TIA Ton verschaltung

lutre · 13 Februar 2019

Hallo zusammen,

Ich bin in alten AWL Baustein eine Konstellation gestoßen die ich einfach nicht verstehe.
Hab das ganze mal fürs Forum nachgebaut. Läuft auf einer 1500er. Quelle siehe unten.

UN #statTon.Q
= #tempBool

U #statTon.Q
ZV "Z1"

CALL #statTon
time_type:=Time
IN :=#tempBool
PT :=t#5s
Q :=
ET :=

U #statTon.Q
ZV "Z2"

Zähler Z1 zählt dabei brav alle 5 Sekunden hoch.
Zähler Z2 bleibt auf Null.

Kann mir jemand dieses Verhalten erklären?

FUNCTION_BLOCK "forum"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
VAR
statTon {OriginalPartName := 'IEC_TIMER'; LibVersion := '1.0'} : TON_TIME;
END_VAR

VAR_TEMP
tempBool : Bool;
END_VAR

BEGIN
NETWORK
TITLE =
UN #statTon.Q;
= #tempBool;

U #statTon.Q;
ZV "Z1";

CALL #statTon
{time_type := 'Time'}
( IN := #tempBool ,
PT := t#5s
);

U #statTon.Q;
ZV "Z2";

END_FUNCTION_BLOCK

Zähler "Z"

Grüße,
Luis

Paul · 13 Februar 2019

Hallo
Kann es sein, dass Z2 noch an einer anderen Stelle im Programm benutzt wird?

PN/DP · 13 Februar 2019

Du darfst #statTon.Q nur ein einziges mal im Zyklus abfragen. Wenn Du es mehrmals verknüpfen willst, dann mußt Du auf eine zweite Variable umkopieren und diese kannst Du dann so oft verwenden wie Du willst.

PS: insbesondere darfst Du #statTon.Q nicht nach dem "CALL #statTon" abfragen, wenn es gleichzeitig die Reset/Freigabe-Bedingung des #statTon ist - hinter dem CALL wird #statTon.Q höchst selten TRUE sein (es müsste gerade eben nach dem umspeichern auf #tempBool auf TRUE gegangen sein).

Harald

lutre · 13 Februar 2019

PN/DP schrieb:
Du darfst #statTon.Q nur ein einziges mal im Zyklus abfragen. Wenn Du es mehrmals verknüpfen willst, dann mußt Du auf eine zweite Variable umkopieren und diese kannst Du dann so oft verwenden wie Du willst.

Harald

Aber ich habe mein statTon.Q hier:

UN #statTon.Q
= #tempBool

U #statTon.Q
ZV "Z1"

doch schon zwei mal verwendet und da funktionierts wie erwartet

PN/DP schrieb:
PS: insbesondere darfst Du #statTon.Q nicht nach dem "CALL #statTon" abfragen, wenn es gleichzeitig die Reset/Freigabe-Bedingung des #statTon ist - hinter dem CALL wird #statTon.Q höchst selten TRUE sein (es müsste gerade eben nach dem umspeichern auf #tempBool auf TRUE gegangen sein).

Harald

Müsste das statTon.Q nach Ablauf der Zeit nicht immer genau einen Zyklus lang true sein?
Wird der Timer Ausgang synchron zum zyklus gesetzt?
Also beim Timer Call wird entschieden (elapsedTime > pt -> Q = true, elapsedTime < pt -> Q = false) ob Q gesetzt wird. Oder passiert dies unabhängig vom Call nach Ablauf der Zeit.

Bitte entschuldige dass ich so blöd nachfrage aber ich steig gerade einfach nicht durch.

Grüße,
Luis

lutre · 13 Februar 2019

Paul schrieb:
Hallo
Kann es sein, dass Z2 noch an einer anderen Stelle im Programm benutzt wird?

Leider ausgeschlossen

Howard · 13 Februar 2019

Moin,
Bei den IEC Timern brauchst du ja überhaupt keinen Call mehr, deshalb vermute ich, dass auch ein lesender Zugriff auf den statTon.Q schon eine Aktualisierung der des Timers (irgendwo im Hintergrund der CPU) ausführt. Das würde zu dem beschriebenen Verhalten passen.

Howard · 13 Februar 2019

Ich muss mich kurz korrigieren: Der Call ist in SCL nicht notwendig, dort reicht ein schreiben der statTon.IN aus, um im Hintergrund einen "Call" auszuführen.

PN/DP · 13 Februar 2019

lutre schrieb:
Aber ich habe mein statTon.Q hier:

