CALENDAR

[kiar]

Hallo hugo,
ich habe jetzt von 277 auf 304 umgestellt und habe folgende Anliegen:
1. Könnt Ihr die Kalenderwoche im CALENDAR noch unterbringen?
2. Wenn man eine Lokalisierung mit dem OFFSET=60 für Deutschland und DST_EN=ON für Sommer/Winterzeitberechnung angibt, warum wird dann SUN_RISE, SUN_SET nicht mit der lokale Zeit ausgegeben? Ich vermute bereits, daß bei Sommerzeit dann 2 Stunden fehlen werden. Wenn schon die lokalen Parameter am Baustein gesetzt sind, sollten die Ausgabewerte auch lokal sein.
Übrigens, danke für Eure Arbeit.

Gruß kiar

[hugo]

1. die kalenderwoche bauen wir noch in den calendar ein.

2. sonnenaufagng und untergang haben wir in weltzeit weil es ja theoretisch auch bewegliche installationen gibt wie z.b. schiffe und dann wird es sehr komplex

[kiar]

Hallo hugo,
ich bin ehrlich: Ich habe es nicht so richtig verstanden mit den beweglichen Installationen. Vielleicht hast Du ein Beispiel?

Aber noch mal meine Sicht:
Der Baustein CALENDAR_CALC bekommt alle Eingabedaten (Längen-, Breitengrad, Zeitzone, Weltzeit, Sommer-/Winterzeit) für eine lokale Berechnung. Es wird aber nur die lokale Zeit bestimmt. Die Sonnenauf-/Untergangszeiten müssen aber selber lokalisiert werden.

Bei den beweglichen Installationen würde ich doch eine Lokalisierung ebenfalls über die Eingabedaten machen. Je nach dem, ob ich die Ortszeit des Heimathafen, die Ortszeit des Zielhafen oder die Ortszeit des Schiffes benötige, sind die dann unterschiedlich oder ändern sich laufend.

Ich denke auch, daß die meisten Anwendungen feste Installationen sind und die Lokalisierung aller Ausgabedaten wichtig ist.

Im Programmcode sieht es übrigens nicht so schön aus, wenn die beiden "schicken" SysRtcGetTime und CALENDAR_CALC anschließend mit etlichen IF-Anweisungen und Additionen/Subtraktionen wegen der Lokalisierung überschüttet werden.

Übrigens würde ich mir die Lokalisierung auch für den sun_time wünschen. Oder noch besser, Ihr packt den auch gleich mit in den CALENDAR_CALC.

Gruß kiar

[hugo]

beweglich sind z.b. schiffe
welche zeit gilt nun wenn du währed eines tages die zeitzone überschreitest.

aber damit siond noch unzählige andere pürobleme verbunden:

1. berücksichtigung von sommer / winterzeit umschaltung während eines tages
  es koennte ja jemand zu beliebiger zeit des dst_en einschalten.

damit sonnen auf und untergang in lokalzeit richitg funktioniert muesste ich be jedem aufruf alles mögliche auf änderung prüfen und dauernd sonnenaufgang und untergang neu berechnen, so mache ich das nur wenn sich längen / breitengrad ändert und einmal um 00:00
um 0:00 weis ich aber noch nicht ob um 02:59 auf sommerezit gestellt wird, das hängt ja davon ab ob dann in diesem augenblick dst_en auf true steht.

geanus aus diesen gründen und noch vielen mehr werden astronomische vorgänge grundsätzlich in weltzeit berechnet.
ausser für uhrzeitanzeige für den user empfehlen wir nicht weltzeit zu nehmen.

bei lokalzeit kannst du z.b. nie sagen wieviel zeit zwischen 2 zeitpunkten vergangen ist, denn dazu müsstest du dst usw bei jedem einzelnen vergelich abfragen.

aus aufgangs und untergangszeit kannst du die tageslänge berechnen, würde aber bei lokalzeit wenn jemand tagsüber die dst einschaltet nicht mehr funktionieren.

ich könnte jetzt mit komplikationen weitermachen.

aber einfach ein tip:
in einer steuerung hat normalerweise lokalzeit nichts verloren das macht die steuerung sicherer und stabiler

[mg]

... beim letzten Kommentar vom Huge stimme ich absolut zu ...

Nur daß das unsere Steuerungshersteller noch nicht kapiert haben. Betrifft insbesondere das Codesys selbst (insbesondere Trend und Alarm), weil den Kunden interessiert halt nur die "Lokalzeit"!

[hugo]

die lokalzeit kannst du zur anzeige ja einfach berechnen ein modul gibts in der lib
allerdings hast du dann das problem das ein ereignis am letzten sonntag um 02.00 nicht mehr nachzuvollziehgen ist ob es die erste stunde 02:00 oder dioe 2te stunde war
alleine deshalb ist mit lokalzeit vorsicht geboten
aber wie gesagt wer es zur anziege haben will kann sie ja einfach umrechnen
aber bitte z.b. im log neben der lokalzeuit auch die weltzeit sonst habt ihr keine möglichkeit mehr den absoluten zeitpunkt bei sommerzeitumschaltung zu ermitteln
genau aus diesem grund können z.b. keine zeitabstände aus zwei lokalzeiten errechnet werden (ausser man nimmt zur zeit auch noch die weltzeit oder sommerzeitflag hinzu)

alleine wegen der tageslängenberechnung haben wir uns entschieden weltzeit für sonnenaufgang und untergang anzugeben

[kiar]

ok Hugo,

