TIA Problem := Große Programme und mehrere TON-Timer in Multi-Instanz beißen sich?

[row-k]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Abend an Euch alle!

Nach Haralds "Anpfiff" (https://www.sps-forum.de/simatic/96328-timer-selbst-gebastelt-bitte-schreibt-eure-meinung-danke.html) habe ich mich natürlich mit den Timern beschäftigt, statt mir selbst welche zu basteln.
Das macht richtig Freude; danke nochmals an Harald!

Ich baute mein Projekt immer weiter aus, programmierte Maschine für Maschine und setzte in jede einen unabhängigen Timer (TON) ein. Insgesamt liefen die bisher eingerichteten 6 TON-Timer einwandfrei und ab dem (bösen?) siebten fand ich lange Zeit den Fehler nicht, bis ich bemerkte, dass der siebte nicht ganz bis zum Vorgabewert hochzählt.

So musste ich mich erstmal behelfen, indem ich einfach die Bedingung rund 10ms eher gelten ließ (siehe Zeile darunter). An diesen Wert musste ich mich herantasten; ab 6ms weniger klappte es meistens, ab 7ms gab es kaum noch Ausfälle und bei 10ms Abzug läuft's.

IF "Tec".Restzeit7_Time > "Tec".Taktzeit_Kartonierer - T#10ms THEN

usw. usf


Andererseits: Zufrieden bin ich nicht mit solchen "Lösungen" ... Kann jemand bestätigen, dass zu viele Timer über viel Programm-Code verstreut eben nicht mehr korrekt arbeiten?

Danke und einen schönen Abend!
Björn

 

[TP-Inc]

Ich hab bestimmt schon über 10000 IEC Timer programmiert und mir ist noch nie einer über den Weg gelaufen der nicht funktioniert hätte... bitte poste mal einen Ausschnitt von dem Code wo es Probleme gibt.

 

[row-k]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für Deine Antwort, TP-Inc.

Ich poste mal nur einen der 9 geplanten (sieben laufen schon), die sind alle gleich und der Auswerte-Baustein ist auch immer sehr ähnlich.

Mit Haltepunkten hatte ich es erst entdeckt: Die funktionieren ja; sie zählen auch alle hoch bis zum Endwert, nur kann ich den Endwert beim siebten scheinbar nicht erwischen,
darum ja mein "Minus 10ms" ...
Wenn ich den Zählerwert per Haltepunkt anschaue, steht er knapp unter dem Endwert.

[COLOR=#008000]// Zeitablauf7 = TRUE kommt vom LieFöBa, wenn das die Ware abgeworfen hat
[/COLOR]IF "Tec".Restzeit7_Time > "Tec".Taktzeit_Kartonierer[COLOR=#b22222] - T#10ms [/COLOR]THEN
        "Tec".Zeitablauf7 := FALSE; [COLOR=#008000]// damit er erst wieder vom LieFöBa angestoßen wird[/COLOR]
        "3_1_FoeBa_Kart_Unt_Befehle" ();
END_IF; [COLOR=#008000]// Vorgabe-Zeitwert vergangen[/COLOR]

Viele Grüße!
Björn

 

[row-k]

War meine Frage zu dumm?

Liegt mein Problem etwa daran, dass dadurch, dass Abarbeitung von viel Programm-Code eben auch gewisse Zeit braucht? Scheint es nur so, dass die Timer hinterherhinken?

Danke für Antworten und ein schönes Wochenende!
Björn

 

[eldon]

Hi
Natürlich braucht Abarbeitung von Code Zeit. Wie hoch ist den deine Zykluszeit?

 

[row-k]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für die Antwort! Meine Zykluszeit beträgt 1,999ms (beim Programmstart ca. 20ms) sehr konstant. Das ist ja das, was mich so wundert.

 

[Onkel Dagobert]

IF "Tec".Restzeit7_Time > "Tec".Taktzeit_Kartonierer

Diese Bedingung wäre doch nie erfüllt, oder? Warum verwendest du nicht den Ausgang Q, was doch eigentlich der Normalfall wäre?

 

[eldon]

Danke für die Antwort! Meine Zykluszeit beträgt 1,999ms (beim Programmstart ca. 20ms) sehr konstant. Das ist ja das, was mich so wundert.

Deiner Zykluszeit nach zu urteilen benutzt du eine 1200er, die zeigt das nur in einer ms Taktung an. Heisst die kann zwischen 1.5 und 2.4999 schwanken...

Aber Onkel Dagobert hat schon recht, warum ist Q nicht gut genug?

 

[row-k]

Zuviel Werbung?
-> Hier kostenlos registrieren

Diese Bedingung wäre doch nie erfüllt, oder? Warum verwendest du nicht den Ausgang Q, was doch eigentlich der Normalfall wäre?

Danke, lieber Onkel!

Doch, doch, die Bedingung wurde auch so erfüllt: IF "Tec".Restzeit7_Time = "Tec".Taktzeit_Kartonierer

Aber stimmt schon, ich werde mit Ausgang Q mal weitermachen. Da hätte ich auch selbst drauf kommen müssen.

Ein schönes Wochenende an alle!
Björn

 

[row-k]

gelöscht, wollte zitieren

 

[row-k]

Deiner Zykluszeit nach zu urteilen benutzt du eine 1200er, die zeigt das nur in einer ms Taktung an. Heisst die kann zwischen 1.5 und 2.4999 schwanken...

Aber Onkel Dagobert hat schon recht, warum ist Q nicht gut genug?

Nein, ich nehme eine 1511-1.
Auch Dir danke für's Helfen.
Gruß
Björn

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

.. Doch, doch, die Bedingung wurde auch so erfüllt: IF "Tec".Restzeit7_Time = "Tec".Taktzeit_Kartonierer ..

Der Vergleich auf "gleich" wird vermutlich funktionieren. In deinem o.g. Code vergleichst du aber auf "größer als". Wahrscheinlich ist das der Unterschied zu deinen anderen Aufrufen?

 

[row-k]

Der Vergleich auf "gleich" wird vermutlich funktionieren. In deinem o.g. Code vergleichst du aber auf "größer als". Wahrscheinlich ist das der Unterschied zu deinen anderen Aufrufen?

Nein, die ersten 6 Timer funktionieren sehr gut mit "=". Also nahm ich den siebten auch wieder so, wunderte mich und fand dann irgendwann, dass der 7. nicht mit "=" funktionierte. Also setzte ich das "> Zeit -10ms" ein (siehe Ausgangs-Post).
Ok, Ausgang Q habe ich jetzt noch nicht eingesetzt, werde ich aber noch probieren. Trotzdem ist es verwunderlich, dass ich nun Timer 7, 8 und 9 mit der Behelfslösung arbeiten lassen muss.

Wieder danke ich für's Mitdenken, lieber Onkel.

 

[RogerSchw85]

Vergleichst du den Timer an mehreren stellen im Programm?

 

[row-k]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin. Nein, alle Timer werden unabhängig voneinander nur angestoßen, um einzelne Prozesse ablaufen zu lassen. Ab dem siebten zählen sie nicht mehr bis zum Ende.

 

[Onkel Dagobert]

IEC-Timer haben die Eigenart dass sie aktualisiert werden, wenn man einen der Ausgänge "Q" oder "ET" abfragt. Das muss nicht unbedingt beim Bausteinaufruf sein, und dann müsste man auch direkt auf die Instanzdaten zugreifen. Ich denke, das ist hier aber nicht der Fall. Darauf wollte Roger wahrscheinlich hinaus.

Was mir in diesem Zusammenhang noch einfällt, verwendest du Instanzen der Timer eventuell mehrfach? Das ist ein sehr beliebter Kopierfehler, der immer mal wieder vorkommt.

Falls das Rätselraten nicht hilft, du dein Programm auch als Anhang hochladen.

 

[row-k]

IEC-Timer haben die Eigenart dass sie aktualisiert werden, wenn man einen der Ausgänge "Q" oder "ET" abfragt. Das muss nicht unbedingt beim Bausteinaufruf sein, und dann müsste man auch direkt auf die Instanzdaten zugreifen.

Das scheint auch unerhablich in meinem Fall zu sein, denn die Timer laufen ja alle "nett vor sich hin", zählen zum Teil eben nur nicht ganz hoch.

Was mir in diesem Zusammenhang noch einfällt, verwendest du Instanzen der Timer eventuell mehrfach? Das ist ein sehr beliebter Kopierfehler, der immer mal wieder vorkommt.

Hmm. Diesen Fehler hatte ich mal anfangs als Kopierfehler und bemerkte das dann. So sehen die letzten 3 Timer aus und die anderen auch. Ist das richtig?

Falls das Rätselraten nicht hilft, du dein Programm auch als Anhang hochladen.

Das wäre ja eine große Mühe für Euch, Donnerwetter und danke für so ein Angebot!!

Ich danke Dir und allen anderen Helfenden sehr. und wünsche einen schönen Sonntag.
Björn

 

[row-k]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank an alle, besonders an den Onkel, weil er mir das "Q" nahelegte! Dadurch habe ich die Erklärung gefunden, eben, als ich mir das Arbeiten mit dem Ausgang "Q" nochmals ansah. Hier das Zitat aus dem TIA-Hilfesystem:

Impulsdiagram
Das folgende Bild zeigt das Impulsdiagramm der Anweisung "Einschaltverzögerung erzeugen":

Die "Spitze" ist's im dritten Diagramm: Wenn das "IN"-Signal nicht lang genug anliegt, schafft es der Timer nicht, bis an den Vorgabewert heranzuzählen und "Q" auf "TRUE" zu schalten. Das ist in meinem, relativ großen Programm der Fall: In einem der nächsten Zyklen, die das "IN"-Signal wieder löschen, hat der Timer noch nicht bis zu Ende gezählt.

Habt einen schönen Wochenstart und viele Grüße!
Björn

 

[chrigu]

Die "Spitze" ist's im dritten Diagramm: Wenn das "IN"-Signal nicht lang genug anliegt, schafft es der Timer nicht, bis an den Vorgabewert heranzuzählen und "Q" auf "TRUE" zu schalten. Das ist in meinem, relativ großen Programm der Fall: In einem der nächsten Zyklen, die das "IN"-Signal wieder löschen, hat der Timer noch nicht bis zu Ende gezählt.
Björn

Ich denke, dann hast du ein anderes Problem als ein zu grosses Programm (Was bei 2ms nicht wirklich gross sein kann).
Wenn du einen Verzögerung abwarten willst, muss das IN-Signal immer bis zum erreichen von Q anstehen, unabhängig von der Zykluszeit! Ansonsten kannst du nicht mit eine TON arbeiten...

 

[row-k]

Ich denke, dann hast du ein anderes Problem als ein zu grosses Programm (Was bei 2ms nicht wirklich gross sein kann).
Wenn du einen Verzögerung abwarten willst, muss das IN-Signal immer bis zum erreichen von Q anstehen, unabhängig von der Zykluszeit! Ansonsten kannst du nicht mit eine TON arbeiten...

Sagte ich ja, danke für die Bestätigung.