UN #statTon.Q
= #tempBool

U #statTon.Q
ZV "Z1"

doch schon zwei mal verwendet und da funktionierts wie erwartet

Nur scheinbar. Mache mal noch einen Zähler auf #tempBool und laß das eine Weile laufen und vergleiche die Zählerstände. #statTon.Q kann sich zwischen den beiden Zugriffen ändern.

Harald

Larry Laffer · 13 Februar 2019

Ich würde das Ganze etwas anders erklären - dafür muss man sich aber den Zustand der einzelnen "Variablen" anschauen und dabei berücksichtigen, dass der TON sehr wahrscheinlich für das Setzen seines Q nicht auf den Zyklus selbst angewiesen ist. Dabei ist es m.E. vollkommen irrelevant, wie oft statTON.Q im Programmcode verwendet wird - dies ist ja schlussendlich auch nur eine Speicherstelle wie andere auch.
In diesem Programm wird der Timer gestartet, weil er ja noch nicht gestartet ist - tempBool wird also TRUE. Irgendwann ist der Timer ja dann mal durchgelaufen. In dem Fall wird, bezogen auf den Ablauf (von oben nach unten) tempBool dann False, statTON ist aber noch immer TRUE (wenn auch nur für einen Zyklus), der Zähler 1 dann also hochzählen. Nun kommt der Aufruf des StatTON selbst, bei dem seiner TriggerVariable tempBool ja nun FALSE ist - somit ist von dem Moment an StatTON.Q auch nicht mehr TRUE. Folglich bekommt Zähler 2, dessen Aufruf ja nach dem des statTON kommt, nichts mehr vom ganz kurzen TRUE-sein des statTON.Q mit.

Code:

UN    #statTon.Q
      =     #tempBool

      U     #statTon.Q
      ZV    "Z1"

      CALL  #statTon
         time_type:=Time
         IN :=#tempBool
         PT :=t#5s
         Q  :=
         ET :=

      U     #statTon.Q
      ZV    "Z2"

... anders macht es für mich keinen Sinn und so ist es für mich auch logisch und nachvollziehbar ...

Gruß
Larry

lutre · 13 Februar 2019

Alles klar, ich war der festen Überzeugung bei IEC Timern wird der Status Q des Timers nur zum Zeitpunkt des Calls verändert.

In Betrachtung dass sich Q unabhängig vom Zyklus bzw vom Call ändern kann, ist klar dass es sehr sehr unwarscheilich ist dass der Timer zwischen Timer Call und Zähler Z2 inkrementieren überläuft.

Danke an alle für die Hilfe!

hucki · 13 Februar 2019

lutre schrieb:
Ich bin in alten AWL Baustein eine Konstellation gestoßen die ich einfach nicht verstehe.
Hab das ganze mal fürs Forum nachgebaut. Läuft auf einer 1500er.

lutre schrieb:
Alles klar, ich war der festen Überzeugung bei IEC Timern wird der Status Q des Timers nur zum Zeitpunkt des Calls verändert.

In Betrachtung dass sich Q unabhängig vom Zyklus bzw vom Call ändern kann, ist klar dass es sehr sehr unwarscheilich ist dass der Timer zwischen Timer Call und Zähler Z2 inkrementieren überläuft

TIA-Hilfe F1 schrieb:
TON: Einschaltverzögerung erzeugen (S7-1500)

...
Die Aktualisierung der Anweisungsdaten geschieht in den folgenden Fällen:

Bei einem Aufruf der Anweisung, wenn die Ausgänge ET oder Q verschaltet sind. Wenn die Ausgänge nicht verschaltet sind, dann wird der aktuelle Zeitwert am Ausgang ET nicht aktualisiert.

Bei einem Zugriff auf die Ausgänge Q oder ET.

Da gibt's auch schon einige Threads zu.

Heinileini · 13 Februar 2019

Larry Laffer schrieb:
Irgendwann ist der Timer ja dann mal durchgelaufen. In dem Fall wird, bezogen auf den Ablauf (von oben nach unten) tempBool dann False, statTON ist aber noch immer TRUE (wenn auch nur für einen Zyklus), . . .

Hallo Ralf,
Du schreibst "wenn auch nur einen Zyklus". Ich glaube hier liegt der GedankenFehler. Der statTON.Q-Impuls ist kürzer als 1 Zyklus.
Wenn statTON = true, dann ist TempBool = false. Damit wird dann auch der Eingang IN des TON false und dadurch wird auch der TrueZustand des statTON unverzüglich beim CALL beendet. Unmittelbar nach dem CALL ist statTON immer false. Vor dem CALL wird statTON erst wieder true wenn die Zeit abgelaufen ist.

