TIA TIA V16 gewollte Dateninkonsistenz im Zeitgesteuerten OB (30) ???

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe ich irgend etwas versäumt? Was macht der Compiler?

bohh, da gabs hier doch vor langer Zeit ne Diskussion...

also wenn Du z.B. schreibst: A := 5 + 3; dann macht der Compiler A := 8; draus... solche Optimierungen halt, aber dokumentiert ist das meines Wissens nicht...

Da gibts dann einige kompliziertere Konstellationen, wo nicht immer was Sinnvolles rauskommt.

Gruß.

PS: wenn ich das noch richtig im Kopf hab, gabs auch die Situation, dass nicht benutzte Variablen wegoptimiert wurden.

also z.B.:

// Originalcode
A := 3;
B := 5;
C := A + B;

// macht der Compiler dann u.U.
C := 8;
// draus

und wenn der Compiler nicht checkt, dass A und B im OB35 auch verwendet werden, dann kommt halt Quatsch raus... Solche Sachen mein ich.

 

[Onkel Dagobert]

Ok, das ist gut und schön, aber eine globale Variable wird ja wohl erhalten bleiben. Also, eigentlich .

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok, das ist gut und schön, aber eine globale Variable wird ja wohl erhalten bleiben. Also, eigentlich .

ja, eigentlich Nur wann, wie und ob sie geschrieben wird?

komisch ist das ganze schon. Und sicherlich im Zusammenhang mit den Weckalarmen nicht ganz trivial. Bei der 300/400 war das ja im AWL-Code noch einigermaßen nachvollziehbar. Wie unter der 1500 der "Maschinencode" wirklich aussieht und wann der dann unterbrochen wird, keine Ahnnung... Vermutlich Siemens auch nicht...

Gruß.

 

[ducati]

ich meinte eigentlich, dass in dem Code:

#RETURNVALUE := RD_LOC_T("Akt".Localzeit);

"Akt".Uhrzeit_temp := TOD_TO_TIME(DTL_TO_TOD("Akt".Localzeit));


"Akt".Uhrzeit := "Akt".Uhrzeit_temp;

sicherheitshalber die Variable "Akt".Uhrzeit_temp nochmal gelesen wird.
damit der Compiler nicht doch noch zu:

#RETURNVALUE := RD_LOC_T("Akt".Localzeit);

"Akt".Uhrzeit := TOD_TO_TIME(DTL_TO_TOD("Akt".Localzeit));

optimiert...

 

[Thomas_v2.1]

Ich würde mal zusätzlich den RET_VAL von RD_LOC_T auf größer 1 / kleiner 0 vergleichen und dann ein Fehlerbit setzen. Nicht dass als welchem Grund auch immer mal die Zeit nicht auslesbar ist, und dann in Lokalzeit alles auf 0 gesetzt wird. Das ist ja leider nicht dokumentiert was die Funktion dann in OUT schreibt, ob nichts, oder null, oder zufällig.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist den nur ein Weckalarm OB vorhanden oder gibt es
da noch andere wo die Localzeit abgefragt wird?

Nicht das es da eine Überschneidung gibt weil der eine 10ms und der
andere 100ms und einer ist höher Priorisiert.

 

[rostiger Nagel]

Besteht den nicht die Möglichkeit die „DATE_TIME“ aus der
Start Information des OBs zu nutzen?

 

[PN/DP]

"Optimierte" OB haben diese Start-Info nicht.

Harald

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es ist nur ein Weckalarm-OB vorhanden, ist auch so schlimm genug...

Die Lokalzeit wird korrekt gelesen und ist jeden Zyklus vorhanden.
Den Ärger verursacht scheinbar die Wandlung "DTL_TO_TOD"

Das Format TOD hat das selbe "Format" wie Time, ist aber im Wertebereich eingeschrängt.

Bin ja mal auf die Antwort von Siemens gespannt...

 

[ducati]

dann probier doch mal:

#RETURNVALUE := RD_LOC_T("Akt".Localzeit);

"Akt".Uhrzeit_temp := TOD_TO_TIME(DTL_TO_TOD("Akt".Localzeit));


"Akt".Uhrzeit := "Akt".Uhrzeit_temp;

evtl. weiter unten im Code alle Variablen nochmal lesen, damit der Compiler die nicht wegoptimiert. Kann man eigentlich diese Compileroptimierung noch irgendwo abschalten?

Hast Du das mal probiert? Gehts dann???

 

[NBerger]

Ja das geht. Wobei die explizite Wandlung TOD_TO_TIME nicht notwendig ist.

Habe auch Integer, Real, LReal, Time, LTime, usw. Zuweisungen getestet. (ist iO)

