TIA Ton verschaltung

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit "Quatsch" meine ich, daß sich die IEC-Timer als FB "tarnen", sich aber überhaupt nicht wie FB verhalten. Das sich z.B. Outputs ändern ohne daß der FB aufgerufen wird!
Ich meine das Verhalten war in TIA bzw. den S7-1x00 nicht von Anfang an so, es wurde erst später eingeführt und gab prompt "böses Erwachen".

Harald

 

[PN/DP]

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

Ja, wenn ich in der Folge immer nur den Merker verarbeite und nicht den timer.q, dann ist man auf der sauberen Seite

Harald

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

Warum? Wodurch?
Selbst, wenn zwischen un t1 und se t1 der Timer ablaufen sollte und die Ausführung durch einen Alarm ausgerechnet hier unterbrochen wird, sollte das BetriebsSystem das VKE retten und unverändert für den se t1 rekonstruieren. Ebenso den AkkuInhalt mit der Zeit.

Das Beispiel in diesem Thread enspricht

UN  T1
=   Mx.y
U   T1
ZV  Z1
U   Mx.y
L   KT 5.2
SE  T1
U   T1
ZV  Z2

Das "HauptProblem" ist hier, dass bei Mx.y = false der Ausgang statTON.Q bzw. die Abfrage u t1 nicht mehr - wie fälschlicherweise erwartet - true liefert, sondern false, weil die EingangsBedingung false am Timer sofort den Ausgang statTON bzw. u t1 zu Null (false) macht. Selbstverständlich auch dann, wenn statTON bzw. u t1 weniger als 1 Zyklus lang true geliefert hätten.
Dies gilt sinngemäss auch für L T1 und LC T1 bzw. für die Abfrage statTON.ET.
Wenn man gerade erst den Timer gestoppt hat, sollte man nicht erwarten, dass er aus irgendwelchen Gründen noch läuft. Selbst dann nicht, wenn man ihn noch vor Ablauf eines kompletten Zyklus gestoppt hat.

Gruss, Heinileini

 

[Heinileini]

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.

Das ist ja auch normalerweise der Fall, der FB berechnet etwas aus den aktuellen Eingangsdaten des FB zum Zeitpunkt des Aufrufs.
Wenn aber ein Timer gestartet wird, führt der naturgemäss ein EigenLeben: die Zeit läuft immer weiter ab, unabhängig davon, wie oft und in welchen ZeitAbständen der FB aufgerufen wird. Folglich kann man eigentlich kein vergleichbares Verhalten erwarten - finde ich.

Gruss, Heinileini

PS:
Eigentlich braucht man doch keine Timer. Wenn man die aktuelle Zeit in genügender Auflösung lesen kann, was man in S5 nicht (wirklich) konnte, dann kann man sich Timer basteln, die sich so verhalten, wie man es (z.B. für einen speziellen Zweck) möchte. Ich bin mir sicher, spätestens wenn man das tut, dann versteht man auch (endlich), welche Haken und Ösen sich daraus ergeben und zu berücksichtigen sind.

Apropos TON:
Kürzlich im Radio gehört: "Ich wurde aus dem TöpferKurs geworfen - muss mich wohl im Ton vergriffen haben"

 

[PN/DP]

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

Warum? Wodurch?

Das Problem ist, daß man nach dem "SE T1" nicht mehr abfragen kann, ob der Timer abgelaufen ist, weil ein "U T1" wird da fast nie mehr TRUE. (und bei einer Abfrage "U T1" vor dem SE werden sporadisch Timerabläufe unterschlagen/nicht erkannt)

Das ist übrigens genau das typische Problem womit Fragesteller hier im Forum aufschlagen, die zwar ganz stolz einen selbstwiederholenden Taktgeber hingekriegt haben, aber die nachfolgende Verarbeitung des Timerzustands nicht funktioniert.

Problematisch:

U  T1
ZV Z0    //der Zähler zählt manchmal zu wenig

L  S5T#1S
UN T1
SE T1

U  T1
ZV Z1    //der Zähler wird fast nie zählen

Oft wird es so gemacht, das ist aber nur fast richtig:

U  T1    //T1 ist hier meistens 2 Zyklen lang TRUE!
ZV Z0    //der Zähler zählt richtig, dank eingebauter Flankenerkennung

L  S5T#1S
UN M1.0
SE T1
U  T1
=  M1.0

U  T1    //fast richtig, T1 hat nicht immer den selben Zustand wie M1.0
ZV Z1    //der Zähler zählt richtig, wenn auch manchmal einen Zyklus "zu früh" bevor M1.0 TRUE wird

So ist es ganz richtig:

U  M1.0  //so ist es ganz richtig
ZV Z0    //der Zähler zählt richtig

L  S5T#1S
UN M1.0
SE T1
U  T1
=  M1.0

U  M1.0  //so ist es ganz richtig
ZV Z1    //der Zähler zählt richtig

Und genau so muß man auch mit den IEC-Timern der S7-1x00 umgehen: NICHT Ton.Q mehrfach abfragen/verwenden, sondern auf eine Arbeitsvariable kopieren (in FUP/KOP: den Q mit einer Variable beschalten), und im Programm dann die Arbeitsvariable verarbeiten (und nicht den Ton.Q!). (Es sei denn, man weiß genau was man tut und will genau dieses azyklische Verhalten ausnutzen)

Harald

 

[nikilouder]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

Das verstehe ich nicht?! Man braucht doch den Call, da sonst der neue Q nicht berechnet wird.

 

[PN/DP]

Das verstehe ich nicht?! Man braucht doch den Call, da sonst der neue Q nicht berechnet wird.

Wenn Du noch 5 Beiträge weiterliest dann findest Du in #11

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.

Harald

 

[nikilouder]

Wenn Du noch 5 Beiträge weiterliest dann findest Du in #11


Harald

Hatte nicht gesehen, dass der Thread schon mehrere Seiten hat, Sorry.

Ich finde dieses Verhalten nicht gut. Ich möchte doch eher gezielt meine Ausgangsparameter nach jedem Call neu berechnet haben und nicht zwischendurch mal.

Das hätte ja zur Folge, dass

temp := myTimer.Q;

myBool1 := temp;
myBool2 := temp;
myBool3 := temp;

unter Umständen zu einem anderen Ergebnis führt, wie

myBool1 := myTimer.Q;
myBool2 := myTimer.Q;
myBool3 := myTimer.Q;

Je mehr Programmcode zwischen den Zuweisungen liegt, desto höher ist die Wahrscheinlichkeit. Ganz zu schweigen davon, wenn ich mit IF-Anweisung große Unterpgoramme abarbeite.

Wiederrum erklärt das wieder warum das hier bei einem TON nicht Funktioniert:

 myTimer(IN:= NOT myTimer.Q)

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wiederrum erklärt das wieder warum das hier bei einem TON nicht Funktioniert:

 myTimer(IN:= NOT myTimer.Q)

Das sollte aber schon funktionieren, wenn ein ZeitWert auch an den TON übergeben und myTimer.Q oder myTimer.ET nicht anderweitig noch abgefragt werden!?
Andererseits, wer wird einen Timer sich selbst starten lassen, wenn er nicht noch anderweitig den TimerStatus verwenden will und ihn dazu abfragen muss.
Also bleibt es dabei: nur an 1 Stelle abfragen und für mehrfache Benutzung ins "ProzessAbbild" speichern.