Gruss, Heinileini

PN/DP · 14 Februar 2019

Heinileini schrieb:
Unmittelbar nach dem CALL ist statTON immer false.

Das ist nicht richtig. Wenn die Zeit zwischen der Zuweisung des #statTon.Q an #tempBool und dem CALL abläuft, dann wird der TON beim CALL nicht rückgesetzt und #statTon.Q ist nach dem CALL noch TRUE (und Z2 zählt 1 hoch!). Wie ich in #3 schrieb

PN/DP schrieb:
hinter dem CALL wird #statTon.Q höchst selten TRUE sein (es müsste gerade eben nach dem umspeichern auf #tempBool auf TRUE gegangen sein).

Larry Laffer schrieb:
... anders macht es für mich keinen Sinn und so ist es für mich auch logisch und nachvollziehbar ...

Jaaa, was für uns S7-Anwendungs-Programmierer logisch und sinnvoll ist, und das was Siemens dafür hält, ist leider nicht immer das selbe.

Ich vermute: Siemens war es irgendwann mal leid, daß immer wieder Support-Anfragen kamen "warum funktioniert mein Timer nicht, wenn ich ihn nur einmal bedingt aufrufe" ... und anstatt daß die S7-Programmierer zu lernen haben wie sie es richtig machen müssen, hat es Siemens gut gemeint (was bekanntlich das Gegenteil von gut ist) und hat diesen Quatsch mit der Aktualisierung des TON.Q außerhalb des CALL bei bloser Abfrage des TON.Q oder TON.ET eingeführt ... :roll:

Harald

Ralle · 14 Februar 2019

PN/DP schrieb:
Du darfst #statTon.Q nur ein einziges mal im Zyklus abfragen.

Harald

Warum sollte das so sein und wie wird das begründet?

Heinileini · 14 Februar 2019

Ralle schrieb:
Warum sollte das so sein und wie wird das begründet?

Das lässt sich doch in dem ProgrammSchnipsel dieses Thread wunderbar nachvollziehen!
Wenn statTON.Q den einen Zähler immer inkrementiert und den anderen fast nie.
Der Trick ist eben der, dass statTON.Q NICHT exakt einen Zyklus lang ansteht, sondern maximal einen Zyklus lang.
Im Programm haben wir hier 3 Stellen, an denen statTON.Q abgefragt wird.
Wenn die Zähler mit UN tempBool getriggert werden, tritt das "Problem" nicht auf . . . dann steht statTON.Q exakt 1 Zyklus lang an.

Gruss, Heinileini

hucki · 14 Februar 2019

Ralle schrieb:
Warum sollte das so sein und wie wird das begründet?

Damit:

TIA-Hilfe F1 schrieb:
TON: Einschaltverzögerung erzeugen (S7-1500)

...
Die Aktualisierung der Anweisungsdaten geschieht in den folgenden Fällen:

Bei einem Aufruf der Anweisung, wenn die Ausgänge ET oder Q verschaltet sind. Wenn die Ausgänge nicht verschaltet sind, dann wird der aktuelle Zeitwert am Ausgang ET nicht aktualisiert.

Bei einem Zugriff auf die Ausgänge Q oder ET.

Die IEC-Timer der S7-1x00 verhalten sich also wie S5-Timer mit den gleichen Problemen durch eine mögliche azyklische Zustandsänderung.

PN/DP · 14 Februar 2019

Ralle schrieb:
PN/DP schrieb:

Du darfst #statTon.Q nur ein einziges mal im Zyklus abfragen.

Harald

Zum Vergrößern anklicken....

Warum sollte das so sein und wie wird das begründet?

Weil sich #statTon.Q asynchron zum Zyklus ändert und deshalb bei mehreren Abfragen verschiedene Zustände haben kann (selbst innerhalb eines FUP/KOP-Netzwerks). Und das auch noch abhängig davon ob man vor oder nach dem CALL abfragt. Damit man den Timerzustand konsistent über den ganzen Zyklus an jeder Programm-Stelle mit dem gleichen Wert hat, darf man #statTon.Q nur einmal abfragen und muß es für Mehrfachverwendung auf eine zweite Arbeits-Variable kopieren (quasi "Prozessabbild" des Timers). Das ist das gleiche Problem wie bei der priorisierten BuB-/HMI-Kommunikation ohne Zykluskontrollpunkt. Wenn man sich asynchron ändernde Variablen ohne ein Prozessabbild (Arbeits-Kopie) mehrfach verknüpft oder per IN_OUT an Bausteine übergibt, dann wird das Programm die meiste Zeit den Anschein von ordnungsgemäßer Funktion erwecken, man fängt sich aber unerklärliche "hochsporadische" Fehlfunktionen ein.

