Villeicht erzähle ich da ja kalten Kaffee. Ich habe verschiedene Zeitgesteuerte Abläufe im Programm. So z.B. soll nach 72h für 2 Minuten eine Pumpe gestartet werden.
Dafür habe ich die vorhandene Variable TIME() verwendet, welche ja die Zeit ab Systemstart ausgibt. Nach ein paar Wochen blieb der Timer hängen. Inzwischen hab ichs gefunden: Time geht nach rund 49 Tagen wieder auf Null zurück und beginnt von vorne!!!
Vorsicht ist geboten, denn wenn genau über diesen Wechsel auf Neubeginn eine Zeitdauer ablaufen soll, wird diese nie erreicht. Es sei denn, man umschifft diesen Fall mit viel trickreichem Aufwand.
Da es bei mir nicht um Millisekunden geht, habe ich nun die eingebaute SysRtcGetTime verwendet, welche die aktuelle Zeit und das Datum ausgibt.
Noch ein Schönheitsfehler: Während internt die Zeit durchläuft, wird bei der Anzeige in der Visualisierung die Sommerzeitumstellung berücksichtigt. Es wäre schön, wenn ein Flag o.ä. abrufbar ist, welches Angibt, ob Sommerzeit oder nicht...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
siehe hierzu die neue oscat... dort gibt es die passenden TIME bausteine der dir zB ein bit setzt, wenn das angelegte datum sommerzeit ist.
btw:
der überlauf nach ~49 tagen kommt dadurch, dass TIME intern als DWORD variable gespeichert wird und dieser wert den millisekunden ab start entspricht; und der max. wert einer DWORD var ist 4294967295, was ungefähr den millisekunden nach 49 tagen entspricht.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
das problem des timer überlaufs kannst du auch agnz einfach vermeiden indem du immer nur die different zweier werte benutzt.
beispiel: t1 ist der erste wert aus dem timer und t2 ist der zweite wert.
die differenz t2 - t1 ergibt immer dasselbe egal ob t1 und oder t2 einen überlauf erfahren hat.
wenn z.b. t1 am oberen ende des wertebereichs liegt und t2 wegenh überlauf am unteren ende angelangt ist dann ergibt t2 - t1 trotzdem den richtigen wert.
wenn du das beachtest musst du keinen komplizierten sonderfälle betrachten.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Villeicht erzähle ich da ja kalten Kaffee. Ich habe verschiedene Zeitgesteuerte Abläufe im Programm. So z.B. soll nach 72h für 2 Minuten eine Pumpe gestartet werden.
Dafür habe ich die vorhandene Variable TIME() verwendet, welche ja die Zeit ab Systemstart ausgibt. Nach ein paar Wochen blieb der Timer hängen. Inzwischen hab ichs gefunden: Time geht nach rund 49 Tagen wieder auf Null zurück und beginnt von vorne!!!
Vorsicht ist geboten, denn wenn genau über diesen Wechsel auf Neubeginn eine Zeitdauer ablaufen soll, wird diese nie erreicht. Es sei denn, man umschifft diesen Fall mit viel trickreichem Aufwand.
Da es bei mir nicht um Millisekunden geht, habe ich nun die eingebaute SysRtcGetTime verwendet, welche die aktuelle Zeit und das Datum ausgibt.
Noch ein Schönheitsfehler: Während internt die Zeit durchläuft, wird bei der Anzeige in der Visualisierung die Sommerzeitumstellung berücksichtigt. Es wäre schön, wenn ein Flag o.ä. abrufbar ist, welches Angibt, ob Sommerzeit oder nicht...
siehe hierzu die neue oscat... dort gibt es die passenden TIME bausteine der dir zB ein bit setzt, wenn das angelegte datum sommerzeit ist.
btw:
der überlauf nach ~49 tagen kommt dadurch, dass TIME intern als DWORD variable gespeichert wird und dieser wert den millisekunden ab start entspricht; und der max. wert einer DWORD var ist 4294967295, was ungefähr den millisekunden nach 49 tagen entspricht.
das problem des timer überlaufs kannst du auch agnz einfach vermeiden indem du immer nur die different zweier werte benutzt.
beispiel: t1 ist der erste wert aus dem timer und t2 ist der zweite wert.
die differenz t2 - t1 ergibt immer dasselbe egal ob t1 und oder t2 einen überlauf erfahren hat.
wenn z.b. t1 am oberen ende des wertebereichs liegt und t2 wegenh überlauf am unteren ende angelangt ist dann ergibt t2 - t1 trotzdem den richtigen wert.
wenn du das beachtest musst du keinen komplizierten sonderfälle betrachten.