Die Funktion Time(), gibt ja die Zeit (in Milisek.) seit Systemstart zurück. Doch denke ich, dass die nicht Jahre lang nur immer aufwärts zählen kann. Irgend wann, kommt doch sicher ein Ueberlauf, wo die Ausgangs-Variable wieder von Null beginnt zu zählen.
Bei welchem Wert kommt der Ueberlauf?
Was passiert mit einem Timer, der auf dieser Funktion basiert?
Angenommen, ich addiere 3 Seckunden vor diesem Ueberlauf, noch 6 Sekunden zu meiner Referenz-Variable (vom Typ TIME). Hat dann diese Variable in bezug auf den Timer plus 3 Sekunden und der Timer auch, so dass mein Zeit-Ablauf nur 6 Seckunden beträgt, und nicht wer weiss wie lange?
Mit freundlichen Grüssen! Pitsch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Da beim Rechnen mit der gleichen Anzahl Bits gerechnet wird kürzt sich der Überlauf quasis von alleine raus, zumindest solange mit Addition/Subtraktion gearbeitet wird.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gibt es da eine einfache Methode, um das zu simulieren. Damit ich sehen kann, wie sich ein Spezialtimer in dieser Situation verhält?
Uebrigens noch etwas für den Administrator:
Der Timerbaustein TP_R in der OSCAT.LIB 1.7 ist sehr warscheinlich fehlerhaft. Der kann hängen bleiben. Ich habe jetz ein paar Mal Störungen in einer meiner Anlagen gehabt. Es stellte sich immer heraus, dass dieser Timer hängen blieb (Der Ausgang blieb auf TRUE). Der Baustein funktioniert 100 x tadellos und plötzlich bleibt er hängen.
Darum eigentlich meine Frage.
Ich habe jetzt selber einen solchen Baustein Programmiert. Der Code ist ein bisschen einfacher als in TP_R. Seither hatte ich keine Störungen mehr.
Mit freundlichen Grüssen! Pitsch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Meine Steuerung ist eine Wago 750-841. Für meine Projekte, brauche ich fast ausschliesslich diesen Typ. Gegenwärtig mit Firmware 11.
Ich habe den Baustein jetzt so programmiert:
FUNCTION_BLOCK ZEIT_RETRIG
VAR_INPUT
EIN : BOOL;
PULS_ZEIT : TIME;
END_VAR
VAR_OUTPUT
OUT : BOOL := FALSE;
END_VAR
VAR
FLANKE : BOOL := FALSE;
HALTEZEIT : TIME := t#0ms;
Aktuelle_Zeit:TIME;
END_VAR
( Nachtriggerbarer Timer )
IF (EIN = TRUE AND FLANKE = FALSE) THEN (Wenn Steigende Flanke an Eingang)
HALTEZEIT := TIME() + PULS_ZEIT;(HALTEZEIT mit Systemzeit + PULS_ZEIT initialisieren)
END_IF;
FLANKE := EIN; (Flankenmerker zurücksetzen)
Aktuelle_Zeit := TIME(); (Nur zur Kontrolle)
IF TIME() <= HALTEZEIT THEN (Wenn Systemzeit kleiner als HALTEZEIT)
OUT := TRUE; (Ausgang auf TRUE setzen)
ELSE(Wenn Systemzeit grösser als HALTEZEIT (Zeit also abgelaufen))
OUT := FALSE; (Ausgang auf FALSE setzen)
END_IF;
So funktioniert es fehlerfrei.
Nur möchte ich gerne genau wissen, was hier passiert, wenn dieser Timer ein paar Seckunden vor einem Ueberlauf gestartet wird und die Endzeit sich nach dem Ueberlauf befindet.
Mit freundlichen Grüssen! Pitsch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
habe mittlerweile den tp_r nochmals getestet und keinerlei fehler gefunden.
kannst du mir dein projekt senden?
in deinem beispiel oben hast du definitiv ein problem mit timer überlauf.
der interne timer den du mit time abfrägst time() läuft an die obere grenze eines 32bit wertes und beginnt dann wieder unten. genau dann geht dein vergleich if time() < haltezeit schief.
du darft keinen kleiner größer vergleich mit time() machen, sondern lediglich einen vergelich mit time() - anfangszeit. nur bei der subtraktion ist sichergestelklt das der überlauf des timers keine auswirkung hat.
bitte sende mir dein projekt mit tp_r damit ich herausfinden kann was bei dir schiefgeht.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Das Projekt zusenden kann ich Dir leider nicht. Da bekomme ich krach mit meinem Vorgesetzten. Die sehen das gar nicht gerne.
Doch kann ich mit sicherheit sagen, dass der Fehler sich in dem Baustein ergab. Denn der Start-Eingang war FALSE und die Zeit längstens abgelaufen und trotzdem blieb der Ausgang TRUE. Die vor- und nachgeschalteten Bausteine funktionierten einwandfrei.
Dennoch besten Dank für die Antworten!
Mit freundlichen Grüssen! Pitsch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
kann es sein das am eingang kurze pulse angelegen haben.
tp_r ist ja ein retriggerable pulsetimer, das heist immer wenn am eingang eine steigende flanke anliegt verlängert sich der eingang um die pulsdauer. er bleibt also true.
kannst du nicht einen kleinen auszug aus deiomem projekt senden.
wir selber setzten den tp_r vielfach ein und würden gerne auch den fehler kennen wenn den einer da ist.
fakt ist aber auch das dein code nicht funktionieren wird. er wird alle 25 tage verrückt spielen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Das komische ist nur, dass es mit meinem Timer geht (der ist ja auch Flanke-Getriggert und mit TP_R gibt es eben manchmal Störungen, weil er hängen bleibt. Jedenfals war das die Ursache der letzten beiden Störungen. Ich kann ja das Programm im Onlinemodus beobachten. Und es war so, dass alles zur Ruhe gekommen ist, nur der Ausgang von TP_R hate noch TRUE, was ich an einer Kontroll-Variable, die ich zu diesem Zweck an den Ausgang hängte, erkennen konnte. Schlimmes ist nicht passiert. Nur die Bedien-Tasten wurden nicht freigeschaltet, weil ich sie mit dem TRUE-Signal des Timers sperre.
Ich habe jetzt meinen Timer, so erweitert, dass das Ueberlauf-Problem eigentlich nicht mehr auftrehten sollte. Ob das so ist, wird sich zeigen.
Ich habe auch volles Vertrauen in die Bibliothek. Ich setze auch öfters Teile davon ein. Bisher ohne Beanstandungen!
Ich werde mein Projekt noch eine Zeit lang beobachten. Vielleicht finde ich noch weitere Fehler (Ich hoffe nicht) die zu diesem Verhalten führen.
Mit freundlichen Grüssen! Pitsch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo Leute
Die Funktion Time(), gibt ja die Zeit (in Milisek.) seit Systemstart zurück. Doch denke ich, dass die nicht Jahre lang nur immer aufwärts zählen kann. Irgend wann, kommt doch sicher ein Ueberlauf, wo die Ausgangs-Variable wieder von Null beginnt zu zählen.
Bei welchem Wert kommt der Ueberlauf?
Was passiert mit einem Timer, der auf dieser Funktion basiert?
Angenommen, ich addiere 3 Seckunden vor diesem Ueberlauf, noch 6 Sekunden zu meiner Referenz-Variable (vom Typ TIME). Hat dann diese Variable in bezug auf den Timer plus 3 Sekunden und der Timer auch, so dass mein Zeit-Ablauf nur 6 Seckunden beträgt, und nicht wer weiss wie lange?
Mit freundlichen Grüssen! Pitsch
Bei 2 hoch 32 (oder waren es 64?).
Da beim Rechnen mit der gleichen Anzahl Bits gerechnet wird kürzt sich der Überlauf quasis von alleine raus, zumindest solange mit Addition/Subtraktion gearbeitet wird.
es sind 2 hoich 32 etwa 25 tage
Hallo
Gibt es da eine einfache Methode, um das zu simulieren. Damit ich sehen kann, wie sich ein Spezialtimer in dieser Situation verhält?
Uebrigens noch etwas für den Administrator:
Der Timerbaustein TP_R in der OSCAT.LIB 1.7 ist sehr warscheinlich fehlerhaft. Der kann hängen bleiben. Ich habe jetz ein paar Mal Störungen in einer meiner Anlagen gehabt. Es stellte sich immer heraus, dass dieser Timer hängen blieb (Der Ausgang blieb auf TRUE). Der Baustein funktioniert 100 x tadellos und plötzlich bleibt er hängen.
Darum eigentlich meine Frage.
Ich habe jetzt selber einen solchen Baustein Programmiert. Der Code ist ein bisschen einfacher als in TP_R. Seither hatte ich keine Störungen mehr.
Mit freundlichen Grüssen! Pitsch
auf welcher steuerung / umgebung setzt du tp_r ein.
bitte melde uns solche fehler damit wir denen nachgehen und sie umgehend beseitigen können
bist du auf einer siemens anlage? welcher typ?
Hallo hugo
Meine Steuerung ist eine Wago 750-841. Für meine Projekte, brauche ich fast ausschliesslich diesen Typ. Gegenwärtig mit Firmware 11.
Ich habe den Baustein jetzt so programmiert:
FUNCTION_BLOCK ZEIT_RETRIG
VAR_INPUT
EIN : BOOL;
PULS_ZEIT : TIME;
END_VAR
VAR_OUTPUT
OUT : BOOL := FALSE;
END_VAR
VAR
FLANKE : BOOL := FALSE;
HALTEZEIT : TIME := t#0ms;
Aktuelle_Zeit:TIME;
END_VAR
( Nachtriggerbarer Timer )
IF (EIN = TRUE AND FLANKE = FALSE) THEN (Wenn Steigende Flanke an Eingang)
HALTEZEIT := TIME() + PULS_ZEIT;(HALTEZEIT mit Systemzeit + PULS_ZEIT initialisieren)
END_IF;
FLANKE := EIN; (Flankenmerker zurücksetzen)
Aktuelle_Zeit := TIME(); (Nur zur Kontrolle)
IF TIME() <= HALTEZEIT THEN (Wenn Systemzeit kleiner als HALTEZEIT)
OUT := TRUE; (Ausgang auf TRUE setzen)
ELSE(Wenn Systemzeit grösser als HALTEZEIT (Zeit also abgelaufen))
OUT := FALSE; (Ausgang auf FALSE setzen)
END_IF;
So funktioniert es fehlerfrei.
Nur möchte ich gerne genau wissen, was hier passiert, wenn dieser Timer ein paar Seckunden vor einem Ueberlauf gestartet wird und die Endzeit sich nach dem Ueberlauf befindet.
Mit freundlichen Grüssen! Pitsch
habe mittlerweile den tp_r nochmals getestet und keinerlei fehler gefunden.
kannst du mir dein projekt senden?
in deinem beispiel oben hast du definitiv ein problem mit timer überlauf.
der interne timer den du mit time abfrägst time() läuft an die obere grenze eines 32bit wertes und beginnt dann wieder unten. genau dann geht dein vergleich if time() < haltezeit schief.
du darft keinen kleiner größer vergleich mit time() machen, sondern lediglich einen vergelich mit time() - anfangszeit. nur bei der subtraktion ist sichergestelklt das der überlauf des timers keine auswirkung hat.
bitte sende mir dein projekt mit tp_r damit ich herausfinden kann was bei dir schiefgeht.
Hallo hugo
Das Projekt zusenden kann ich Dir leider nicht. Da bekomme ich krach mit meinem Vorgesetzten. Die sehen das gar nicht gerne.
Doch kann ich mit sicherheit sagen, dass der Fehler sich in dem Baustein ergab. Denn der Start-Eingang war FALSE und die Zeit längstens abgelaufen und trotzdem blieb der Ausgang TRUE. Die vor- und nachgeschalteten Bausteine funktionierten einwandfrei.
Dennoch besten Dank für die Antworten!
Mit freundlichen Grüssen! Pitsch
NUN ICH KANN DEN FEHLER HIER NICHT REPRODUZIEREN:
kann es sein das am eingang kurze pulse angelegen haben.
tp_r ist ja ein retriggerable pulsetimer, das heist immer wenn am eingang eine steigende flanke anliegt verlängert sich der eingang um die pulsdauer. er bleibt also true.
kannst du nicht einen kleinen auszug aus deiomem projekt senden.
wir selber setzten den tp_r vielfach ein und würden gerne auch den fehler kennen wenn den einer da ist.
fakt ist aber auch das dein code nicht funktionieren wird. er wird alle 25 tage verrückt spielen.
bist du sicher das die instanz von TP_R eindeutig ist und nicht mehrfach verwendet oder anders deklariert ist?
Test : TP_R;
falsch koennte sein test : TP;
ich bin mir ziemlich sicher das TP_R genau das tut was es tun soll
[/img]
Hi
@Hugo
Kann ich bestätigen.
Bei mit läuft der TP_R auf einem halben Dutzend von Anlagen OHNE Probleme.
(Unterschiedliche Anlagen)
@Pitsch52
Bei uns ist das Identisch.
Jedoch, habe ich es bisher IMMER geschafft, einen "CodeSnippes" zu basteln, bei der sich der Fehler reproduzieren lässt.
Ich habe volles Vertrauen zu der Bibliothek.
Wäre schön, das Problem zu lolalisieren und zu beseitigen.
Hallo
Das komische ist nur, dass es mit meinem Timer geht (der ist ja auch Flanke-Getriggert und mit TP_R gibt es eben manchmal Störungen, weil er hängen bleibt. Jedenfals war das die Ursache der letzten beiden Störungen. Ich kann ja das Programm im Onlinemodus beobachten. Und es war so, dass alles zur Ruhe gekommen ist, nur der Ausgang von TP_R hate noch TRUE, was ich an einer Kontroll-Variable, die ich zu diesem Zweck an den Ausgang hängte, erkennen konnte. Schlimmes ist nicht passiert. Nur die Bedien-Tasten wurden nicht freigeschaltet, weil ich sie mit dem TRUE-Signal des Timers sperre.
Ich habe jetzt meinen Timer, so erweitert, dass das Ueberlauf-Problem eigentlich nicht mehr auftrehten sollte. Ob das so ist, wird sich zeigen.
Ich habe auch volles Vertrauen in die Bibliothek. Ich setze auch öfters Teile davon ein. Bisher ohne Beanstandungen!
Ich werde mein Projekt noch eine Zeit lang beobachten. Vielleicht finde ich noch weitere Fehler (Ich hoffe nicht) die zu diesem Verhalten führen.
Mit freundlichen Grüssen! Pitsch