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

Zuviel Werbung?
-> Hier kostenlos registrieren
Habe nochmal den gesamten Thread genau durchgelesen und nun dies gefunden:
NBerger schrieb:
In "Akt".Localzeit steht definitiv immer eine gültige Zeit und im OB1 wird "Akt".Uhrzeit definitiv nicht T#0s.

Habe das mit "Fangschaltungen" überprüft die mir jeweils ein Bit setzen wenn es so auftreten würde, werden aber nicht gestzt (Im OB30 schon).
Zum Vergrößern anklicken....
NBerger schrieb:
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
Zum Vergrößern anklicken....
Also suche den Schreibzugriff, der "Akt".Uhrzeit auf T#0s schreibt.

Harald
 
NBerger, sieh dir auch die Querverweise des Bausteins an, der deine Codezeilen enthält. Ich denke gerade an einen Fall, wo ein FB im OB1 und in einem Weckalarm mit der selben Instanz aufgerufen wurde. In diesem fanden u.a. Flankenauswertungen statt, wodurch sich Inkonsistenzen ergaben. Der TE hatte damals das Programm gepostet, wodurch der Fehler schnell gefunden wurde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wird der DB "Akt" auch mal als Instanz-DB geöffnet? Oder als DB_ANY oder Variant oder was auch immer TIA mit indirekter Adressierung auf "optimierte" DB so hergibt? Dann wird das TIA die Verwendungsstellen nicht anzeigen, dann muß man selber logisch suchen.

Tip: lege Dir einen total frischen DB neu an und kopiere die Lokalzeit in "NeuDB".Uhrzeit und verwende "NeuDB".Uhrzeit wo immer Du das lesend brauchst, dann könnte Dir egal sein, wo/warum "Akt".Uhrzeit auf T#0s geschrieben wird.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es kann doch wirklich nicht so schwer sein, so ein Problem bis auf den Ursprung einzugrenzen. Also das Programm soweit reduzieren bis nichts anderes mehr vorhanden ist. Am Besten geht das natürlich in Plcsim wenn das Verhalten dort auch auftritt. Wenn nicht, dann kann man an der realen SPS auch bei laufender Anlage einen neuen Programmteil mit neuen Variablen anlegen.
 
Es kann doch wirklich nicht so schwer sein
Zum Vergrößern anklicken....

Nun: habe mal nach und nach alles auskommentiert... bis dann die letzte "Akt".Uhrzeit abfrage in einem IF Then auskommentiert wurde... ab da kein Fehler mehr.

Na wenn das jetzt ein Fehler meinerseits ist...

Also alles wieder zurück auf Anfang und der Ordnung halber das Format von Time auf TOD geändert und siehe da kein Fehler mehr.

Na wenn da nicht einer lauert. ;)

Mal schauen was Siemens so die nächsten Tage meint. :ROFLMAO:
 
NBerger schrieb:
habe mal nach und nach alles auskommentiert... bis dann die letzte "Akt".Uhrzeit abfrage in einem IF Then auskommentiert wurde... ab da kein Fehler mehr.

Na wenn das jetzt ein Fehler meinerseits ist...
Zum Vergrößern anklicken....
Nun mach' es doch nicht so geheimnisvoll. Wie lautet denn der auskommentierte Programmcode? Ist das geheim? Oder sollen andere Anwender auch den selben Fehler machen? Zeige uns doch bitte mal den problematischen Code. Dann können wir fundiert diskutieren, ob das ein Fehler von Siemens oder vom Anwender ist.

Steht da womöglich was wie "IF "Akt".Uhrzeit := t#0s THEN" oder "IF MyFunc(result=>"Akt".Uhrzeit) = t#0s THEN" ?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Geheim ist das mit Sicherheit nicht, aber oft genug schießt das dann in völlig falsche Richtungen...

Hier eine der "problematischen" Stellen: "Akt".Uhrzeit ist vom Typ Time (funktioniert nicht)

