TIA Verhalten von IEC-Timern (TIA)

MarkusP

Level-2
Beiträge
324
Reaktionspunkte
31
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo liebes Forum,

nach längerer Abstinenz im Forum eine Frage zu den IEC-Timern.

Ich habe die Anforderung, Zeitgeber "stoppen" zu können. Das bedeutet bei einem TP oder TOF den Ausgang
bei fehlender Freigabe abzuschalten. Mit einem nachgeschalteten AND funktioniert das nicht sauber, da der Zeitgeber
unabhängig davon weiterläuft; sollte dann die Freigabe wieder kommen wäre der Ausgang auch wieder da.
Nun verwende ich RT um die Zeit zurückzusetzen. (und damit auch den Ausgang) So weit, so gut....

Was mir aber nicht klar war, dass RT den gesamten Inhalt des IDB zurücksetzt!?

Selbst wenn der Eingang IN am Timer ansteht, ist die Variable IN im IDB FALSE.
Ist natürlich nicht ganz so toll, wenn man irgendwo im Programm auf die Bausteingänge lesend zugreift.
Mir wäre noch nie in den Sinn gekommen, in einem FB Eingänge zu überschreiben. Mir ist klar, dass die
Eingänge in eimen FB einzelne Variablen in einem IDB sind, aber bitte wer löscht Eingangsdaten?
Dafür gibt es doch die IN/OUT Deklaration.

Ebenso verhält es sich mit einem noch nie gestarteten Timer, dort hat dann PT im IDB den Startwert.

Ist das Verhalten des IEC-Timer eventuell so in der IEC definiert?

Vielleicht gibt es jemand hier im Forum, der mich aufklären kann, in der Hilfe finde ich nichts dazu.

PS: Bei Bedarf hätte ich Screenshots, da ich das Verhalten einfach nicht glauben konnte

Schönes WE
Markus
 
Ich habe die Anforderung, Zeitgeber "stoppen" zu können. Das bedeutet bei einem TP oder TOF den Ausgang
bei fehlender Freigabe abzuschalten. Mit einem nachgeschalteten AND funktioniert das nicht sauber, da der Zeitgeber
unabhängig davon weiterläuft; sollte dann die Freigabe wieder kommen wäre der Ausgang auch wieder da.
Wie soll sich der Timer Deinen Wünschen entsprechend denn verhalten?
- dass der "gestoppte" Timer weiterläuft, das stört Dich anscheinend.
- dass der Ausgang noch aktiv ist, wenn die Freigabe wiederkommt und der Timer noch nicht abgelaufen ist, stört Dich anscheinend auch.
Welche Wirkung soll denn durch das "Stoppen" des Timers erzielt werden?
Willst Du den aktuellen ZeitWert im Moment des Stoppens auswerten?
Willst Du evtl den Timer beim Wiederkommen der Freigabe ab dem bei Beginn des Stoppens erreichten ZeitWert weiterlaufen lassen?
Kommt die Freigabe normalerweise, bevor der Timmer gestartet werden soll?
Wodurch soll der Timer gestartet werden?
Sag doch einfach mal, welches zeitliche Verhalten Du haben willst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Heinileini,

mir geht es gar nicht mehr so darum was der RT Befehl intern im IEC-Timer macht, sondern dass offenbar der IEC-Timer die Bausteineingänge im IDB überschreibt.
Ich habe nicht erwartet, dass ein gesetzter Eingang am FB-Eingang im IDB FALSE wird :shock:

IEC-Timer #1.jpg
 
Ich zähle für Timer, die man anhalten und weiterlaufen lassen muss nur noch Impulse
des Systemtaktes in 1/10sec oder 1sec. Das ist viel einfacher und leichter zu handeln.
Die Genauigkeit sollte ausreichen bzw. eigentlich gar nicht von der Genauigkeit der
Timer abweichen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...also wenn ich in einem Baustein eine Flanke brauche, mache ich die im Baustein mit lokalen Variablen selber.
Ich wäre noch nie auf die Idee gekommen, ein Bausteineingang zu überschreiben. Muss mal in der IEC61131
nachlesen, ob das überhaupt vorgesehen ist.
 
Muss mal in der IEC61131 nachlesen, ob das überhaupt vorgesehen ist.
Kannst du Dir sparen, da diese Timer eh' nicht der Norm entsprechen:
- die Timer werden auch beim (nur) Auslesen von .Q und/oder .ET aktualisiert!
- RT fummelt von außen in den Instanzdaten herum (wie Du schon selbst bemerkt hast; allerdings muss man RT ja auch nicht nutzen, denn das sieht die IEC61131 vermutlich ebenfalls nicht vor)

Die Siemens IEC-Timer sind IMHO ein Kompromiss aus Standard-IEC- und Siemens-S5-Timern.
 