die lokalen Werte für sun_rise und sun_set habe ich jetzt selbst berechnet - kein Problem damit.

Jetzt habe ich aber gesehen, daß im CALENDAR_CALC intern der sun_time aufgerufen wird.
Und nun wünsche ich mir noch sun_midday und sun_declination in die XCAL-Struktur.

Gruß kiar.

[hugo]

hallo kiar,
ja das macht sinn.
midday wird aber logischerweise auch in weltzeit sein da es eine astronomische größe ist

[kiar]

Danke hugo,

aber mal was anderes:
Hockst Du eigentlich 24h vorm Monitor? Oder hast Du so was "Kleines" immer dabei?
Du bist ja bei den Antworten schneller, als ich beim Fragen formulieren.

Gruß kiar

[hugo]

dank blackberry und diversen gadgets bin ich häufig online aber bestimmt nicht immer

[QTreiber]

Hallo Hugo,
ich bin gerade dabei, mich ein bisschen mit den Kalenderfunktionen zu beschäftigen, da bin ich auf eure Diskussion gestoßen. Das mit der UTC in der Steuerung kann ich ja schon nachvollziehen und auch aktzeptieren, aber für manche Dinge ist die Lokalzeit unabdingbar, da muss ich Kiar recht geben. Ich hab mich gefragt, ob ich das Bit "night" verwende um die Beleuchtung zu beeinflussen, aber wenn das anzeigt wann es in Greenwich dunkel ist, stellt sich mir dann schon die Sinnfrage.
Aber das wäre nun nicht mein eigentliches Problem. Mir scheint die Berechnung der Sonnenstandszeiten bei meiner Steuerung nicht so recht zu funktionieren. Laut Internet hätte heute der Sonnenaufgang für meinen Breitengrad um exakt 6:00 sein sollen, ich bekomme aber von deinem Baustein 2:27:14 angezeigt. Wenn ich nun noch 2 Stunden Timeoffset addiere komme ich aber trotzdem auf 4:27... das ist von 6:00 ziemlich weit entfernt. Hast du vielleicht eine Idee? Ich hab dir mal einen Screenshot angehängt. (Version 3.20)


Wolfgang

[gelöscht durch Administrator]

[QTreiber]

Ach ja, was mir noch seltsam vorkommt  Ich hab in ein und demselben Programm unterschiedliche Sonnenaufgangs und Untergangszeiten. Je nachdem ob ich Calendar oder sun_time benutze...

Siehe Anhang...

Wolfgang

[gelöscht durch Administrator]

[hugo]

die sonnenstasndsberechnung wurde in den letzten versionen nochmals überarbeitet und dabei wird die refraktion berücksichtigt.
die refraktion beugt das sonnenlicht beim durchgang durch die erdatmosphäre, deshalb sehen wir den sonnenaufgang bereits einige grad bevor die sonnen rein geometrisch über dem horizont ist.

den calendar werden wir nochmals überarbeiten, so dass dann alle werte in lokalzeit vorhanden sind.
allerdings warne ich nochmals bei verwendung von lokalzeit mit sommerzeit. es gibt tage die sind 25 stunden und tage die sind 23 stunden.
einmal im jahr fällt eine stunde komplett aus und einmal ist sie gar doppelt.
dies muss beim programmieren unbedingt beachtet werden.

da ein anwender kaum die uhrzeit aus der sps ablest erscheint es mit logischer und einfacher intern immer utc (weltzeit) zu verwenden.

den sonnenaufgang in utc bedeutet nicht das du die sonnenaufgangszeit in greenich angezeigt bekommt, sonder du bekommst natürlich die lokale sonnenaufgangszeit die ja klediglich von längengrad und breitengrad abhängt. diese zeit bekommst du dann in weltzeit angezeigt.

aber wie gesagt den calendar ändern wir in der nächsten version so dass er alle ausgaben in lokalzeit macht, das ist gebe ich zu logischer.

[hugo]

*****
Offline Offline

Beiträge: 647



Profil anzeigen Private Mitteilung (Offline)
   
   
Re: LTIME_TO_UTC
« Antwort #1 am: 02. August 2009, 20:51:12 »
   ZitierenZitat Beitrag ändernÄndern Beitrag löschenLöschen Thema teilenThema teilen
Hallo Terminator95

Dein Problem mit LTIME_TO_UTC kann ich nachvollziehen !

Ich habe dir eine korrigierte version erstellt !

die alte hat nicht nur falsch gerechnet, sondern hat auch bei "DST" = True , das ganze jahr über die +1 Stunde für Sommerzeit mitgerechnet
die neue version prüft vorher ob bei LTIME überhaupt sommerzeit aktiv ist

und nicht vergessen time_offset wird in minuten angegeben

Code:

FUNCTION LTIME_TO_UTC : DT
VAR_INPUT
   LTIME : DT;
   DST_ENABLE : BOOL;
   TIME_ZONE_OFFSET : INT;
END_VAR
VAR
   tmp: INT;
   tmp2: DWORD;
END_VAR

tmp := time_zone_offset * 60;
tmp2 := BOOL_TO_DWORD(DST_ENABLE AND DST(LTIME)) * 3600;
IF tmp < 0 THEN
   tmp := ABS(tmp);
   LTIME_TO_UTC := DWORD_TO_DT(DT_TO_DWORD(Ltime) + INT_TO_DWORD(tmp) - tmp2);
ELSE
   LTIME_TO_UTC := DWORD_TO_DT(DT_TO_DWORD(Ltime) - INT_TO_DWORD(tmp) - tmp2);
END_IF;