IF ("DB_Temp_Heizung".Solar_Dach > 90.0 OR "DB_Temp_Heizung".Rücklauf_Solar > 90.0) AND "Akt".Uhrzeit > t#9h AND "Akt".Uhrzeit < t#19h THEN
"Rfg_Pumpe_Solar_AUS" := false;
ELSE
IF "Verz_Pumpe_EIN".Q THEN // [°C]
"Rfg_Pumpe_Solar_AUS" := false;
ELSIF NOT "Verz_Pumpe_AUS".Q THEN
"Rfg_Pumpe_Solar_AUS" := true;
END_IF;
END_IF;
Zum Vergrößern anklicken....

"Akt".Uhrzeit ist hier vom Typ TOD (funktioniert)
IF ("DB_Temp_Heizung".Solar_Dach > 90.0 OR "DB_Temp_Heizung".Rücklauf_Solar > 90.0) AND "Akt".Uhrzeit > TOD#09:00:00 AND "Akt".Uhrzeit < TOD#19:00:00 THEN
"Rfg_Pumpe_Solar_AUS" := false;
ELSE
IF "Verz_Pumpe_EIN".Q THEN // [°C]
"Rfg_Pumpe_Solar_AUS" := false;
ELSIF NOT "Verz_Pumpe_AUS".Q THEN
"Rfg_Pumpe_Solar_AUS" := true;
END_IF;
END_IF;
Zum Vergrößern anklicken....

Ein Problem sehe ich da nicht. Wie schon gesagt "Akt".Uhrzeit wird nur EINMAL geschrieben! Das ist ABSOLUT sicher.

Steht da womöglich was wie "IF "Akt".Uhrzeit := t#0s THEN" oder "IF MyFunc(result=>"Akt".Uhrzeit) = t#0s THEN" ?
Zum Vergrößern anklicken....
Selbst wenn so etwas ginge, macht man das nicht.

Nur für den Fall das dies hier auch noch hochkocht:
Binär gesehen sind TOD und Time identisch!
Aus der Hilfe Explizite Wandlung Time_TO_TOD:
Das Bitmuster des Quellwerts wird ohne Änderung rechtsbündig in den Zieldatentyp übertragen. Wenn der Quellwert außerhalb des Wertebereichs von TOD liegt, dann wird der Zieldatentyp nicht verändert.
Zum Vergrößern anklicken....
 
(rote Markierungen sind von mir)
NBerger schrieb:
Hier eine der "problematischen" Stellen: "Akt".Uhrzeit ist vom Typ Time (funktioniert nicht)
IF ("DB_Temp_Heizung".Solar_Dach > 90.0 OR "DB_Temp_Heizung".Rücklauf_Solar > 90.0) AND "Akt".Uhrzeit > t#9h AND "Akt".Uhrzeit < t#19h THEN
(...)
Zum Vergrößern anklicken....
"Akt".Uhrzeit ist hier vom Typ TOD (funktioniert)
IF ("DB_Temp_Heizung".Solar_Dach > 90.0 OR "DB_Temp_Heizung".Rücklauf_Solar > 90.0) AND "Akt".Uhrzeit > TOD#09:00:00 AND "Akt".Uhrzeit < TOD#19:00:00 THEN
(...)
Zum Vergrößern anklicken....
Ein Problem sehe ich da nicht.
Zum Vergrößern anklicken....
Mit "funktioniert nicht" meinst Du
• "funktioniert nicht" : Akt".Uhrzeit wird dabei (manchmal) auf T#0 geschrieben
• "funktioniert" : Akt".Uhrzeit wird nicht verändert
?

Es macht für mich keinen Sinn, eine Uhrzeit mit TIME# (T#) zu vergleichen, auch wenn da bei Siemens eine implizite Konvertierung zu TOD# möglich ist (die aber bei aktivierter IEC-Prüfung nicht toleriert wird!). TIME# (T#) ist für eine Zeitdauer gedacht und TOD# ist für einen Zeitpunkt. Dabei ist es völlig egal, daß die binäre Implementierung beider Datentypen gleich ist. Was denkst Du, warum es den Datentyp TOD (TIME_OF_DAY) gibt? Weil Siemens uns Programmierern die Arbeit unnötig schwer machen will? ;) Ich habe Dich schon vor einer Woche gefragt: "Warum ist "Akt".Uhrzeit vom Datentyp TIME (und nicht TOD)?", doch Du bringst nur die Forderung, daß "die explizite Wandlung TOD_TO_TIME nicht notwendig ist." anstatt mal darüber nachzudenken und drauf einzugehen.

