- Beiträge
- 22.226
- Reaktionspunkte
- 6.911
Wieso ist das Datum der Zeitumstellung vom Vorjahr abhängig??? Die Umstellungen sind immer am letzten Sonntag im März und am letzten Sonntag im Oktober.// Die Berechnung des Datums für die Zeitumstellung des aktuellen Jahres ist Abhängig vom Vorjahr -> "GVL.stSystemTime.wYear -1"
Sie ist vom aktuellen Jahr abhängig (und damit "indirekt" natürlich auch vom Vorjahr).Wieso ist das Datum der Zeitumstellung vom Vorjahr abhängig???
Mein Ansatz, müsste ich auf irgendwelche Hilfen vom "SystemFunktionen" verzichten, wäre genau durch den WochenTag Sonntag inspiriert, nämlich einen speziellen, den OsterSonntag. Dafür gibt es Formeln/Lösungswege - habe ich vor Jahrenden schonmal in Excel durchexerziert, habe die Lösung aber jetzt nicht parat *). Auf dem Umwege über OsterSonntag dürfte sich relativ leicht das Datum des letzten Sonntags im März und Oktober ermitteln lassen.Die Umstellungen sind immer am letzten Sonntag im März und am letzten Sonntag im Oktober.
Das hatten wir eigentlich schon geklärt, dass nur "fast immer" richtig ist. Aber nicht in der Stunde, nach der die Uhr 1 Stunde zurückgestellt werden soll.Deine Minutenpulse kannst du immer schicken.
Function Ostern(ByVal Jahr As Integer) As Date
Dim ZR1, ZR2, ZR3, ZR4, ZR5, ZR6, ZR7 As Integer
ZR1 = Jahr Mod 19 + 1: ZR2 = Int(Jahr / 100) + 1
ZR3 = Int(3 * ZR2 / 4) - 12: ZR4 = Int((8 * ZR2 + 5) / 25) - 5
ZR5 = Int(5 * Jahr / 4) - ZR3 - 10: ZR6 = (11 * ZR1 + 20 + ZR4 - ZR3) Mod 30
If (ZR6 = 25 And ZR1 > 11) Or ZR6 = 24 Then ZR6 = ZR6 + 1
ZR7 = 44 - ZR6
If ZR7 < 21 Then ZR7 = ZR7 + 30
ZR7 = ZR7 + 7
ZR7 = ZR7 - (ZR5 + ZR7) Mod 7
If ZR7 <= 31 Then
Ostern = DateSerial(Jahr, 3, ZR7)
Else
Ostern = DateSerial(Jahr, 4, ZR7 - 31)
End If
End Function
Mit der angewendeten Formel und dem aktuellen Jahr berechne ich mir den Tag (27., 28.,...) für die Zeitumstellung des darauffolgenden Jahres. Demnach nutze ich das Vorjahr um den Tag der Zeitumstellung für das aktuelle Jahr zu berechnen. Deswegen auch Aktuelles Jahr -1.Wieso ist das Datum der Zeitumstellung vom Vorjahr abhängig??? Die Umstellungen sind immer am letzten Sonntag im März und am letzten Sonntag im Oktober.
Kann natürlich sein, dass ich gerade gewaltig auf dem Schlauch stehe, aber eigentlich verstelle ich die Systemzeit gar nicht, sondern filtere mir nur daraus das aktuelle Jahr um die Daten für die Zeitumstellungen zu ermitteln. Diese vergleiche ich mit der Systemzeit und reagiere je nach Umstellung entsprechend.Es ist ungünstig, die Systemuhr zu verstellen.
Da ich nur Minutenimpulse benötige sind für mich die Stunden doch uninteressant, oder sehe ich das falsch?Du holst dir die Minuten aus dem Struct der Systemzeit, warum nicht auch die Stunden? Windows kennt von Kindesbeinen an die Zeitumstellung, da braucht man sich eigentlich nicht drum kümmern.
Genau.Das hatten wir eigentlich schon geklärt, dass nur "fast immer" richtig ist. Aber nicht in der Stunde, nach der die Uhr 1 Stunde zurückgestellt werden soll.
Ja, sicher. Und solange sowohl der OsterSonntag als auch der letzte Sonntag im März nach dem potenziellen Störer (Schaltag, 29. Februar) stattfinden, muss man sich nicht einmal um das Thema SchaltJahr kümmern - das tut schon die Berechnung des OsterSonntags!Hmm, der Ostersonntag liegt meistens nach dem letzten Sonntag im März, manchmal aber auch davor - und trotzdem kann man vom Ostersonntag ausgehend den letzten Sonntag im März berechnen???
dws = OsterSo + INT((31_Mrz - OsterSo) / 7) * 7 ' WxlTag (Winter->Sommer)
dsw = OsterSo + INT((31_Okt - OsterSo) / 7) * 7 ' WxlTag (Sommer->Winter)
' Wobei ...
' OsterSo : Datum des OsterSonntags im aktuellen Jahr (s. 'PS' in Beitrag #23)
' 31_Mrz : Datum des 31. Mrz im aktuellen Jahr
' 31_Okt : Datum des 31. Okt im aktuellen Jahr
' Gilt auch für das 'PS' in Beitrag #23:
' In SCL und ST dürfte das INT überflüssig sein, da ein INT-Ergebnis einer Division immer nur ab- und nie aufgerundet wird.
' Aber: Vorsicht, der Compiler könnte/dürfte die Division durch 7 mit der anschliessenden Multiplikation mit 7 "zusammenfassen" (= schlabbern)!
' Vorsichtshalber das DivisionsErgebnis einer INT-HilfsVariable zuweisen und mit dieser HilfsVariable weiterrechnen.
Die empfangenden Uhren werden aber allein durch den Minuten-Impuls gesteuert/weitergeschaltet. Einen entsprechenden Impuls für den StundenZeiger gibt es nicht - wär' ja auch zu einfach!Nochmal: Solange die Systemzeit korrekt ist, brauchst du dir um die Zeitumstellung in TwinCat keine Sorgen machen.
Ich glaube nicht, daß in der Formel der Ausdruck "Jahr - 1" das Vorjahr meint, sondern einfach für die Verschiebung des Ergebnisses der Division und des (0-basierten) MOD um 1 Tag nötig ist. Genauso, wie wenn man ein 0-basiertes Array [0..30] für jeden Tag eines Monats hat und den Index in das Array aus "Tag - 1" berechnet. Da meint "Tag - 1" auch nicht "Gestern" oder einen Tag des Vormonats.Mit der angewendeten Formel und dem aktuellen Jahr berechne ich mir den Tag (27., 28.,...) für die Zeitumstellung des darauffolgenden Jahres. Demnach nutze ich das Vorjahr um den Tag der Zeitumstellung für das aktuelle Jahr zu berechnen. Deswegen auch Aktuelles Jahr -1.Wieso ist das Datum der Zeitumstellung vom Vorjahr abhängig??? Die Umstellungen sind immer am letzten Sonntag im März und am letzten Sonntag im Oktober.
OK, ich hatte den Code nur oberflächlich überflogen und fälschlicherweise angenommen, daß da die Uhr verstellt wird. Vor allem, weil beim Rückstellen zur Winterzeit etwas extra für 1 Stunde unterdrückt wird, was bei Berechnung aus einer nicht verstellten Uhr eigentlich nicht nötig sein sollte.eigentlich verstelle ich die Systemzeit gar nicht
// Pulse vorbereiten
tbSecond0 := tiSecond = 0 ;
tbHour2 := tiHour = 2 ;
IF sbSecond0Prev OR NOT tbSecond0 THEN
; // wenn nicht positive Flanke der Sekunde: nichts tun
ELSIF sbHour2Prev OR NOT tbHour2 THEN
PulseCounter := PulseCounter + 1 ; // 1 min vor, normaler Impuls, wenn nicht Beginn der "magischen" Stunde
ELSIF tdateChgWin2Sum = actualDate THEN
PulseCounter := PulseCounter + 61 ; // 1 min vor und 1 h vor
ELSIF tdateChgSum2Win = actualDate THEN
PulseCounter := PulseCounter - 59 ; // 1 min vor und 1 h zurück
ELSE
PulseCounter := PulseCounter + 1 ; // 1 min vor, normaler Impuls, wenn Beginn der "magische" Stunde, aber kein Wxl-Datum
END_IF ;
sbSecond0Prev := tbSecond0 ; // für FlankenErkennung
sbHour2Prev := tbHour2 ; // für FlankenErkennung
// Pulse ausgeben bzw. unterdrücken
tbClock := ( tiSecond MOD 2 ) = 0 ; // für z.B. tbClock 0,5 Hz
output_pulse := output_pulse AND tbClock ; // Rücksetzen des Ausgabe-Impulses
IF sbClockPrev OR NOT tbClock THEN
; // wenn nicht positive Flanke des AusgabeTaktes: nichts tun
ELSIF PulseCounter <= 0 THEN
; // wenn ZählerStand <= 0: nichts tun
ELSE
output_pulse = TRUE ; // wenn Zählerstand > 0: Impuls setzen und Zähler dekrementieren
PulseCounter := PulseCounter - 1 ;
ENDIF ;
sbClockPrev := tbClock ; // für FlankenErkennung
Aber genau hier liegt auch mein Problem. Wie kann man die exakte Uhrzeit unmittelbar nach dem Einschalten festhalten, um die zeitliche Differenz zu ermitteln? Im Grunde muss ich ja wissen wann die Steuerung ausgefallen ist und wann sie wieder gestartet wurde.Der Aufwand hierfür beschränkt sich eigentlich darauf, zu ermitteln, wie viele Impulse nachzuliefern sind.
Du benötigst nicht die "die genaue Uhrzeit unmittelbar nach dem Einschalten", sondern die aktuelle Uhrzeit, zu der Du beginnst, die ImpulsAusgabe wieder aufzunehmen. Und natürlich auch bzw. insbesondere, die aktuelle Uhrzeit und den Zählerstand zu dem Zeitpunkt, zu dem Du den letzten Impuls ausgegeben bzw. unterdrückt hast. Die aktuelle Uhrzeit kannst Du in "aller Ruhe" - wie gewohnt - einlesen.Wie kann man die exakte Uhrzeit unmittelbar nach dem Einschalten festhalten, um die zeitliche Differenz zu ermitteln?
Nein, die Uhren geben leider keine Rückmeldung.Haben Deine Nebenuhren irgendeine Rückmeldung, wo ein oder beide Zeiger stehen?
Unabhängig vom Wechsel der Sommer-/Winterzeit muss das Datum sowieso einbezogen werden, falls sich der Stromausfall über mehrere Tage erstrecken sollte, oder nicht? Das war zumindest mein Gedanke und der Grund dafür warum ich vom Datentyp Date and Time gesprochen habe.Immerhin könnte ja während des Stromausfalls ein Wechsel von Winter-/Sommerzeit stattgefunden haben und man muss sich deshalb nicht nur die Uhrzeit, sondern auch das Datum des zuletzt ausgegebenen Impulses merken.
Hmmm, jain. Du musst doch "normalerweise" (wenn kein Wechsel zwischen Sommer- und Winterzeit während des StromAusfalls stattfindet) "nur" den MinutenZeiger und "indirekt" auch den StundenZeiger synchronisieren. Oder haben Deine Uhren auch eine DatumsAnzeige, die über den Minuten-Impuls gesteuert wird?Unabhängig vom Wechsel der Sommer-/Winterzeit muss das Datum sowieso einbezogen werden, falls sich der Stromausfall über mehrere Tage erstrecken sollte, oder nicht? Das war zumindest mein Gedanke und der Grund dafür warum ich vom Datentyp Date and Time gesprochen habe.
Ja guck, da hatte ich wohl einen DenkfehlerHmmm, jain. Du musst doch "normalerweise" (wenn kein Wechsel zwischen Sommer- und Winterzeit während des StromAusfalls stattfindet) "nur" den MinutenZeiger und "indirekt" auch den StundenZeiger synchronisieren. Oder haben Deine Uhren auch eine DatumsAnzeige, die über den Minuten-Impuls gesteuert wird?
Uhrzeit und Datum sind zu berücksichtigen wegen der Umstellungen zwischen Sommer- und Winterzeit.
Um die beiden Zeiger (Stunde und Minute) zu synchronisieren, kann Dir egal sein, wie viele (halbe!?) Tage zwischen Beginn und Ende des StromAusfalls vergangen sind.
Jetzt leuchtet mir auch der Ansatz von PN/DP ein.Könnte man nicht ab Mitternacht mitzählen, wieviele Minutenimpulse tatsächlich ausgegeben wurden, und mit der aktuellen Uhrzeit vergleichen, wieviele es hätten sein müssen?
Zur Frage: Genau, 2 Umdrehungen pro 24 Stunden.Du musst nur die Differenz zwischen Soll und Ist der Zeiger ausgleichen und die ist maximal 12 Stunden.
Frage am Rande: die StundenZeiger machen doch pro 24 Stunden 2 Umdrehungen?
Ja. Und zwar separat für jede einzelne, angeschlossene Uhr.Könnte man nicht ab Mitternacht mitzählen, wieviele Minutenimpulse tatsächlich ausgegeben wurden, und mit der aktuellen Uhrzeit vergleichen, wieviele es hätten sein müssen?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?