sonnenaufgang und -untergang stimmen nicht

[tommi.l]

hallo,
bin gerade dabei denn sun_time baustein in mein twincat einzubinden.
klappt auch alles soweit. allerdings wird die zeit des sonnenaufgangs (berechnet 03:24 uhr, soll 05:24 uhr) und die zeit des sonnenuntergangs (berechnet 19:38 uhr, soll 21:38 uhr) falsch berechnet (anbei ein Screenshot).
ist schon komisch, dass die zeit genau 2 stunden daneben liegt, oder?!?!?
wo ist der fehler?
kann mir da jemand helfen?




[gelöscht durch Administrator]

[peewit]

das hat schon seinen grund warum das 2 stunden daneben liegt

du musst mal zwischen weltzeit (utc) und lokalzeit (ltc) unterscheiden
wir haben geographisch gesehen +1 stunde zur weltzeit (greenwich)
und da wir momentan sommerzeit haben , sind unsere uhren nochmals 1 stunde vorgestellt
das ergibt in summe +2 stunden zur weltzeit

der baustein sun_time gibt die ergebnisse als weltzeit (utc) aus
somit ist das ergebnis genau um diese 2 stunden zu früh

dass ergebniss müsstest du dann noch mit utc_to_ltc auf lokalzeit konvertieren

in der doku des baustein sun_time ist dies aber auch so beschrieben !!

[tommi.l]

hallo,
danke für die schnelle antwort. wer lesen kann ist klar im vorteil 
aber jetzt taucht ein anderes problem auf:
utc_to_ltc finde ich nicht....ich finde nur utc_to_ltime
davon abgesehen ist der wert aus dem sun_time baustein ein tod und utc ist vom format dt. 
kannst du mir da nochmals auf die sprünge helfen?
ich hab mir jetzt zwar nen baustein geschrieben mit dem es funktioniert, aber die neugierde plagt mich schon

[peewit]

hallo

ja es sollte UTC_TO_LTIME sein ..... habe nicht ausgepasst

das die verschiedenen datum und zeit formate schwer in form zu bringen sind, das ist leider so

ich habe dir einen kleinen hilfsbaustein (nur eine zeile code) gemacht der dir aus der utc und der sonnenauf/untergangszeit (tod) mittels sommerzeit ja/nein und time_offset wieder eine TOD auf lokalzeitbasis erzeugt

ich hoffe du kannst den code verstehen

Code: [Auswählen]

FUNCTION DT_TOD_TO_LTOD : TOD
VAR_INPUT
UTC : DT;
iTOD : TOD;
DST_ENABLE : BOOL;
TIME_ZONE_OFFSET : INT;
END_VAR

DT_TOD_TO_LTOD := DT_TO_TOD(UTC_TO_LTIME(DWORD_TO_DT(DT_TO_DWORD(DATE_TO_DT(DT_TO_DATE(UTC))) + DT_TO_DWORD(TOD_TO_DT(ITOD))), DST_ENABLE, TIME_ZONE_OFFSET));

[tommi.l]

alles klar. hab es selbst jetzt nicht so realisiert, aber geht natürlich auch so 
hatte mich eben nur gewundert, weil ich den baustein nicht gefunden hab...

[tommi.l]

ach so ganz vergessen: danke !!!

[tommi.l]

jetzt hab ich ein neues Problem und zwar mit dem sun_pos.
aus irgendeinem Grund werden die Winkel nicht richtig berechnet.
Hab natürlich diesmal als erstes richtig in die Doku geschaut.... 
zu dem Zeitpunkt der Errechnung rechnet die SPS 278° der Kompass sagt ~230°.
die höhe über dem Horizont ist laut Berrechnung 26°?!?!? (am 01.07.!!) grob gemessen sind es aber 70°...
kann mir da einer nen Tipp geben?
 

[peewit]

gib uns doch bitte einmal ein problem beispiel:


übergebene Datum/Uhrzeit und Längen und Breitengrad
und was hat dir der baustein ausgegeben !

eventuell eine bidschirmhardcopy erstellen

hier kannst du mal online herumspielen !
http://www.volker-quaschning.de/datserv/sunpos/index.php

[tommi.l]

guckst du hier
stimmt übrigens nicht mit den daten für der http://www.volker-quaschning.de/datserv/sunpos/index.php seite überein...

[gelöscht durch Administrator]

[peewit]

hallo

ich habe mit deinen daten es auch mal selber probiert (siehe grafik)
die werte sind aber nicht so dramatisch anders !

wir müssen noch den kommentar von "hugo" abwarten, um zu erfahren welche berechnungsbasis bei oscat verwendet wird.
(es gibt hier mehrere berechnungmöglichkeiten)

um dann bestimmen zu können , ob hier wirklich etwas fehlerhaft ist.



[gelöscht durch Administrator]

[hugo]

hallo leute,

bei der berechnung des sonnenstandes sind mehrer dinge zu berücksichtigen.

- der sonnenstand ist geometrisch ein anderer als optisch. die sogenannte refraktion verbiegt den lichteinfall durch brechung in der atmosphäre.
- die refraktion wirkt am stärksten bei flachen winkeln, also bei auf und untergang.
- die ganze berechnung ist für einen idealisierten erdball gemacht, das bedeutet das die meereshöhe deines standortes und das gelände einen wesentlichen einfluss haben
  hügel und berge können hier mehrere minuten unterschied zur folge haben.
- nicht zu vergessen ist das abhängig von deiner sps/cpu unterschiedliche lib beim compilen eingebunden werden was zu unterschiedlicher genauigkeit im algorithmus führt.
- abhängig von der verwendeten methode führt dies zu unterschiedlichen ergebnissen.
- nicht zuletzt hat die luftfeuchtigkeit und verschiedene temperaturschichten in der atmosphäre einen einfluss.

alles in allem sollten aber die fehler sich nicht auf mehr als ein paar minuten aufsummieren.

abschliessend ist aber zu sagen das der auf und untergang "dämmerung" in unseren breitengraden eine relativ lange periode ist und wir nur den mittleren zeitpunkt der dämmerung feststellen.
wenn die dämmerung 30 minuten dauert, und wir 05:00 berechnen kann dies in der praxis bedeuten das die dämmerung um 04:45 beginnt und um 05:15 die sonne voll aufgegangen ist.
dasselbe gilt für die abenddämmerung.

[tommi.l]

ich ahne da etwas....

wenn ich anstatt der Umrechnung von Lokalzeit in UTC, die richtige UTC angebe stimmt es....
hat sich also erledigt.....

schon wieder nicht richtig gelesen.......

trotzdem danke.....

[hugo]

ja das sollte auch so sein, alle astronomischen vorgänge benötigen weltzeit

[peewit]

hugo !

du könntest deine ausführliche erklärung der faktoren bei der berechnung mit in die baustein doku aufnehmen, da immer wieder diskusionen über unterschiedliche werte auftreten.

[hugo]

naja ich stelle immer wieder fest das es an utc liegt, und das steht ja klar immanual.
alle meine bisherigen untersuchungen zeigen einen sehr geringen fehler des moduls