Harald

Heinileini · 14 Februar 2019

PN/DP schrieb:
. . . hat es Siemens gut gemeint (was bekanntlich das Gegenteil von gut ist) und hat diesen Quatsch mit der Aktualisierung des TON.Q außerhalb des CALL bei bloßer Abfrage des TON.Q oder TON.ET eingeführt . . .

Na ja, als Quatsch empfinde ich das nicht. Warum fragt man ab? Um den aktuellen Zustand zu erfahren. Wäre der Zustand dann nicht aktualisiert, würden alle sich darüber beschweren!
Ich finde, Siemens kann doch nichts dafür, wenn eine Zeit "azyklisch" abläuft.
Was heisst überhaupt "zyklisch"? Gemeint ist doch damit immer(?) der OB1-Zyklus. Soll man die abgelaufene Zeit zwischen Punkt A und Punkt B im Zyklus nicht mittels eines Timers "messen" können? Soll man denn die Timer in anderen Zyklen (WeckAlarmen) nicht benutzen dürfen? Oder soll sich jeder Timer merken, in welchem Zyklus er gestartet wurde und soll er dann nur in diesem einem Zyklus zyklisch aktualisiert werden? Dann ist er doch trotzdem in den anderen Zyklen wieder azyklisch.
Wer ein ProzessAbbild der Timer (oder auch nur eines Timers) benötigt - warum auch immer - der macht sich eines. Fertig ist die Laube.
Startet man in einem Zyklus einen Timer sofort wieder, sobald er abgelaufen ist, so hat man es doch schon mit zwei verschiedenen Zyklen zu tun:
1. den OB1-Zyklus oder z.B. einen WeckAlarmZyklus, der den Timer startet und
2. den Zyklus, der sich im Takt der ablaufenden Zeit abspielt.
Und niemand erwartet, dass diese identisch sind.
Dass dabei genau das Problem auftritt, das hier speziell für Timer betrachtet wird, allgemeinerer Natur ist, sollte schon klar sein und nicht den Timern in die Schuhe geschoben werden.
Natürlich gibt es verschiedene Möglichkeiten für das BetriebsSystem, das Verhalten der Timer zu realisieren. Aber, ob ein anderes Verhalten sinnvoller wäre . . . z.B. in Hinblick auf die vom BetriebsSystem verbratene Zeit für die Verwaltung der Timer?

Gruss, Heinileini

volker · 14 Februar 2019

Ich habe eigentlich nicht gewuss, das die t-timer auch azyklisch laufen. also genau das gleiche verhalten wie die s5-timer.

um sicher über einen zyklus einen s5-timer zu haben hängt man ja auch einen merker dran

'das könnte problematisch werden
l s5t#1s
un t1
se t1

also macht man das ja so
l s5t#1s
un m1.0
se t1
u t1
= m1.0

kann man sagen, dass wenn ich an den timer.q einen merker schreibe das gleiche verhalten hätte?

Ralle · 14 Februar 2019

@Volker

Ja, das dachte ich auch.
Solange man den TON selbst nicht aufruft, passiert bis zum nächsten Aufruf im Zyklus nichts damit. Ist wohl Falsch, siehe Hucki!
Das Aufruf von .Q schon ausreicht hatte ich nicht mehr auf dem Schirm.
Finde ich nicht so toll, denn ich meine, man sollte eine Funktion komplett aufrufen, um sie auszuführen, der "Rest", also Aufruf von .Q, sollte nur eine Abfrage des Zustandes beim letzten Aufruf sein.
Aber wenn es nun einmal so gemacht ist ... müssen wir immer dran denken.

TIA Ton verschaltung

Level-2

Level-2

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-2

Level-2

Level-1

Level-1

User des Jahres 2011-2013; 2015-2017; 2020-2022

Super-Moderator , User des Jahres 2008-2009

Level-2

User des Jahres 2014

Level-3

User des Jahres 2011-2013; 2015-2017; 2020-2022

Super-Moderator , User des Jahres 2006-2007

Level-3

User des Jahres 2014

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-3

Supermoderator

Super-Moderator , User des Jahres 2006-2007

Similar threads

Wir schützen deine Privatsphäre