Vielleicht macht Siemens bei dem hier gezeigten TIME#-Vergleich auch noch einen Fehler und schreibt tatsächlich die Vergleichsvariable (manchmal?) auf 0? Doch das würde vermutlich gar nicht passieren, wenn man da von vornherein den richtigen Datentyp TOD verwendet. Ich kann es nicht testen, und ehrlich gesagt glaube ich das auch nicht. Ich glaube die Problemursache liegt woanders (bei einer anderen Stelle mit impliziter Konvertierung TIME/TOD?).

NBerger schrieb:
Wie schon gesagt "Akt".Uhrzeit wird nur EINMAL geschrieben! Das ist ABSOLUT sicher.
Zum Vergrößern anklicken....
Das ist wirklich schwer zu glauben.

NBerger schrieb:
Steht da womöglich was wie "IF "Akt".Uhrzeit := t#0s THEN" oder "IF MyFunc(result=>"Akt".Uhrzeit) = t#0s THEN" ?
Zum Vergrößern anklicken....
Selbst wenn so etwas ginge, macht man das nicht.
Zum Vergrößern anklicken....
Ob sowas in TIA V16 überhaupt möglich ist, weiß ich nicht. Es könnte aber ein unbeabsichtigter Tippfehler sein, und als Programmierer der das selber geschrieben hat, ist man vielleicht schon blind das zu sehen... man weiß ja was man gewollt hat. ;) Hast Du alle Verwendungsstellen von "Akt".Uhrzeit kontrolliert?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für mich macht es auch keinen Sinn, TOD mit TIME zu vergleichen. Mit IEC-Prüfung bin ich aber auch noch nie in diese Verlegenheit gekommen. Dennoch würde ich annehmen, dass es funktionieren müsste. Und generell scheint es ja auch so gedacht zu sein, da der Fehler nur sporadisch auftritt, oder zumindest nicht zyklisch. NBerger, du kannst doch den Fehler bestimmt rekonstruieren? Ist es dir möglich, dein Projekt so weit zu reduzieren, dass du uns eine lauffähige Kostprobe liefern kannst, eventuell als schlanke Quelldatei? Das wäre schon mal sehr interessant. Früher habe ich virenverseuchte Disketten gesammelt :ROFLMAO: .
 
Für mich ist das auch noch ein bisschen unbefriedigend. Da waren zwar Fehler im Programm, doch die dürften alle nicht dazu führen, daß "Akt".Uhrzeit auf 0 geschrieben wird. Ich kann mir nur schwer vorstellen, daß ein einfaches Ändern des Datentyps von TIME auf TOD den Fehler abstellt. Ich hätte auch gern ein reproduzierbar Fehler-verursachendes Programmbeispiel, am besten als Quelle, dann könnte man leicht testen, ob das Problem in TIA V16 neu aufgetaucht ist oder ob es das vorher schon gab.

Harald
 
Ja, das fände ich auch gut. Ein komplett runterreduziertes Projekt oder Quelle mit der man das Fehlverhalten nachstellen kann. Die Neugier ist schließlich geweckt und wenn das jetzt im Sande verläuft, schade.
 
Schreibt ein HMI oder ein OPC Server eventuell in "Akt".Uhrzeit ?
Vielleicht unbewusst, wegen alten Programmüll.
Wenn es 26 Mal innerhalb von eine Minute passiert kann man schnell ein test machen indem man die HMI oder OPC Server von die Steuerung trennt.
 
Ich habe mir mal den Astro Baustein reingezogen und im OB1 verwendet und auch Überprüfungstags eingebaut. Weiterhin einen Zähler wie oft der OB1 und der OB30 dran waren...
Da wird nichts mit 0 überschrieben...

8B893qRL9rrukAAAAASUVORK5CYII=
 
Zurück
Oben