Baustein Ltime

[klaus313]

Hallo Hugo,

der Baustein Ltime hat noch einen kleinen Schönheitsfehler:
wenn im ersten cycle die Zeit noch nicht korrekt ist, also auf 1970.... + 1s steht wird next_check berechnet und > utc gesetzt. Dies bedeutet im ersten cycle wird auf Sommerzeit am 1.1.1970 geprüft was FALSE ist. Bis zur Zeit next_check ist somit die Korrektur der Sommerzeit - wenn es denn so ist - nicht berücksichtigt.
Es wäre vielleicht ein time_valid input sinnvoll ?

Weiterhin ist der Aufruf:
next_check := DWORD_TO_DT(DT_TO_DWORD(utc) / 3600 * 3600 +3600);
mir nicht ganz klar. Nutzt du hierbei eine Rundung bei DWORD aus wenn zuvor /3600 und dann *3600 berechnet wird oder wie ist das gemeint: /3600*3600 ist 1 ? Was hab ich hier übersehen ?

Da zumindest bei mir die SPS Uhr immer auf local Zeit läuft wäre eventuell auch eine Funktion Ltime_to_utc sinnvoll um dann Sun_time korrekt berechnen zu können ?

Dae und Gruß
Klaus


.
d.h. b

[hugo]

Hi einen neue funktion LTIME_TO_UTC wird es in release 1.7 geben diese wird am sonntag released

das problem mit dst sollte bereits in der release 1.6 korrigiert sein. hast du 1.6 verwendet?

das teilen durch 3600 und anschließend mal 3600 ist wirklich nötig. das ergebnis aus dword / integer ergibt zwingend einen integer und dann mal 3600 ergibt nicht dasselbe wie die ursprüngliche zahl.

vorsicht ist aber geboten zeit datums abhängige funktionen aus lokalzeit mit sommerzeit zu betreiben.
bei umschaltung auf sommerzeit gibt es einen tag wo die stunde 02:00 - 03:00 nicht existiert, umgekehrt gibt es dann im herbst einen tag wo diese stunde 2 mal vorkommt.
das kann schnell in software zu unvorhergesehenen problemem führen, mit utc ist immer alles eindeutig.
steuerungstechnik sollte deshalb nicht immer mit sommerzeit arbeiten.

[Tom]

Hab den Thread noch mal ausgegraben.

Es scheint immer noch ein Problem zu geben, zumindest bei meinem CX mit Lib2.1. Das Auslesen der Uhrzeit dauert halt etwas und scheint nicht sauber zu sein. Der "Ltime" rechnet zumindest mit einem falschen Wert, in der Variable next_check steht "2042-11-02-02:00", damit findet auch keine Korrektur mehr statt. Ich hab mir damit beholfen, dass ich "Ltime" überspringe, solange der "NT_GetTime" busy ist. Vielleicht ist auch eine andere Lösung möglich, z.B. im "Ltime" in der ersten Zeile auch zu prüfen, ob "next_check" größer eine Stunde gegenüber "utc" ist und bei TRUE die Berechnungen durchlaufen zu lassen.

[Tom]

Hab das grad mal getestet: Die Variable "next_check" hat jetzt das richtige Datum, die Sommerzeit wird aber erst nach dem nächsten Check zur vollen Stunde gesetzt, wegen der Reihenfolge im Programm. Wenn man die init-Verzweigung weglässt, funktioniert das Ganze, weiss nur nicht wie das performancemäßig aussieht, die Verzweigung war ja sicher nicht umsonst drin. Kann man aber bei den Aufrufen im Stundentakt sicher verschmerzen. So sähe das aus:

----------------------------------------------------------------

IF utc > next_check  OR next_check > (utc+T#2h) THEN
   local_dt := utc + time_zone_offset;
   next_check := DWORD_TO_DT(DT_TO_DWORD(utc) / 3600 * 3600 +3600);
   DST_on := DST(local_dt, time_zone_offset);
   IF DST_on AND dst_enable THEN time_adder := time_zone_offset + T#1h; ELSE time_adder := time_zone_offset; END_IF;
END_IF;
local_dt :=utc + time_adder;
wday := weekday(DT_TO_DATE(local_dt));

----------------------------------------------------------------

Man könnte auch statt "local_dt" eine andere Hilfsvariable beim Check für verwenden, der Übersichtlichkeit halber.

----------------------------------------------------------------

IF utc > next_check  OR next_check > (utc+T#2h) THEN
   temp_dt := utc + time_zone_offset;
   next_check := DWORD_TO_DT(DT_TO_DWORD(utc) / 3600 * 3600 +3600);
   DST_on := DST(temp_dt, time_zone_offset);
   IF DST_on AND dst_enable THEN time_adder := time_zone_offset + T#1h; ELSE time_adder := time_zone_offset; END_IF;
END_IF;
local_dt :=utc + time_adder;
wday := weekday(DT_TO_DATE(local_dt));

----------------------------------------------------------------



Bei mir funktioniert's, oder hab ich was übersehen? Was sagst du dazu, Hugo?

[hugo]

nun die uhrzeit die du am eingang bekommst dürfte ja gar nicht sein, bist du sicher das die abarbeitung in der richtigen reihenfolge passiert?
in der grafischen oberfläche kannst du die reihenfolge automatisch definieren indem du rechte maustaste / reihenfolge / alles nach datenfluss anordenen ausführst.

die zusätzliche abfrage werde ichj einbauen damit bei falschen zeiten nicht dieser hangup entsteht.
danke für deinen hinweis

[Tom]

Mit CFC hab ich noch gar nicht gearbeitet. Sollte ich mir vielleicht mal anschauen. Reihenfolge ist richtig. Hab mal mit einem kleinen FB die Werte vom NT_GetTime in ein Array gelesen. Im ersten Zyklus sind alle Werte auf 0, daher das Problem, erst im 2 Zyklus werden korrekte Werte geliefert. Vielleicht liegts daran, dass ich meine Testumgebung in einer VM von VMWARE laufen hab, dann entschuldige den Trouble. Mein CX ist halt noch nicht betriebsbereit.  ::)  Wie auch immer, die Abfrage kann nicht schaden.

Keep up the good work ...  :)

[hugo]

die nächste release (2.3) der oscat lib wird einen anderen algorithmus verwenden und dann auch bei unkorrekter zeit am eingang funktionieren.