Step 7 Das Verhalten der Simatic Timer in verschiedenen Systemen

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich möchte mal die unterschiedlichen Verhaltensweisen der Timer in den verschiedenen Siemens Steuerungen zur Diskussion stellen, denn meiner Meinung nach ist da die ein oder andere Variante wo das Verhalten mindestens zwefelhaft ist.

Verglichen habe ich:

a) Verhalten bei Zeitverzögerung 0s
b) Remanenz-/Anlaufverhalten
c) Verhalten bei Änderung der Zeit bei laufendem Timer

---
S7-300/400: S5 Timer S_EVERZ

a) schaltet S bei S5T#0ms unverzüglich durch
b) Timer mit S:=true bei erstem Durchlauf, Timer läuft ab egal ob Timer remanent/nicht remanent
c) Ändern der Zeit bei laufendem Timer von lang nach kurz nicht möglich. Ändern der Zeit bei laufendem Timer von kurz nach lang nicht möglich.

---
S7-300/400: TON SFB4

a) Schaltet IN bei T#0s nicht durch
b) IN=true bei erstem Durchlauf bzw. SPS Warmstart mit IN:=true im Instanz-DB: Timer läuft ab -> Q:=true
c) Ändern der Zeit von kurz nach lang nicht möglich (Timer nach 1s abgelaufen, wird nach 5s auf 10m geändert, es bleibt Q:=true)
Jedoch: Ist In:=True mit PT:=T#0s und somit Q:=false und wird dann PT auf z.B. T#5s geändert, dann läuft die Zeit ab -> Q:=true.
Ändern der Zeit nach unten ist möglich (Timer mit PT:= t#10m gestartet, nach 10s auf t#1s gesetzt -> Q:=true)

-----
TON-Timer S7-1200/1500

a) Schaltet IN bei T#0s unverzüglich durch
b) Wurde IN (aus welchen Beweggründen auch immer) mit TRUE aus der AS geladen und als Startwert gesetzt, dann läuft der Timer trotz IN:=true nach Neustart überhaupt nicht ab.
c) Ändern der Zeit bei laufendem Timer von lang nach kurz nicht möglich. Ändern der Zeit bei laufendem Timer von kurz nach lang nicht möglich.

---
CFC/PCS7 TimerP (aktuellste Version)

a) Wenn Ti < SampleTime, dann passiert nichts am Ausgang.
Wenn anschließend Ti > SampleTime geändert wird, dann kein Fehler an Error und kein Ausgang setzen, Eingang muss neu angetriggert werden
b) nicht getestet, bzw. durch automatische Platzierung im OB100-Aufruf und Anlaufverhalten einstellbar.
c) Ti kann nicht im laufenden Betrieb geändert werden

---

Meiner Meinung nach sollte eine Einschaltverzögerung mit 0s Verzögerung unverzüglich durchschalten. Das wurde bei der 1200/1500 wenigstens korrigiert. Beim TimerP kommt hinzu, dass die Untergrenze auch noch variabel von SampleTime abhängt was es aufwändig macht einstellbare Parameter entsprechend zu begrenzen. Wenn der Timer im 0,2 Sekunden Zyklus aufgerufen wird, und ich 0,1 Sekunden als Verzögerung angebe, dann läuft er eben wenigstens nach 0,2 Sekunden ab. An der Genauigkeit kann es nicht liegen, denn die Abweichung habe ich auch bei größeren Zeiten. Also was soll das?

Unmöglich ist hingegen das Anlaufverhalten TON bei der 1200/1500. Wie viele Zustände hat eine Einschaltverzögerung? 1) IN:= false/Q:=false 2) IN:= true, Q:=false (Timer läuft) 3) IN:=true, Q:= true (Timer abgelaufen). Wozu ein Zustand wo IN:= true aber überhaupt nichts passiert?