...also wenn ich in einem Baustein eine Flanke brauche, mache ich die im Baustein mit lokalen Variablen selber.
Ich wäre noch nie auf die Idee gekommen, ein Bausteineingang zu überschreiben.
Die FlankenErkennung ist leider ein DauerBrennerThema, das gerne immer wieder zu Missverständnissen führt.
Du schreibst von "lokalen Variablen". Der allgemeine Begriff "Variable" ist schon mal gut, denn man kann das Thema etwas allgemeiner betrachten.
Wenn von Flanken (positiven und negativen) die Rede ist, dann meint man die Erkennung, ob eine boolsche Variable (1 Bit) ihren Zustand geändert hat.
Man vergleicht dazu den aktuellen Zustand der Variablen mit dem Zustand, den die Variable im vorherigen Zyklus gehabt hat.
Der Zustand, den die Variable im vorherigen Zyklus hatte, ist aber nicht mehr verfügbar - es sei denn, man hat ihn im vorherigen Zyklus in eine Variable kopiert, die bis zum aktuellen Zyklus ihren Inhalt nicht verändert. Lokale Variablen eignen sich dafür also nicht, weil sie im Baustein nur vom Beginn bis zum Ende des Bausteins verfügbar sind. Nach dem Verlassen des Bausteins bis zum nächsten Durchlaufen des Bausteins (z.B. im nächsten Zyklus), hat das BetriebsSystem den für die lokale Variable benutzten SpeicherPlatz aber anderen Bausteinen als lokale Variable zur Verfügung gestellt.
Um den "alten" Zustand der zu beobachtenden Variable für den Vergleich mit dem aktuellen Zustand zu retten, ist eine lokale Variable also definitiv nicht geeignet.
Eine globale Variable wäre möglich, aber nur, wenn diese nicht gleichzeitig den alten Zustand mehrerer zu beobachtenden Variablen retten soll. Deshalb wird pro Instanz eine (andere!) Variable zum Speichern des alten Zustandes benötigt.
Wie angedeutet gilt dies nicht nur für BitVariablen, die man auf eine Veränderung ihres Zustandes prüfen will, sondern ganz allgemein auch für Bytes, Worte, DoppelWorte u.s.w..

Sooo, wie kommst Du zu der Annahme, dass ein BausteinEingang überschrieben wird?
Meinst Du damit, dass das Bit, das Du auf eine Veränderung prüfen willst, überschrieben wird? Wird es doch nicht!
Das Bit wird bei BausteinBeginn in eine lokale Variable kopiert. Diese lokale Variable wird mit dem alten im IDB gespeicherten Zustand verglichen und der aktuelle Zustand (die lokale Variable) wird danach als alter Zustand für den nächsten Zyklus im IDB gespeichert. Beiden Variablen hat man (eher nicht zufällig, sondern absichtlich) scheinbar (nicht "anscheinend"!) denselben symbolischen Namen gegeben. Bist Du darauf hereingefallen?

Gruss, Heinileini
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich zähle für Timer, die man anhalten und weiterlaufen lassen muss nur noch Impulse
des Systemtaktes in 1/10sec oder 1sec. Das ist viel einfacher und leichter zu handeln.
Die Genauigkeit sollte ausreichen bzw. eigentlich gar nicht von der Genauigkeit der
Timer abweichen.

An dem Punkt bin ich auch schon angekommen, aber wir haben nun 2020 und nicht STEP3...
Aber langsam glaub ich's Dir :-?

Lg
 
Sooo, wie kommst Du zu der Annahme, dass ein BausteinEingang überschrieben wird?
Meinst Du damit, dass das Bit, das Du auf eine Veränderung prüfen willst, überschrieben wird? Wird es doch nicht!
Das Bit wird bei BausteinBeginn in eine lokale Variable kopiert. Diese lokale Variable wird mit dem alten im IDB gespeicherten Zustand verglichen und der aktuelle Zustand (die lokale Variable) wird danach als alter Zustand für den nächsten Zyklus im IDB gespeichert. Beiden Variablen hat man (eher nicht zufällig, sondern absichtlich) scheinbar (nicht "anscheinend"!) denselben symbolischen Namen gegeben. Bist Du darauf hereingefallen?

Hallo Heinileine,
das wird es sein, Danke!

Wie man es aber schafft, zwei "Variablen" den selben Namen zu geben ist mir unklar. Geht in einem selbstgeschriebenen Baustein nicht oder?
Geht sicher nur, da es ein Baustein von TIA ist. Würde man einen klassischen IEC Timer programmieren, wäre die Schnittstelle des Bausteines auch anders,
da gäbe es dann IN und OUT Variablen. Die Variablen gleich zu benennen finde ich aber aus o.a. Gründen trotzdem nicht super!

Zudem war für mich nicht sofort ersichtlich, auf welche Variable ich mit fbZeit1.IN zugreife, aber Du hast recht, das sind die #static Variablen und eben nicht
die "Eingangsvariable" im Baustein, da es die ja gar nicht gibt... Wie gesagt, die Vairablen aber gleich zu benennen finde ich in dem Zusammenhang sehr irreführend.
Mein Problem ist halt, dass ich bei Verwendung mehrerer Timer mit dem selben Eingang eben immer auf die IN Variable des ersten zugegriffen habe um Kopierfehler
zu vermeiden. Da dies aber (wie ich jetzt gelernt habe) nicht der Eingang IN sondern die #static Variable IN ist, weißt Du was passiert, wenn der erste Timer
über RST resetet wird.

Der von mir beschriebene Code kommt übrigens von einer anderen Plattform (Codesys, SCL) und wurde mit einem Tool importiert, da denkst Du über sowas nicht mehr nach...
Werde mir selber einen "echten" IEC-Timer basteln.

Danke und Lg
Markus
 
Zurück
Oben