TIA IEC Timer Phänomen TIA V15.1

[herrwernersens]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin zusammen,

ich habe mal wieder ein TIA Phänomen festgestellt.
TIA Version V15.1 (installiert auf Win7 Enterprise (Virtuelle Maschine))
S7 1513-1 PN Fimware 2.6.1

Seit TIA V13 deklariere ich Timerinstanzen in DB's als IEC_Timer, egal ob für TON, TOF oder TP.
Aktuell kommt es sporadisch vor, dass obwohl der Timereingang IN den Status 1 hat, die Zeit nach einem Neustart der Steuerung nicht erneut abläuft.
Also vor dem Neustart war die Zeit abgelaufen und der Ausgang gesetzt.
Wenn ich den Eingang, kurz freimache und wieder belege, läuft die Zeit erneut ab.

Ein Ändern des DB Parameters "Optimierter Zugriff" hat keinen Einfluss darauf.
Scheinbar lässt sich das Problem beheben indem man nicht IEC_Timer als Datentyp wählt, sondern direkt TON_TIME.
Das wäre zwar eine Lösung, aber für mich unbefriedigend, da ich dann die verwendeten ~100 Timer in den DBs entsprechend umdeklarieren müsste.
Zudem hat der Typ IEC_Timer wie gesagt seit V13 funktioniert.

Hat jemand von euch schon etwas ähnliches beobachten können?



screenshots: hier gehören das Netzwerk und der DB zwar nicht zusammen, aber es stellt korrekt das Verhalten bzw. die Art der Deklaration dar.





​

 

[Ph3niX]

Der Timer benötigt eine positive Flanke um abzulaufen. Bei einem dauerhaften HIGH-Signal bin ich mir nicht sicher, ob dies immer so erfasst wird von Prozessabbild. Ich würde mal versuchen dies mit einem SR-Glied zu machen und dann über den Systemmerker "FirstScan" dieses SR-Glied zu setzen und dann mit dem Q des SR-Gliedes auf den IN des TON-Timers.

Grüße aus dem Ammerland ;-)

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann es sein, daß die Bedingung zum Ablaufen der Zeit schon seit dem ersten Zyklus nach STOP/RUN-Neustart anliegt? Dann sieht der Timer keine 0-1-Flanke und startet nicht. Wenn die Gefahr/Möglichkeit besteht, daß IN im Zyklus1 schon 1 ist, dann müsstest Du den IN noch mit einem Zyklus1-Signal verknüpfen, oder die betreffenden Timer im OB100 mit IN=0 aufrufen. Vielleicht hat Siemens dafür auch eine spezielle Anweisung erfunden? - das weiß ich nicht.

PS: ach, jetzt sehe ich daß Du ein dauerhaftes TRUE verschaltest - da würde ich davon ausgehen daß das laut Dokumentation nie funktionieren kann. Und wenn doch, dann ist das vielleicht ein Fehler den Siemens irgendwann ohne besonderen Hinweis beseitigt.

Harald

 

[herrwernersens]

Danke für die Antwort.
Es macht aber keinen Unterschied, ob am Eingang das "high" signal hängt, oder ob z.B. ein Sensor der an einem Eingang angeschlossen ist.
Der Timer im DB screenshot hat z.B. einen Lichttaster am Eingang, der läuft nach Neustart aber auch nicht ab.
Das seltsame ist ja wie gesagt, dass solche Konstellationen bisher ohne Probleme funktioniert haben. Die ersten Anlagen mit TIA habe ich edit: 2015 programmiert und bis dato hat das immer funktioniert.

 

[PN/DP]

Vielleicht einfach nur Glück gehabt.

Harald

 

[herrwernersens]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie gesagt, etwas seltsam das Ganze.
In S7 classic brauchte ich doch darauf auch keine Rücksicht nehmen, sondern konnte einen Sensor direkt an den Eingang eines Timers hängen.
In der Beschreibung für den S_EVERZ steht auch, dass ein Wechsel von VKE 0 auf 1 nötig wäre.
Ist es denn nicht so, dass erst beim ersten Einlesen des PAE der Status von 0 auf 1 wechselt? Den Status vor dem Neustart kann er ja nicht behalten, wenn die Instanz nicht remanent angelegt wurde.

 

[PN/DP]