Das Verhalten eines Timers bei ändern der Zeit bei laufendem oder abgelaufenem Timer ist sicherlich Geschmackssache. Das ungünstige bei den TON Timern ist dabei, dass man nach einer Änderung an PT an ET überhaupt nicht sehen kann wie lange der Timer noch läuft. Meine eigenen Timer haben überhaupt kein Problem mit der Änderung der Zeit.

Findet ihr das schlüssig was Siemens da bei den Timern veranstaltet?

 

[Clyde82]

Hi,

wenn du sagst, dass dein Timer abläuft egal ob remanent oder nicht, war auch die Variable die ihn auf true setzt remanent? Weil eigentlich wirbt Siemens ja bei Remanenz genau mit diesen Sachen, Merker, DBs, Zeiter, Zähler. Da fänd ich es schon "komisch" wenn das nicht bei wäre. War die Ausgangsvariable (Q) "true" auch wenn der Timer läuft, obwohl er es nicht hätte tun sollen?

Ich stimme dir zu, eine S_Everz mit s5t#0ms sollte durchschalten, aber den Anwendungsfall dafür sehe ich nicht?

Das sich die unterschiedlichen Methoden anders verhalten, überrascht mich jetzt irgendwie nicht.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

S_EVERZ schaltet doch mit 0s durch, so wie ich es zumindest erwarten würde.

Beim TON der 1200/1500 muss Q beim Rücklesen auf false sein (d.h. Timer läuft) damit das Verhalten auftritt. Das Problem mit den nicht mehr anlaufenden Timer nach Momentaufnahme/Startwerte setzen damit es keinen Datenverlust gibt, gab es zumindest schon einmal hier im Forum. Dass beim Rücklesen gerade kein Timer läuft lässt sich ja nicht ausschließen, und das Rücklesen passiert bei den 1500er sicher öfters, weil da andauernd alles geladen und zurückgesetzt werden will.

Aber ich schrieb ja, wie oder was auch immer dort zurück gelesen wird, warum überlegt sich Siemens bei einer Einschaltverzögerung mit max. 3 Zuständen einen weiteren den garantiert niemand haben will?

 

[hucki]

...warum überlegt sich Siemens bei einer Einschaltverzögerung mit max. 3 Zuständen einen weiteren den garantiert niemand haben will?

Wird nicht immer propagiert, dass der 0-1 Wechsel am IN das eigentliche Timer-auslösende Element ist?
Somit wäre da nicht wirklich ein neuer Zustand, denn den gab' es ja nicht, wenn der IN von Anfang an auf 1 ist.

Das ist doch auch oft das Problem, wenn der Timer in irgendwelchen IF-Konstrukten "gefangen" ist.

 

[Thomas_v2.1]

Da wäre auch die Frage, wer sich das mit der Flanke ausgedacht hat, und was das für Vorteile haben soll?

Programmieraufgabe 1. Woche: Programmiere eine Einschaltverzögerung. Wenn IN=true ist T=T+deltaT, wenn T>=PT dann Q=true, wenn IN:= false dann T=0 kommt bei vermutlich 95% der Anfänger heraus. Wie kann man da 4 verschiedene Varianten programmieren die sich alle unterschiedlich verhalten? Und warum? Vielleicht bin ich zu doof dafür den Grund zu erkennen.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Thomas:
wenn du nun noch den Quellcode deines eigenen Timers dabei packst (das wird wahrscheinlich ein Pendant zum IEC-Timer sein) dann wäre das aus meiner Sicht ein Beitrag für die FAQ ...

Gruß
Larry

 

[Windoze]

Bei der S7-1200/1500 gibt es noch einen Fall. Wenn der Timer als Multiinstanz in einem nicht Optimierten FB
Aufgerufen wird, läuft er bei PT=0 auch nicht los. (Kann man Einzelinstanzen der Timer auch auf nicht Optimiert umstellen? Habe ich noch nicht getestet. Evtl. ist es da auch so.)
Ich denke mal, das ist ein Kompatibilitätsmodus für migrierte S7-300/400 Programme.

 

[vollmi]

