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

Zuviel Werbung?
-> Hier kostenlos registrieren
Da wäre es ja mal interessant, welche Bausteine bzw. Funktionen dies noch betrifft...

Ansonsten, Bilder sagen mehr als Worte:
200w.gif

Wahrscheinlich ganz viele :D
Wenn ich mein altes Hirn bemühe, dann gab es dieses Thema auch schon zu S5-Zeiten.
Bei bestimmten Steuerungen konnten Alarme nach jeder Anweisung auftreten und bei anderen nur bei Bausteinwechsel.
Die Befehle AS und AF findet man bei den alten S5-Bausteinen gar nicht selten.
Auch bei "geöffneten" Original Siemens-Bausteinen :p
 
Da wäre es ja mal interessant, welche Bausteine bzw. Funktionen dies noch betrifft...


ach Du Scheiße,

im blödesten Fall würde es nicht funktionieren wenn man im OB 1 schreibt:

Wert_aus_GlobalDB := Wert_aus_GlobalDB + 1.0;

und dann Wert_aus_GlobalDB im OB35 lesen würde...

naja...

PS:
oder
im OB1:
Wert_aus_GlobalDB := INT_TO_REAL(Wert_Int);

und Wert_aus_GlobalDB im OB35 lesen...

das wär schon Krass, wenn so bestimmet Sachen nicht gehen würden :shock:


PPS:

und noch problematischer, da es ja nicht nur Weckalarme betrifft, sonder auch das Lesen der Variablen von der Visu aus, sprich nicht mehr vorhandenen Zykluskontrollpunkt für HMI...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
und noch problematischer, da es ja nicht nur Weckalarme betrifft, sonder auch das Lesen der Variablen von der Visu aus, sprich nicht mehr vorhandenen Zykluskontrollpunkt für HMI...

Zykluskontrollpunkt ist im Prinzip genau die gleiche Thematik.
Das Problem des TE musste da eigentlich genauso auftreten.
 
Im OB1:
Code:
"Akt".Uhrzeit := DTL_TO_TOD("Akt".Localzeit);

IF "Akt".Uhrzeit = t#0s THEN
    "Tag_2" += 1;
END_IF;

Im OB30:
Code:
IF "Akt".Uhrzeit = t#0s THEN
    "Tag_3" += 1;
END_IF;

Variablentabelle nach ca 1 Minute:

Anhang anzeigen 53051


hmm, konnt das bisher überhaupt jemand nachstellen???

Ich probiers grad aus:
TIA V15.1.0.5 S7-1510SP FW2.6.1
OB1 optimiert keine Mindestzykluszeit Priorität 1
OB30 optimiert 0,5ms Priorität 17
sonst kein Code in der SPS
Zykluszeit: kürzeste 0,153ms aktuelle 0,2...1,1ms längste 9,118ms

"Akt".Uhrzeit Datentyp time optimierter GlobalDB remanent
"Akt".Localzeit Datentyp DTL optimierter GlobalDB remanent

irgendwie tritt das bei mir nicht auf, zumindest nicht 26 mal pro Minute, aber ich lass es mal bis morgen laufen...

Bei Reinitialisierung vom GlobalDB hab ich da Einträge, aber sonst nicht :confused:

Gruß.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Grund dafür liegt in der Implementierung der Datums-/Zeitkonvertierungsfunktionen. Alle diese Konvertierungen in SCL, die fehlschlagen könnten, initialisieren zuerst den Wert mit einer Null und führen dann die Konvertierung durch. Wenn die Konvertierung nicht erfolgreich war, ist das Ergebnis automatisch Null. Der OB30 unterbricht die Ausführung jederzeit, so dass er manchmal direkt nach dem internen Setzen des Werts auf Null unterbrochen wird und die eigentliche Konvertierung nach der Ausführung des OB30 erfolgt. Um solche Dinge zu vermeiden, könnte der Benutzer die Konvertierung in eine temporäre Variable durchführen und dann das Ergebnis der Konvertierung der statischen Variablen zuweisen.

Achso, es ist kein grober Fehler, das fehlerhafte Verhalten ist auch noch in anderen Funktionen vorhanden, von denen wohl bei Siemens keiner weiß wer da wieder Bockmist verzapft hat. Der Anwender muss darauf durch Versuch und Irrtum selber kommen, und dann kreative Ideen entwickeln um die Fehler zu beseitigen.

Und vermutlich gibt es dann noch mindestens vier verschiedene Umschiffungsvarianten, weil die der Fehler sich unterschiedlich verhält wenn optimierte Bereiche, nicht optimierte Bereiche, nicht optimierte in remanenter Struktur, oder wenn der Entwickler heute wieder seine Schuhe mit Klettverschluss anziehen musste, weil er auch nicht in der Lage ist sich eine Schleife zu binden.
 
Das würde bedeuten, daß man in höherprioren Tasks grundsätzlich nicht auf Variablen zugreifen darf, die in niederen Task als Rückgabewert von Siemens-Funktionen verwendet werden. Mehrmalige Zuweisungen an Ausgänge geht gar nicht...

