TIA S5-Timer vs. IES-Timer

Outrider

Level-1
Beiträge
745
Reaktionspunkte
5
Zuviel Werbung?
-> Hier kostenlos registrieren
Sind IEC-Timer sicherer (zuverlässiger) als S5-Timer ?
Wenn Nein, warum werden im Safety-Teil nur IEC-Timer angeboten ?
Wenn ja, warum werden immer noch S5-Timer im Standardprogramm
Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich meine die sind beide zuverlässig.
Aber IEC Timer sind besser als S5-Timer für mehrere Gründe.
Die S5-Timer sind nur da wegen rückwärtskompatibilität. In 2050, wenn es noch S7 Steuerungen gibt (mit STEP7-AI selbstprogrammiert !), wird es auch S5-Timer geben.
 
Für moderne, wiederverwendbare Programmierung sind mMn S5 Timer absolut nicht zu gebrauchen. Funktionieren tun natürlich beide zuverlässig.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Onkel:
ganz sicher ...? Meinst du nicht, dass Chuck da doch etwas anderes an der Stelle bevorzugen würde ...?

@Outrider:
Es gibt hinsichtlich der Funktionssicherheit sicherlich keine Unterschiede zwischen S5- und IEC-Timern. Lediglich haben IEC-Timer einen wesentlich größeren Zeitbereich und ich kann sie unproblematisch zum Bestandteil einer Baustein-Instanz machen.
Bei Safety sieht das dann wieder ein bißchen anders aus. Hier muß eine Funktionalität ja wieder bestimmte Bedingungen erfüllen. Der Safety-IEC-Timer ist zwar nach außen hin (also in der Anwendung) identisch mit dem Standard-IEC-Timer - im Innenleben aber ganz sicher nicht.

Gruß
Larry
 
@Larry
waren in der distributed safety Variante (Classic-Welt ) die Timer auch IEC, ich bin erst im TIA vor ca. einem Jahr in die Safety-Welt hinzugekommen
Danke an alle !
 
Sind IEC-Timer sicherer (zuverlässiger) als S5-Timer ?
Wenn Nein, warum werden im Safety-Teil nur IEC-Timer angeboten ?
Wenn ja, warum werden immer noch S5-Timer im Standardprogramm
Gruß

Der Unterschied zwischen den S5-Timern und den IEC-Timern ist bei S7 Classic ein recht grober:

Die S5-Timer werden von der Firmware direkt bearbeitet - jeder Timer hat seine fixe Speicherstelle und seinen Platz in Scheduler, wann er dran kommt. Das ganze geschieht im Hintergrund, parallel zur Ausführung des Anwenderprogramms. Fragt man den Timer ab, so bekommt man immer den aktuellen Zustand.
Wenn man nun in einem AWL-Programm folgendes rein schreibt:
Code:
UN M0.1
L S5T#100MS
SE T0

X T0
X T0
= M0.0

U T0
= M0.1
Kann es sporadisch vorkommen, dass M0.0 = TRUE wird - die Wahrscheinlichkeit ist niedrig.
Ich hatte schon Situationen, wo ein S5-Timer im OB1 mehrfach abgefragt wurde, zwischen den Abfragen waren einige 100 Zeilen AWL-Code auf einer 314er-CPU V1.2 (also eine langsame Krücke). Da ist die Wahrscheinlichkeit, dass das Phänomen auftritt, schon im Bereich von einigen %.
Vermeiden lässt sich dieses Phänomen, indem man einen Timer grundsätzlich nur 1 mal abfragt, auf einen Merker legt und nur noch den Merker weiterverwendet (wurde auch so bei uns in die Norm aufgenommen).

Bei IEC-Timern existiert dieses Phänomen nicht, da der Ausgang Q immer nur dann aktualisiert wird, wenn ein TON-Aufruf mit der entsprechenden Instanz ausgeführt wird.


Zum Thema Safety:
Wer sich schon mal Gedanken darüber gemacht hat, wie Siemens auf den S7-Steuerungen seine Sicherheit erreicht, dem ist vermutlich aufgefallen, dass jedes Stück F-Code doppelt abgearbeitet wird. Der erste "Kanal" ist jenes Programm, das der Anwender schreibt. Der zweite "Kanal" wird vom Compiler generiert. Der F-CALL kümmert sich darum, dass beide Kanäle aufgerufen werden und dass beide Kanäle das gleiche liefern.
Ein sicherer IEC-Timer lässt sich so recht einfach implementieren, indem der F-CALL die Systemzeit abspeichert, dann die beiden redundanten Timer (nacheindander - mit viel Zeit dazwischen) abarbeitet - die sich beide auf die gespeicherte Systemzeit beziehen - und am Ende prüft der F-CALL wieder, ob beide Timer das gleiche ausgeben und ob die gespeicherte Systemzeit eh nicht manipuliert wurde. Ich weiß nicht, wie genau das Siemens implementiert - aber soweit weg von der Realität bin ich wohl nicht.
Das ganze nun mit S5-Timern zu realisieren - wo zum Einen der Zeitpunkt, an dem der Timer abgefragt wird, für das Ergebnis eine Rolle spielt, zum Anderen die Timerbildung im Hintergrund in der Firmware geschieht (wie zum Teufel prüft man das) - ist imho zwar möglich - aber praktisch kaum zu realisieren - und vor allem auch nicht sinnvoll.