@Thomas:
wenn du nun noch den Quellcode deines eigenen Timers dabei packst (das wird wahrscheinlich ein Pendant zum IEC-Timer sein) dann wäre das aus meiner Sicht ein Beitrag für die FAQ ...

Mich würde interessieren, wie der Quellcode des perfekten Timers aussehen würde.

Ich wäre ja den einfachen weg gegangen. Und hätte bei IN True, bei jedem Aufruf die Differenz der Systemzeit zum letzten Aufruf addiert und wenn das Resultat grösser als T dann Q gesetzt.
Bei nem Sekundengenauen Timer würds vermutlich sogar langen mit dem Systemsekundentakt die zeit zu erhöhen, da muss man sich dann auch nicht um Überläufe kümmern wie wenn man Time_tck nutzt.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

eine Variante für den Vergleich fehlt noch: S5 Timer unter S7 1200/1500

genau wegen dem Kuddelmuddel (und noch andere Gründe) verwende ich den auch unter S7-1500 weiterhin...

jetzt krig ich gleich wieder Schläge

Ich finde das bei einem so essentiellen Softwarebestandteil wirklich SEHR bedenklich

@Thomas, vielleicht kannst Du den unter Deinen Testbedingungen mit aufnehmen.

grundsätzlich wären auch noch Timer des Safety Teils interessant, das sind dann nochmal 6 andere Verhaltensweisen.

:roll:

 

[ducati]

Da wäre auch die Frage, wer sich das mit der Flanke ausgedacht hat, und was das für Vorteile haben soll?

Programmieraufgabe 1. Woche: Programmiere eine Einschaltverzögerung. Wenn IN=true ist T=T+deltaT, wenn T>=PT dann Q=true, wenn IN:= false dann T=0 kommt bei vermutlich 95% der Anfänger heraus. Wie kann man da 4 verschiedene Varianten programmieren die sich alle unterschiedlich verhalten? Und warum? Vielleicht bin ich zu doof dafür den Grund zu erkennen.

Mich würde interessieren, wie der Quellcode des perfekten Timers aussehen würde.

Ich wäre ja den einfachen weg gegangen. Und hätte bei IN True, bei jedem Aufruf die Differenz der Systemzeit zum letzten Aufruf addiert und wenn das Resultat grösser als T dann Q gesetzt.
Bei nem Sekundengenauen Timer würds vermutlich sogar langen mit dem Systemsekundentakt die zeit zu erhöhen, da muss man sich dann auch nicht um Überläufe kümmern wie wenn man Time_tck nutzt.

Naja, wenn man länger drüber nachdenkt, kommen auch bei einem selbstgeschriebenen Timer verschiedene Varianten raus...

wie haben einen selbstgeschriebenen visualisierungsfähigen Timer, da kann man von der Visu für die Laufzeit Tage/Stunden/Minuten/Sekunden einstellen und sieht die Restlaufzeit. Intern läuft die zeit aber rückwärts, also kein Überlauf nach 60 Jahren möglich... aber Timereinstellung dafür nicht während Timerlauf änderbar...

Naja

 

[Gleichstromer]

TON-Timer S7-1200/1500

c) Ändern der Zeit bei laufendem Timer von lang nach kurz nicht möglich. Ändern der Zeit bei laufendem Timer von kurz nach lang nicht möglich.

Der PT-Wert einer IEC-Zeit kann bei der 1200er (1500er dann wohl auch) mit dem Befehl "PT" (Zeitdauer laden) geändert werden, er kann sowohl verkleinert als vergrössert werden.

Solange der Timer noch nicht abgelaufen ist, kann die Zeit verringert oder vergrössert werden. Ist die geladene Zeit grösser als der aktuelle Timer-PT, wird der Timer-Q dann high.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

-----
TON-Timer S7-1200/1500

b) Wurde IN (aus welchen Beweggründen auch immer) mit TRUE aus der AS geladen und als Startwert gesetzt, dann läuft der Timer trotz IN:=true nach Neustart überhaupt nicht ab.

---