Irgendwie mag ich nicht glauben, daß das wirklich so stümperhaft implementiert sein soll... und nicht schon früher aufgefallen ist... Werden jetzt auch schon die TIA-Compiler von unerfahrenen Praktikanten programmiert und ist da niemand mit etwas Ahnung, der deren Code ansatzweise überprüft? Oder ist die Erklärung eine Fantasie des first-level-Supports? Hat der Support auch ausdrücklich geschrieben, daß die initiale Zuweisung von 0 an den Ausgangsparameter bzw. den Function-Rückgabewert erfolgt und nicht an lokale/temporäre Zwischenvariablen? Und anscheinend werden die Rückgabewerte dann byReference übergeben? Sollten elementare Datentypen nicht grundsätzlich als Kopie (byValue) übergeben werden? Integrierte Siemens-Funktionen/Makros müssen sich da wohl nicht dran halten...

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
irgendwie tritt das bei mir nicht auf, zumindest nicht 26 mal pro Minute, aber ich lass es mal bis morgen laufen...

Hab jetzt nach 12 Stunden über Mitternacht 3 Einträge im OB1 und 2 Einträge im OB30 :confused:

keine Ahnung, was das bedeutet, was passiert eigentlich um Mitternacht?

Gruß.
 
Zuletzt bearbeitet:
ich probiers bis morgen nochmal mit TIA V16.0.0.4 und Firmware 2.8.3, ne F-CPU hab ich nicht...

kurzfristigs siehts nicht so aus, dass da im OB30 beim Lesen der Variablen aus dem GlobalDB etwas nicht stimmt, also nach 5min noch 0 Einträge...

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo ducati,

lässt du den Siemens-Vorschlag mit dem Umweg über TEMP dabei auch mitlaufen?

nee... ich versuche überhaupt erstmal das Problem nachzustellen. Wie PN/DP glaub auch ich noch nicht wirklich an einen Bug...

OB1:
Code:
#RETURNVALUE := RD_LOC_T("DB1".Localzeit);


"DB1".Uhrzeit := DTL_TO_TOD("DB1".Localzeit);


IF "DB1".Uhrzeit = t#0s THEN
    "MD100" += 1;
END_IF;

OB30:
Code:
IF "DB1".Uhrzeit = t#0s THEN
    "MD104" += 1;
END_IF;
 
Also ich habe das Problem bereits "damals" umschifft...

Für mich ist das abgeschlossen. Von Siemens ist eh nichts zu erwarten und einen anderen Ansatz sehe ich nicht.

P.S.: Was da wohl alles im Motion-Control schief gehen kann... ich mag garnicht dran denken...
 
nee... ich versuche überhaupt erstmal das Problem nachzustellen. Wie PN/DP glaub auch ich noch nicht wirklich an einen Bug...

Das problem stellte sich bei mir aber auch erst ein wenn im Zyklischen Programm IF Then abfragen mit einem Vergleich auf einen Time-Wert gab.

Code:
IF  "Akt".Uhrzeit > t#5h45m)) THEN
 
nach 8 Stunden jetzt auch unter TIA16 kein Fehler bei mir.

Das problem stellte sich bei mir aber auch erst ein wenn im Zyklischen Programm IF Then abfragen mit einem Vergleich auf einen Time-Wert gab.

Code:
IF  "Akt".Uhrzeit > t#5h45m)) THEN

gibts doch die Abfragen auf = t#0s

aber ich hab noch ein par hinzugebaut und wart mal bis morgen.


OB1:
Code:
#RETURNVALUE := RD_LOC_T("DB1".Localzeit);


"DB1".Uhrzeit := DTL_TO_TOD("DB1".Localzeit);


IF "DB1".Uhrzeit = t#0s THEN
    "MD100" += 1;
END_IF;



IF "DB1".Uhrzeit > t#5h45m THEN
    #Test_Temp := "MD100"+ 1;
END_IF;



IF "DB1".Uhrzeit > t#5h45m THEN
    #Test_Temp := "MD100"+ 1;
END_IF;

OB30:
Code:
IF "DB1".Uhrzeit = t#0s THEN
    "MD104" += 1;
END_IF;



IF "DB1".Uhrzeit > t#5h45m THEN
    #Test_Temp := "MD100"+ 1;
END_IF;



IF "DB1".Uhrzeit > t#5h45m THEN
    #Test_Temp := "MD100"+ 1;
END_IF;

aber ich glaub nicht, dass sich da was tut...

vielleicht liegts an der F-Steuerung?

Gruß.
 
also ich kanns NICHT nachstellen...

"Akt".Uhrzeit ist bei mir nur 0 bei Reinitialisierung des DB sowie in der Nacht um 0:00 Uhr für 2 bzw 4 Zyklen.

Gruß.
 
Ich lasse auch seit ein paar Stunden einen Test auf einer 1200er laufen, bisher noch kein Fehler aufgetreten.
Ich habe 30 Time Variablen in die ich im OB1 konvertiere und im OB30 alle 50ms abfrage, und parallel frage ich jede Sekunde vom WinCC die Variablen ab und prüfe auf Null, denn HMI-Kommunikation hat ja ebenfalls fast die höchste Priorität (damit kann ich zumindest auch eine String-Zuweisung während der Zuweisung unterbrechen).
 
Zurück
Oben