Habe gerade die Projektanforderung vom Support bekommen ... DIE MACHEN DAS NICHT MAL SELBST

HEITEC AG
Externer Dienstleister der Siemens AG
Digital Industries
Customer Services DI
Customer Care Center
Technical Support

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den Heitec Support musst so schnell es geht überspringen. Der nächste Level ist dann Siemens selbst...

 

[DeltaMikeAir]

Habe gerade die Projektanforderung vom Support bekommen ... DIE MACHEN DAS NICHT MAL SELBST

Das ist halt der 1st Level Support, die komplexeren Sachen gehen dann weiter zu Siemens.

 

[ducati]

Was ist denn jetzt hier rausgekommen???

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habs Projekt geschickt... man konnte es nachstellen... Ist jan Siemnes übergeben... jetzt schon 2 Tage Ruhe.
Scheint nicht ganz so einfach zu sein.

Wenn Antwort kommt melde ich's

 

[NBerger]

Und schon ist Antwort da...

Hier die vollständige Meldung:

wenn Sie den Aufruf des LGF Bibliothek-Anweisung entfernen und die folgende Anweisung einfügen wird die lokale Zeit korrekt im OB30 angezeigt, ohne auf 0 zurückgesetzt zu werden:

//Tag_1war ein MW zur Ausgabe des Int-Wertes, kann jedoch durch eine static-Variable ersetzt werden

Entfernter Aufruf: "LGF_Astro_DB"(modeDMS:=TRUE, actLocalTime=>"Akt".Localzeit);

"Tag_1":= RD_LOC_T("Akt".Localzeit);

"Akt".Uhrzeit := TOD_TO_TIME(DTL_TO_TOD("Akt".Localzeit));

Der verwendete LGF-Baustein entstammt aus der V14 SP1. Für die V16 ist bereits eine neuere Version verfügbar V5.0 verfügbar -> https://support.industry.siemens.com/cs/de/de/view/109479728

In Ihrem Projekt müsste der LGF_Astro durch LGF_AstroClock ersetzt werden. Einige Parameter des Typ-FBs müssten im Projekt umbenannt werden und das Verhalten erneut geprüft werden. Ebenfalls wäre empfehlenswert die Temp-Variablen im LGF_AstroClock in den static-Bereich (per Markieren + Drag / Drop) zu kopieren, wenn Sie mit Interrupt-OBs arbeiten.

Werde das morgen mal testen...

Warum das jetzt ein Problem macht die Localzeit in einem FB zu holen ??? aber gut...

Im LGF-Astro wird lediglich Sonne auf und Untergang berechnet aus dem zuvor geholten Datum...

Es bleibt komisch. Werde natürlich updaten und dann mal schauen

 

[ducati]

Vielleicht schreibt der Astro Baustein intern doch irgendwie Dein "Akt".Localzeit
Oder ist das nen InOut?

Kann man den Astrobaustein öffnen? Oder ist der geschützt.

Könntest Du ja ganz leicht prüfen, indem Du den Bausteinaufruf mal auskommentierst...

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich rege mich grad mal was über Siemens auf, ist schon eine Frechheit so eine Antwort.

Kann man den Astrobaustein öffnen? Oder ist der geschützt.

Könntest Du ja ganz leicht prüfen, indem Du den Bausteinaufruf mal auskommentierst...

Lerne ja gerne was dazu, was soll den beim Auskommentieren passieren???


Zurück zur Siemensantwort:
Wenn ich das jetzt richtig interpretiere steht da:
- Keine Bausteinaufrufe da nicht sicher gestellt sein kann das Daten verfälscht (inkonsistent) sind!
- Keine Temp-Variablen da bei Interupts die Konsistenz nicht garantiert werden kann.

Als Resüme: Verwenden sie bitte einen anderen Hersteller!!! oder wie jetzt.

Sollte vielleicht ne Nacht drüber schlafen bevor ich denen antworte:sc6:

 

[Oberchefe]

Diese Funktionen

• sind per Parametrierung sofort verwendbar
• können universell eingesetzt werden
• sind nicht Know How geschützt und somit individuell anpassbar
• sind inklusive Schnittstellenbeschreibung optimal dokumentiert

sind wohl nicht geschützt

 

[Oberchefe]

Ich denke dass wenn du irgendwo vom OB1 aus gestartet bist, Temp-Variablen beschrieben hast, dann der OB30 dazwischen kommt, dort die gleichen Temp-Variablen beschreibt, dann geht es zurück wo du warst und du fragst dann die Temp-Variablen ab und bekommst den falschen Inhalt. Hätte aber auch erwartet, dass der OB30 entweder einen anderen Speicherbereich für seine Temp-Variablen verwendet oder alternativ deren Inhalt zu Beginn sichert und am Ende wiederherstellt.