Ich meine zu 95% daß das auch beim S_EVERZ in S7-300/400 schon so war. Und bei TON mußte man (glaube ich) auch ggf. dafür sorgen, daß Instanzen im ersten Zyklus initialisiert werden.

Wie Siemens den TON intern aufbaut und ausführt hat Siemens nicht dokumentiert. Laut Dokumentation wird eine 0-1-Flanke verlangt. Ob im Speziellen im ersten Zyklus eines nicht remanenten Timers durch zufällig günstige Initialisierung der Instanz auch das sofort-1 des IN als 0-1-Flanke "erkannt" wird, schreibt Siemens nirgends - um also auf der sicheren Seite zu sein, daß ein Programm auch einige TIA-Versionen später noch so funktioniert wie ursprünglich, muß man bei allen unklaren Sachen vom ungünstigsten Fall ausgehen und selber für ordnungsgemäße Funktion vorsorgen.

Harald

 

[PN/DP]

Ist es denn nicht so, dass erst beim ersten Einlesen des PAE der Status von 0 auf 1 wechselt?

Wenn der erste Zyklus des OB1 läuft, dann wurde vorher das PAE eingelesen.

Harald

 

[winnman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ev. im Start OB den Eingang auf 0 setzen? (mal nur zum testen) oder den Timer.

 

[RedCali]

was passiert den im NW 5 davor?
Du verschaltest zwar ein TRUE am Timer IN, aber der Timer ist doch ausgegraut - wird also wohl nicht bearbeitet?
Möglicherweise ist das VKE aus dem vorangehenden Netzwerk auf FALSE was hier die Abarbeitung verhindert?

 

[hucki]

Dein Startwert für IN in der Timerdeklaration steht manuell auf TRUE gesetzt.
Demzufolge wird der Timer bei einem Neustart schon so initialisiert und kann bei bereits anliegendem Sensor-Signal am IN auch keine 0-1 Flanke erkennen.

 

[herrwernersens]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dein Startwert für IN in der Timerdeklaration steht manuell auf TRUE gesetzt.
Demzufolge wird der Timer bei einem Neustart schon so initialisiert und kann bei bereits anliegendem Sensor-Signal am IN auch keine 0-1 Flanke erkennen.

Das ist zwar bei dem Beispiel im screenshot korrekt, aber auch wenn z.B. ein Sensor am Timer hängt, ist das Verhalten das gleiche und jetzt kommt das Fatale - manchmal läuft der Timer erneut ab und manchmal nicht. Ich habe hier aktuell 4 gleiche Maschinen stehen, alle haben das gleiche Programm, bei einer machts Probleme, bei den anderen nicht.

 

[herrwernersens]

ICH HAB'S!

Es gibt ja nichts was es nicht gibt. Ein eifriger Mitarbeiter aus der Inbetriebnahme wollte während der Inbetriebnahme die DB's mit den Formatwerten absichern, was er auch gemacht hat.
Bei der Gelegenheit hat er sich gedacht, da speicher ich mal zur Sicherheit alle DB's ab, leider inklusive derer, in denen sich u.a. Instanzen von Timern befinden.
Also er macht eine Momentaufnahme und kopiert diese in die Startwerte -> ist zum Vergleich zu S7-classic ja auch recht komfortabel geworden.
Im Beispiel meines TON's hatte also der Eingang "IN" zum Zeitpunkt der Sicherung den Zustand "1".
Wenn jetzt die Steuerung neu startet steht im Instanz-DB bei "IN" bereits der Status "1" bzw true. Und genau das ist der Grund, warum der Timer nicht mehr abläuft.
Es ist übrigens unerheblich, ob der Timer als TON_TIME oder als IEC_Timer deklariert ist.
Ändert man den Startwert wieder auf "0" bzw. false, ist das Verhalten wieder genauso, wie ich es gewohnt war.

Vielen Dank nochmal für eure Antworten! Gruß Werner

 

[PN/DP]

Also er macht eine Momentaufnahme und kopiert diese in die Startwerte -> ist zum Vergleich zu S7-classic ja auch recht komfortabel geworden.

Also hat hucki in #11 die Ursache des Problems gesehen.

Es ist schon immer mein Reden, daß wahlloses oder gedankenloses Herausladen der DB mit Aktualwerten und später wieder in die SPS hineinladen oft keine gute Idee ist und zu geändertem oder gar Fehlverhalten des SPS-Programms führen kann, weil beim Hineinladen der DB in die SPS die Aktualwerte zu Initialwerten werden!

Der Fehler hier ist das undurchdachte Kopieren der Momentaufnahme in die Startwerte - weil das in dem TIA nun so schön komfortabel geht.

Harald

 

[herrwernersens]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also hat hucki in #11 die Ursache des Problems gesehen.

Es ist schon immer mein Reden, daß wahlloses oder gedankenloses Herausladen der DB mit Aktualwerten und später wieder in die SPS hineinladen oft keine gute Idee ist und zu geändertem oder gar Fehlverhalten des SPS-Programms führen kann, weil beim Hineinladen der DB in die SPS die Aktualwerte zu Initialwerten werden!

Der Fehler hier ist das undurchdachte Kopieren der Momentaufnahme in die Startwerte - weil das in dem TIA nun so schön komfortabel geht.

Harald

Stimmt, das habe ich heute morgen glatt überlesen...!

 

[JesperMP]

Verstehe nicht warum die Erklärung ist dass den Startwert als TRUE definiert ist.
Obwohl den IN Startwert TRUE ist, da IN mit eine Variabel (M2.2) beschaltet ist, wird IN mit den Statuswert von den Variabel beim Aufruf aktualisiert.
Ich denke die Erklärung ist wie schon behauptet dass den IN Variabel nie eine 0-1 Flanke sieht.

herrwernersens har vermutlich Systembyte=MB2 spezifiziert.
Anstatt M2.2, probier mit eine negierte M2.0 (FirstScan). Dies erzeugt die benötigte Flanke.

 

[herrwernersens]

Verstehe nicht warum die Erklärung ist dass den Startwert als TRUE definiert ist.
Obwohl den IN Startwert TRUE ist, da IN mit eine Variabel (M2.2) beschaltet ist, wird IN mit den Statuswert von den Variabel beim Aufruf aktualisiert.
Ich denke die Erklärung ist wie schon behauptet dass den IN Variabel nie eine 0-1 Flanke sieht.

herrwernersens har vermutlich Systembyte=MB2 spezifiziert.
Anstatt M2.2, probier mit eine negierte M2.0 (FirstScan). Dies erzeugt die benötigte Flanke.

Nein, das Sytemmerkerbyte ist nicht aktiviert, die Timer "Neustart", "high" und "low" werden althergebracht im OB100 gebildet.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja, dann verwende deine negierte "Neustart" bit als IN für der Timer.

edit: Wenn du "Neustart" in OB100 setzt, dann musst du es am ende von OB1 rücksetzen.

 

[PN/DP]

Verstehe nicht warum die Erklärung ist dass den Startwert als TRUE definiert ist.
Obwohl den IN Startwert TRUE ist, da IN mit eine Variabel (M2.2) beschaltet ist, wird IN mit den Statuswert von den Variabel beim Aufruf aktualisiert.

Das ist von Siemens so eigentlich auch ziemlich speziell gelöst... es bedeutet, daß der Timer.IN schon vor dem ersten Aufruf einmal gelesen werden muß (und vermutlich auf eine interne Merk-Variable umgespeichert wird). Auf dieses undokumentierte und nicht garantierte Verhalten würde ich mich nicht verlassen.

Wenn man bei einer normalen FB-Instanz den Startwert eines Input manipuliert, spielt es keine Rolle, ob er false oder true ist, wenn beim ersten Aufruf der IN mit etwas beschaltet ist - dann bekommt die Instanz den Startwert gar nicht zu sehen, sondern sieht das was draußen angeschaltet ist. Nur bei den IEC-Timern wird der IN anscheinend schon vor dem ersten Aufruf gelesen und gemerkt - die Timer werden noch vor dem ersten Aufruf initialisiert.

Harald

 

[JesperMP]

PN/DP, ich denke ich verstehe was du meinst.
Die IEC Timer sind etwas Kuriös. Einen normalen FB muss immer aufgerufen werden, aber ein IEC Timer kann mitten in ein LAD Netzwerk sein und wird trotzdem immer aktualisiert.

In diesen Fall, wo IN mit ein Variabel beschaltet ist, glaubst du nicht dass die Lösung ist es mit eine Variabel zu beschalten der bei SPS Start einen Flanke erzeugt ?