lg
 
Die S5-Timer werden von der Firmware direkt bearbeitet - jeder Timer hat seine fixe Speicherstelle und seinen Platz in Scheduler, wann er dran kommt. Das ganze geschieht im Hintergrund, parallel zur Ausführung des Anwenderprogramms. Fragt man den Timer ab, so bekommt man immer den aktuellen Zustand.
------------
Bei IEC-Timern existiert dieses Phänomen nicht, da der Ausgang Q immer nur dann aktualisiert wird, wenn ein TON-Aufruf mit der entsprechenden Instanz ausgeführt wird.
Das gilt aber auch nur mehr bei den IEC-Timern auf S7-300/400.
Auf den 1200/1500 wird das Timer-Ergebnis auch bereits wieder bei jeder Abfrage von .Q oder .ET aktualisiert.
Insofern kann es hier auch wieder unterschiedliche Ergebnisse bei Mehrfach-Abfragen im Code geben.
Wie dieses Verhalten in der Steuerung umgesetzt wird (Firmware oder Compiler) weiß ich nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das gilt aber auch nur mehr bei den IEC-Timern auf S7-300/400.
Auf den 1200/1500 wird das Timer-Ergebnis auch bereits wieder bei jeder Abfrage von .Q oder .ET aktualisiert.

Eigentlich wollte ich ja grade wild über diese Antwort herziehen - aber diesen Unsinn hat Siemens tatsächlich in den Compiler eingebaut und es lässt sich mittels Trace auch nachvollziehen. Wer braucht denn sowas?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also, ich war ja irgendwie noch nie so n grosser Fan von Siemens, aber was ich hier gelesen habe über S5-Timer, IEC-Timer und die "safety Timer"...also...wie soll man da noch durchblicken?
Hab ich so komplexe Vorgänge bisher bei meinen geliebten Wago Steuerungen einfach noch nicht entdeckt oder ist das einfach eine Eigenheit von Siemens?

Ich meine, ich war ja schon beim Umstieg von der Logo!Soft Comfort v7 auf die v8 aufgeschmissen, weil ich in einem Timerbaustein verzweifelt nach der Möglichkeit gesucht habe, auf den errechneten Wert einer Arithmetischen Anweisung zu verweisen.
Ich kam einfach nicht drauf. Am Schluss hat mir dann n Kollege gesagt, dass man bei Logo!Soft Comfort v8 jetzt unter den Bausteinen die Parameterliste ausklappen und die Parameter mit einer "Leitung" verbinden muss. Als hätt ich nicht schon genügen Linien die sich über mein Arbeitsblatt schlängeln.

Macht Siemens extra immer alles n ecken komplizierter? Versteh ja auch nicht, warum bei TIA jeder FB einen eigenen DB erhält. Was ist da die Überlegung dahinter?
(Also, klar, jeder FB braucht einen Speicher für seine Werte, das ist ja der Unterschied zum FU Baustein. Aber warum macht man die DBs für den User sichtbar und lösst die nicht wie bei CoDeSys im Hintergrund?)
 
Versteh ja auch nicht, warum bei TIA jeder FB einen eigenen DB erhält. Was ist da die Überlegung dahinter?
Das ist erstens historisch gewachsen und hat zweitens den Vorteil, daß beim Hinzufügen oder Löschen von Instanzen die anderen Instanzen ihre Aktualdaten nicht verlieren.
Wenn man will, kann man in TIA aber auch alle Instanzen in nur einen DB packen (Stichwort "Multiinstanz") - dann gehen aber nach Änderungen beim dann nötigen in-die-CPU-Laden des Multiinstanz-DB die Aktualdaten aller im Multiinstanz-DB enthaltenen Instanzen verloren.

Harald
 
Wenn man will, kann man in TIA aber auch alle Instanzen in nur einen DB packen (Stichwort "Multiinstanz") - dann gehen aber nach Änderungen beim dann nötigen in-die-CPU-Laden des Multiinstanz-DB die Aktualdaten aller im Multiinstanz-DB enthaltenen Instanzen verloren.

Stimmt – wenn die Entwicklungsumgebung das nicht abfangt, dann gehen die Aktualdaten verloren…! :confused:ROFLMAO::s17:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
die Entwicklungsumgebung

TIA ist Keine Entwicklungsumgebung, genauso wenig wie Paint unter Win98 auch Kein Bildbearbeitungsprogramm ist :)
(Nur das bei dem Vergleich TIA/Entwicklungsumgebung zu PaintWin98/Bildbearbeitungsprogramm eindeutig Paint als eher zugehörig hervor geht :D )

Aber Ronin: Wenn das ja jetzt alles IEC-S5-Timer sind... Wie verhält sich das denn jetzt mit den Timern in Safety? *g* Mir wäre gerade so als würden bald einige ein böses Erwachen erleben...

MfG Fabsi

MfG Fabsi
 
Eine Arbeitsbeschaffungsmaßnahme oder ein Problemgenerator für Probleme die man früher gar nicht kannte... Den Sarkasmus darfst du allerdings nie aus den Augen verlieren ;)

MfG Fabsi
 
Zurück
Oben