Das Verhalten ist auch noch Firmenware abhängig, mir ist letztens noch ein Projekt
von einen Kollegen vor die Füße gefallen, wo die CPU getauscht werden musste.
Bei der alten Version funktionierte es mit den "true" am "In" Eingang, bei der
neuen nicht mehr. Hab neh weile gesucht, bis ich es gefunden hatte, dabei musste
ich nur mal eben die Defekte CPU tauschen.

 

[Heinileini]

Da wäre auch die Frage, wer sich das mit der Flanke ausgedacht hat, und was das für Vorteile haben soll?

"Das mit der Flanke"? Was meinst Du damit? Die positive Flanke am 'IN' beim TON bzw. die negative Flanke beim TOF, mit der der Timer gestartet wird?
Da bin ich aber gespannt, wie Deine Variante ohne FlankenErkennung aussieht!

 

[PN/DP]

Bei einem TON bzw. EVERZ bräuchte man keine Start-Flanke. Es ist nun aber schon > 30 Jahre so, daß da explizit eine Flanke erforderlich ist, da wollte man wohl kompatibel bleiben. Das Problem besteht aber eigentlich nur, wenn die CPU neu startet und den Timer nicht neu initialisiert. Und das Problem gibt es wohl erst seit die S7-CPUs keinen Kaltstart mehr kennen.

Harald

 

[Maagic7]

Zuviel Werbung?
-> Hier kostenlos registrieren

IEC Timer bei S7300/400

da kann Siemens mal nix für. Das einzige, sie haben sich korrekt an die IEC Spezifikation gehalten.

TimerAufruf mit 0ms = RESET des Timers.
Das ist nicht die tollste Idee und deswegen wurde das bei der 1500er wieder korrigiert und Siemens
macht sein eigens Süppchen, was aber völlig egal ist, da vieles andere auch nicht 100% IEC kompatibel ist.

Eine 2te Korrektur ist, dass die IEC-Timer bei der 1500er jetzt wieder direkt den TimerAusgang durchschalten,
ohne die Multiinstanz oder einen Hilfsmerker zu verschalten. Das ist meines erachtens die bessere Methode,
jedoch wieder nicht ganz IEC konform.

 

[Thomas_v2.1]

IEC Timer bei S7300/400

da kann Siemens mal nix für. Das einzige, sie haben sich korrekt an die IEC Spezifikation gehalten.

TimerAufruf mit 0ms = RESET des Timers.
Das ist nicht die tollste Idee und deswegen wurde das bei der 1500er wieder korrigiert und Siemens
macht sein eigens Süppchen, was aber völlig egal ist, da vieles andere auch nicht 100% IEC kompatibel ist.

Eine 2te Korrektur ist, dass die IEC-Timer bei der 1500er jetzt wieder direkt den TimerAusgang durchschalten,
ohne die Multiinstanz oder einen Hilfsmerker zu verschalten. Das ist meines erachtens die bessere Methode,
jedoch wieder nicht ganz IEC konform.

Hast du die aktuelle IEC Spezifikation? Ich habe nur den letzten Draft der 2nd Edition, da ist das Verhalten bei Änderung von PT bei laufendem Timer nicht festgelegt (implementation dependent). D.h. wenn dann hat sich Siemens das selber so ausgedacht.

Genauso steht dort nirgends, dass eine Flankenauswertung stattfinden muss. Es ist steht nur geschrieben, dass die Zeit mit der steigenden Flanke gestartet wird, was sich meiner Meinung nach auf die Zeitdiagramme bezieht.

 

[DeltaMikeAir]

Thomas, nur kurz zur Info:
https://support.industry.siemens.co...-200-cpus-(et-200sp-et-200pro)?dti=0&lc=de-AT


Firmware V2.9.2 ( 1500ér )
Folgendes Verhalten wurde verbessert:

• Das Rücksetzen der TONR Anweisung funktioniert, auch wenn eine fallende Flanke am Eingang IN anliegt.
• Beim Beobachten von Variablen an der Anweisung TON_TIME werden die Werte korrekt angezeigt.