# Startzeit an die Jahreszeiten anpassen



## Ratoncito (16 November 2020)

Hallo,

den Zeitpunkt für das Senken und Heben der Rolladen in meinem Haus möchte ich ein wenig an die Jahreszeiten anpassen. Die Änderung der Helligkeit ist dabei an den Scheitelpunkten (21.Dezember bzw. 21.Juni) am Geringsten. An den Tagen der Tag- und Nachtgleiche (20.März bzw. 22.September) am Größten.

Die Kurve ähnelt stark einer Sinuskurve.

Für das Senken ist der Startpunkt am 21.Dezember um 19:45 Uhr und soll der ansteigenden Flanke einer Sinuskurve bis zum Scheitelpunkt am 21.Juni um 22:00 Uhr folgen. Von dort wieder zurück auf den Startwert.

Gibt es hier Programmiergenies die das hinkriegen? Und wenn möglich noch so, dass auch ich das nachvollziehen kann?

Noch eine Bemerkung.
Die Anwendungshinweise zum WagoAppScheduler und WagoAppBuilding habe ich mir schon angeschaut. Da mir aber die Grundlagen fehlen ist mir die Umsetzung zumindest im Moment zuviel.

Vielen Dank im Voraus.


----------



## Blockmove (16 November 2020)

Sonnenaufgang und Sonnenuntergang gibt es in der WagoAppTime.
Siehst du im Screenshot zu den Zeiten in deinem letzten Thread.
Ich nutze für meine Rollladen eigentlich nur Sonnenuntergang.

In der Oscat-Bibliothek gibt es auch Bausteine zum Einfallswinkel.


----------



## ccore (16 November 2020)

Ist wahrscheinlich nicht ganz so genau, aber du könntest ab dem 21.12 auf den Startpunkt 19:45, jeden Tag ca. 45s (44,4) aufaddieren. Ab dem 21.06. wieder abziehen.
Das ist halt nur erechnet. Sonnenauf und Untergang aus der WAGOAppTime ist dort sicher genauer.


----------



## Ratoncito (16 November 2020)

Hallo,

@Blockmove

Auch die WagoAppTime habe mich mir angeschaut. 

Sonnenuntergang im Dezember etwa schon um 16:30 Uhr, und Aufgang im Sommer so gegen 5:00 Uhr. 

Das passt nicht zu meinen Wünschen, ich möchte die Zeiten an den Scheitelpunkten lieber selbst vorgeben.

Danke für den Hinweis.


@ccore

Dann ist die Änderung leider linear, man erhält ein Dreieck und keinen sinusförmigen Verlauf.

Auch Dir Danke


----------



## Blockmove (16 November 2020)

Schau mal hier:
https://www.timeanddate.de/astronomie/daemmerung-phasen

Welche der Dämmerungsphasen entspricht deinen Scheitelpunkten?
Für den passenden "Scheitelpunkt" musst du dann nur die passende Formel finden.


----------



## Larry Laffer (16 November 2020)

Ratoncito schrieb:


> Sonnenuntergang im Dezember etwa schon um 16:30 Uhr, und Aufgang im Sommer so gegen 5:00 Uhr.
> 
> Das passt nicht zu meinen Wünschen, ich möchte die Zeiten an den Scheitelpunkten lieber selbst vorgeben.



Wie sieht denn im Groben die Kurve gemäß deiner Wünsche aus ?
Ich hatte mit im Groben an den Zeiten orientiert - nur z.B. im Sommer die Jalousien nicht vor 7 Uhr Morgens auffahren lassen - egal wann SA war.
Gleiches galt für das Zufahren - da habe ich die meißten bei SU oder spätestens um 21 Uhr zufahren lassen.

Gruß
Larry


----------



## Ratoncito (16 November 2020)

Hallo,

@Larry



> Die Kurve ähnelt stark einer Sinuskurve.
> 
> Für das Senken ist der Startpunkt am 21.Dezember um 19:45 Uhr und soll  der ansteigenden Flanke einer Sinuskurve bis zum Scheitelpunkt am  21.Juni um 22:00 Uhr folgen. Von dort wieder zurück auf den Startwert.



Mathematisch habe ich mich damit ehrlich gesagt noch nicht beschäftigt. Mal ganz ohne Anspruch auf Richtigkeit:
Jahr = 365 Tage
Kreis = 360°
Gesamtzahl der Minuten von Scheitel zu Scheitel = 135
Wenn man die 5° vernachlässigt entspricht das bei der Berechnung jeden Tag +1° bei dem Wert für sin.
Die Ungenauigkeit der 5 Tage könnte man durch einen Reset an den Scheitelpunkten aufheben.

Große Frage:
Kann man in e!Cockpit mit der Winkelfunktion rechnen?
Die Localtime in e!Cockpit berücksichtigt den Wechsel von Sommer- zur Winterzeit?


----------



## .:WAGO::011726:. (16 November 2020)

Hallo Wolfgang,

Der Baustein "FbCalculateSunriseSunset" aus der WagoAppBuilding berechnet Sonnenauf- und untergang. Hier könntest du mit "ADD" und "SUB" die Zeiten noch ein wenig auf deine Bedürfnisse anpassen.

Ansonsten ist das Beispielprogramm1 im Anwendungshinweis zur WagoApp Building die Premiumlösung.

Grüße aus Minden


----------



## Blockmove (16 November 2020)

Ratoncito schrieb:


> Hallo,
> 
> @Larry
> 
> ...



Winkelfunktionen kann e!Cockpit.
Du kannst dir UTC-Zeit als auch Lokalzeit ausgeben lassen
Wichtig dabei ist nur, dass du in der Weboberfläche der Steuerung die passende Zeitzone einträgst.

Wenn du deine Formel hast, dann kannst du sie recht einfach in FUP in einem Execute-Baustein eintragen.

Gruß
Blockmove


----------



## Larry Laffer (16 November 2020)

@Wolfgang:
Wenn du die Sommer-Winterzeit-Umstellung wegläßt dann ist die Kurve, aufgrund der Schrägstellung der Erdachse, eine Sinuskurve.
Aber du hast meine Frage nicht beantwortet.
Die Wago-SPS sollte auf jeden Fall auch Winkelfunktionen können - denk nur dran : hier wird nicht mit Grad gerechnet sondern im Bogenmaß ...


----------



## Ratoncito (16 November 2020)

Upps, habe gerade nur mal eben Kaffeepause gemacht und schon 3 Antworten. Vielen Dank!

@Wago-Support

Ja, die Bausteine sind recht vielseitig.

Nur, vor knapp 14 Tagen wusste ich nicht wie Codesys riecht, wie e!Cockpit schmeckt und heute baue ich EINEN.

Einfach gesagt, mir ist alles neu und ich bin mit vielem schlicht überfordert. Ich drehe mich im Kreis ohne genau zu wissen in welche Richtung ich laufen muss.
An den Beispielen in den WagoApps habe ich mich auch schon versucht. Leider fehlen mir die Grundlagen. Für ein Beispiel fehlte mir eine Bibliothek - ich habe lange gebraucht, bis ich diese gefunden habe. Danach kam ich ein kleines Stück weiter, dann fehlte wohl wieder etwas. Da habe ich aufgegeben, zumindest für den Anfang.

Meine alte SPS ist ausgefallen, es fehlen einige Funktionen. Das macht den Alltag nicht unbedingt leichter. Daher habe ich mich erst auf die wesentlichen Dinge gestürzt und möchte in den nächsten Tagen die neue Steuerung einsetzen. Die nebensächlichen Dinge wie Rolladen automatisch AUF und AB kommt später.


@Blockmove

Lokalzeit habe ich gefunden, dann gehe ich davon aus, dass dort auch die Umstellung von Sommer- auf Winterzeit automatisch geht.


@Larry

Danke für den Tip zum Bogenmaß.
Während dem Kaffee habe ich meine Gedanken zum Verlauf der Kurve durchgerecht - scheint zu stimmen.

Welche Frage habe ich nicht beantwortet?

Meinst Du damit den Verlauf der Kurve und Zeitumstellung?

Ja, die Sinuskurve passt. Mir geht es nur darum, dass die Kurve in etwa zur Jahreszeit und meinen Gewohnheiten passt. Die Rolladen im Wohnbereich mache ich sowieso von Hand runter wenn es uns danach ist, und im Rest des Hauses geht es automatisch. Und wenn keiner zuhause ist 1 Stunde früher. Es wäre nicht angebracht, wenn im Sommer die Rolladen schon um 19 Uhr runtergehen, oder im Winter erst um 22 Uhr.

Allen noch mal vielen Dank für die Hilfe.

Wenn jemand Zeit hat - ein kleines Beispiel wie man mit der Zeit und der Berechnung in FUP umgeht wäre super.
Ich breche mir bei den Datenformaten sicherlich wieder die Ohren.
Startzeit für die Kurve 20 Uhr, Endzeit 22 Uhr. Zwei Zwischenpunkte (30° - 60°  - 90°) reichen.

Es hat keine Eile


----------



## Blockmove (16 November 2020)

Hallo Wolfgang,
Stell doch mal die Formel ein.
Das Umsetzen auf SPS ist dann kein großes Thema.


----------



## Larry Laffer (16 November 2020)

@Wolfgang:
Mrine Frage war im Beitrag #6 - ich denke mal, dass du so wie ich nicht grundsätzlich ganz früh morgens (also mitten in der Nacht) im Sommer die Jalousien hoch haben willst sondern ggf. erst zum (oder nach dem) Aufstehen. Genauso ist es (oder so ähnlich) mit dem Runter.


----------



## Ratoncito (16 November 2020)

Hallo,

@Larry

sorry, den Sonnenaufgang habe ich übersehen, da es mir zuerst mal nur um den Abend ging. Aber 6 Uhr Rolladen AUF - ich hätte kein Problem damit. Heute stehe ich oft schon zu Zeiten auf, zu denen ich in meiner Sturm- und Drangzeit nach Hause kam. 

Die Details hätten zu Beginn sicherlich für Verwirrung gesorgt, daher hatte ich sie nicht erwähnt.
Die Rolläden im Schlafzimmer fahren nur dann AUF, wenn keiner zuhause ist. Und wenn keiner zuhause ist, bleiben die Rölläden noch 1 Stunde länger unten. Und auch an Sonn- und Feiertagen bleiben sie länger unten. Das hat sich so im Laufe der Zeit mal ergeben.

Wie bequem das alles ist merkt man so richtig jetzt, wo die alte SPS das nicht mehr automatisch erledigt.

Wie schon oben geschrieben würde mir ein kleines Beispiel in dem ich sehen kann wie man das richtig macht reichen.


@Blockmove

Formel? Habe ich keine, ich habe es ja auch noch nicht so gemacht 
Im Prinzip würde ich es so beschreiben:
Startzeit am 21.12. um 20:00 Uhr bis zum 21.06. um 22:00 Uhr, sind 120 Minuten Differenz
Die ganze Kurve in 4 Abschnitte (360°) unterteilt sind 60 Minuten pro 90°
Am nächsten Tag: 20:00 Uhr + (60 Minuten - sin89° * 60 Minuten)
nächster Tag: 20:00 Uhr + (60 Minuten - sin88° * 60 Minuten)
und dann so weiter bis zum 21.06. und dann das ganze zurück, also alles wieder abziehen bis zum 21.12.

Ich hoffe mal dass es richtig ist. 2 Stunden ist einfacher für das Beispiel, kann man später ja anpassen.

Noch einen schönen Abend


----------



## Blockmove (16 November 2020)

Der SEL-Baustein ist vielleicht ganz interessant für dich



In dem Beispiel fährt der Rollo bei Sonnenaufgang hoch, jedoch nicht vor 5Uhr.


----------



## Larry Laffer (17 November 2020)

Ratoncito schrieb:


> Formel? Habe ich keine, ich habe es ja auch noch nicht so gemacht
> Im Prinzip würde ich es so beschreiben:
> Startzeit am 21.12. um 20:00 Uhr bis zum 21.06. um 22:00 Uhr, sind 120 Minuten Differenz
> Die ganze Kurve in 4 Abschnitte (360°) unterteilt sind 60 Minuten pro 90°
> ...



Naja ... du musst hier eine Relation Winkel zu Tag bilden. Dafür musst du wissen, wieviele Tage seit dem 21.12. vergangen sind (wenn du im ersten Halbjahr bis) bzw. wieviele seit dem 21.06. vergangen sind (wenn du im zweiten Halbjahr bist).
Diese 182 Tage entsprechen dann deinem Winkelbereich.
Deine 2 Stunden sind dann die maximale Auslenkung der Amplitude.
Ist ein bisschen Rechnerei - das ließe sich aber z.B. in Excel schon mal schön in der Tabelle simulieren bevor du dann damit an die SPS gehst.

Ganz grundsätzlich solltest du dich hier m.E. von FUP entfernen und eher auf ST setzen. Das wird dann Vieles vereinfachen ... (auch wenn es zusätzliches, aber nicht problematisches, Lernen bedeutet)

Gruß
Larry


----------



## Heinileini (17 November 2020)

Larry Laffer schrieb:


> Naja ... du musst hier eine Relation Winkel zu Tag bilden. Dafür musst du wissen, wieviele Tage seit dem 21.12. vergangen sind (wenn du im ersten Halbjahr bis) bzw. wieviele seit dem 21.06. vergangen sind (wenn du im zweiten Halbjahr bist).
> Diese 182 Tage entsprechen dann deinem Winkelbereich.


Du verwirrst mich ein wenig, Larry.
Ich würde davon ausgehen, dass die Periode (2 x Pi) der Länge des Jahres entspricht (ca. 365,25 Tage) und zum FrühlingsBeginn startet und endet (NullDurchgang bei ansteigender SinusKurve).
Ferner, dass die mittlere TagesLänge (ebenfalls zum FrühlingsAnfang ermittelt ... oder alternativ zum HerbstAnfang) mit dieser SinusSchwingung moduliert wird.
Wenn man nun für das "WinterHalbjahr" (negative Werte der SinusKurve) und das "SommerHalbjahr" (positive Werte der SinusKurve) eine unterschiedliche Behandlung haben möchte und der Übergang zwischen beiden "sanft" erfolgen soll, kann man doch negative Werte anders skalieren als positive Werte und - so man das überhaupt will - diese auch noch auf feste Minimal- oder MaximalWerte begrenzen.
So weit, so einfach ... wenn nicht noch die Umstellerei zwischen Winter- und SommerZeit dazwischenhauen würde ... aber auch das lässt sich beherrschen.

Gruss, Heinileini


----------



## Larry Laffer (17 November 2020)

@Heinrich:
Es ist eigentlich egal, ob du den Frühlingsanfang als 0° annimmst oder den Winteranfang als 270° - entscheidend ist, dass du bezogen auf den jeweiligen Referenzpunkt die Anzahl der vergangenen Tage ermitteln musst damit du die Relation auf die 360° bilden kannst - man kann natürlich auch sagen 365 Tage ist ja nah an 360° - also sind Tage gleich Grad - ich weiß jetzt aber nicht, ob das dann vielleicht doch ungenau wird.
Ansonsten weiß ich gerade nicht was dich verwirrt ...

Gruß
Larry


----------



## Ratoncito (17 November 2020)

Hallo,

vielen Dank für die vielen Gedanken die Ihr Euch macht. Aber bevor es zu kompliziert wird möchte ich Euch ein wenig bremsen. Es geht nur um den Zeitpunkt zu dem Rolladen AUF oder AB fahren, da hält es nicht so genau.

Jahreslänge: 365 und im Schaltjahr 366 Tage
Winter: 21.12. = Scheitelpunkt
Frühling: 22.03. = 0-Durchgang 91 (Schaltjahr 92) Tage seit Winter
Sommer: 21.06. = Scheitelpunkt 91 Tage seit Frühling
Herbst: 21.09. = 0-Durchgang 91 Tage seit Sommer
Winter: 21.12. = Scheitelpunkt 92 Tage seit Herbst

Um es zu vereinfachen kann man pro Tag 1° annehmen, dann fehlen an einem Jahr 5 bzw 6 Tage, pro Halbjahr 2,5 bzw. 3 Tage.
Da sich an den Scheitelpunkten die geringste Differenz ergibt könnte man dort die Zeit für 2 bzw 3 Tage gleich lassen.

Startet man am 21.12. um 20Uhr so berechnet sich der nächste Tag: 20:00 Uhr + (60 Minuten - sin89° * 60 Minuten)
nächster Tag: 20:00 Uhr + (60 Minuten - sin88° * 60 Minuten) usw.

Hierbei habe ich angenommen das die Scheitel bei 20 und 22 Uhr liegen.

Nun muss man statt Grad noch das Bogenmaß einsetzen 1° = Pi / 180

Wenn man es komfortabel machen möchte gibt man die zwei Uhrzeiten für Start und Ziel als Variable ein und berechnet Differenz in Minuten und setzt diesen Wert statt der "60" in obigem Beispiel ein.
Und statt je Tag mit einem Grad zu rechnen kann man auch 90 / 92 einsetzen.

Wenn man für die Zeit die Localtime nimmt wäre auch die Zeitumstellung berücksichtigt! Mir geht es in der Hauptsache nicht darum die Rolladen zu einer bestimmten Helligkeit AUF und AB zu fahren, sondern passend zu meinem Tagesablauf.

Für die Programmierung wird wohl, wie schon von Euch angemerkt, strukturierter Text die richtige Wahl sein.
Habe ich noch nicht angeschaut, aber mit VBA und Access und ähnlichen habe ich mich schon mal beschäftigt. Dann werde ich, mit Eurer Hilfe, auch das schaffen.

Je mehr man sich darüber Gedanken macht, umso mehr fällt mir ein... Ich bin überrascht, was heute alles möglich ist.

Für Eure Bemühungen im Voraus schon mal vielen Dank.


----------



## Blockmove (17 November 2020)

Dann pack das Ganze mal in ein VBA-Makro und probiers in Excel.
Das ist dann nur ein ganz kleiner Schritt nach ST


----------



## Ratoncito (17 November 2020)

Hallo,

@Blöckmove



> Dann pack das Ganze mal in ein VBA-Makro und probiers in Excel.



Sorry, die wenigen von mir in Excel verwendeten Macros beschränken sich darauf, irgendwo etwas zu kopieren, Zeilen einfügen und mit dem vorher kopierten Inhalt zu füllen. Erstellt habe ich das mit der Funktion Aufzeichnen.

Mehr Erfahrung habe ich mit Access und dem VBA-Editor. Allerdings geht es da eher um Datenbankverwaltung, also Filter setzen, Daten schreiben und Eingaben verwalten. Berechnet wird da nicht viel.

Ich habe da schon in etwa eine Idee, wie die Berechnung erfolgen könnte. Aber noch keine Ahnung von ST.

Ich möchte das erst mal auf Eis legen, denn ich muss zuerst die neue Steuerung installieren. Das hat im Moment Priorität.

Danke, in ein paar Tagen werde ichs versuchen.


----------



## Heinileini (17 November 2020)

Larry Laffer schrieb:


> @Heinrich:
> Es ist eigentlich egal, ob du den Frühlingsanfang als 0° annimmst oder den Winteranfang als 270° - entscheidend ist, dass du bezogen auf den jeweiligen Referenzpunkt die Anzahl der vergangenen Tage ermitteln musst damit du die Relation auf die 360° bilden kannst - man kann natürlich auch sagen 365 Tage ist ja nah an 360° - also sind Tage gleich Grad - ich weiß jetzt aber nicht, ob das dann vielleicht doch ungenau wird.


Das sehe ich auch so. Und der Fehler, den man in Kauf nimmt, wenn man das Jahr auf 360 Tage "vereinfacht", dürfte zu verkraften sein.



Larry Laffer schrieb:


> Ansonsten weiß ich gerade nicht was dich verwirrt ...


Aus Deinem Beitrag ...



Larry Laffer schrieb:


> Naja ... du musst hier eine Relation Winkel zu Tag bilden. Dafür musst du wissen, wieviele Tage seit dem 21.12. vergangen sind (wenn du im ersten Halbjahr bis) bzw. wieviele seit dem 21.06. vergangen sind (wenn du im zweiten Halbjahr bist).
> Diese 182 Tage entsprechen dann deinem Winkelbereich.


... konnte ich nicht entnehmen, wie Du es eigentlich gemeint hast. Die FallUnterscheidung "wenn du im ersten Halbjahr bist u.s.w." liess schlimmeres vermuten.


----------



## Larry Laffer (17 November 2020)

Heinileini schrieb:


> ... liess schlimmeres vermuten.


Na ... du bist ja drauf ...


----------



## Ratoncito (25 November 2020)

Hallo,

ich möchte das Thema mal wieder aufgreifen.

Im  Prinzip geht es um Berechnungen mit Datum und Zeit. Dafür kann man  unterschiedliche Datentypen verwenden. Welchen Datentyp verwende ich,  damit ich mich nicht in ungeeigneten Typen verzettel?

Das Jahr hat vier Jahreszeiten, die Startpunkte sind:
22.03. Frühling
21.06. Sommer
21.09. Herbst
21.12. Winter

Der Verlauf der Startzeit für die Rolladen soll einer Sinuskurve folgen, deren Scheitelpunkte bei 19:45 Uhr und 22:00 Uhr liegen.
Ich würde mich mal an der Berechnung versuchen, habe aber einige Fragen.

Ich benötige:
1.) die Anzahl der Minuten zwischen 19:45 und 22:00 Uhr.
2.) die Anzahl der vergangenen Tage vom 21.09. bis heute.

Gibt es eine feste Konstante für Pi?
In welchem Datentyp lässt sich der Startpunkt des Tages am Besten berechnen und der Start auslösen?

Sind bestimmt nicht alle Fragen


----------



## Heinileini (25 November 2020)

Ratoncito schrieb:


> Gibt es eine feste Konstante für Pi?


Nur für den Fall, dass nicht: kann man "berechnen" nach der Formel Pi := 4 * ARCTAN(1)


----------



## Blockmove (25 November 2020)

Heinileini schrieb:


> Nur für den Fall, dass nicht: kann man "berechnen" nach der Formel Pi := 4 * ARCTAN(1)



Man kann sich auch ganz einfach eine globale Variable definieren und der den Wert zuweisen


----------



## Larry Laffer (25 November 2020)

Ratoncito schrieb:


> Im  Prinzip geht es um Berechnungen mit Datum und Zeit. Dafür kann man  unterschiedliche Datentypen verwenden. Welchen Datentyp verwende ich,  damit ich mich nicht in ungeeigneten Typen verzettel?


Dafür hat die SPS für das Datum den Typ DATE und für die Uhrzeit den Typ TimeOfDay.



Ratoncito schrieb:


> Ich benötige:
> 1.) die Anzahl der Minuten zwischen 19:45 und 22:00 Uhr.


Wenn du hier mit TOD (TimeOfDay) arbeitest dann gibt es da wahrscheinlich Bausteine wo du die direkt subtrahieren kannst (ich arbeite selber nicht mit Wago).
Ansonsten kannst du TOD aber in DINT um-casten und hast dann die Millisekunden, die seit 0:00 Uhr vergangen sind. Aus dieser Differenz dann Minuten zu bilden sollte dann recht simpel sein 
Für weitere Uhrzeit-Berechnungen solltest du dann auch wieder diesen Datentyp nehmen ...



Ratoncito schrieb:


> Ich benötige:
> 2.) die Anzahl der vergangenen Tage vom 21.09. bis heute.


Auch hier müßte es eigentlich Bausteine geben. Allerdings musst du berücksichtigen, dass du dann bei dem 21.09. um eine Diffenrenz bilden zu können auch immer das dazu passende Jahr mit angeben musst. Das heißt, dass du dir hier dein "Hilfsdatum" erst manuell zusammenbauen musst.
Hat die Wago hier keine Bausteine dann ist das auch nicht schlimm denn du kannst den Datentyp DATE zu INT umcasten. Der INT stellt dann die Tage dar, die (bei Siemens zumindestens) seit dem 01.01.1970 vergangen sind. Das wäre aber für dich egal weil du ja du die Subtraktion das schon passend für dich bekommst ...

Für PI würde ich mir auch, wie von Blockmove geschrieben, eine Konstante im Baustein anlegen.

Gruß
Larry


----------



## Heinileini (25 November 2020)

Larry Laffer schrieb:


> Für PI würde ich mir auch, wie von Blockmove geschrieben, eine Konstante im Baustein anlegen.


Auch?   Ist denn eine lippische lokale Konstante dasselbe wie eine ostalbische globale Variable?


----------



## Larry Laffer (25 November 2020)

In etwa ... Ja !


----------



## Ratoncito (25 November 2020)

Hallo,

also für Pi habe ich mir eine Bergische Konstante angelegt.

Mit dem Rest komme ich auf keinen grünen Zweig. Zum Testen habe ich mir einen Baustein in ST angelegt und alles mögliche mit unterschiedlichen Datentypen ausprobiert. 

Das Umwandeln von DATE_AND_Time in DATE, TIME, TOD und INT bekomme ich noch auf die Reihe, aber bei den Versuchen etwas Gescheites damit zu berechnen bin ich kläglich gescheitert.

Würde mir jemand zeigen wie der Code für eine Berechnung der Tage zwischen Datum1 und dem aktuellen Datum aussieht?
Das aktuelle Datum habe ich in DATE_AND_TIME und 
Datum1 als DATE mit Wert D#2020-1-1

Vielen Dank und noch einen schönen Abend.


----------



## Larry Laffer (25 November 2020)

Hallo Wolfgang,
mit DT (DateAndTime) kannst du so gar nichts anfangen - aber das Passende daraus holen.
Es müsste auch bei Wago einen Baustein DT_to_TOD (oder ähnlich) geben.
Ausserdem, wenn es für DATE keine direkten Bausteine gibt dann schau mal nach dem Wandeln DATE_to_INT (oder ähnlich) - und dann solltest du wieder selber klarkommen können ...

Gruß
Larry


----------



## Heinileini (25 November 2020)

"DATE bzw. DATE_AND_TIME: Intern wird das Datum in einem DWORD in Sekunden seit dem 1.Januar 1970 abgespeichert. Dieser Wert wird konvertiert."

Also vermute ich mal:

dAnzahlTage := UDINT_TO_DINT(DATE_TO_UDINT(Datum2)/86400) - UDINT_TO_DINT(DATE_TO_UDINT(Datum1)/86400) ;

Statt DATE_TO_UDINT ggfs DATE_AND_TIME_TO_UDINT verwenden.


----------



## Larry Laffer (25 November 2020)

Nein Heinrich ... einfach DATE nach INT konvertieren und dann die beiden DATE's voneinander subtrahieren - schon hast du Tage.
DT oder DateAndTime ist ein komplexer Datentyp, der sowohl das Datum wie auch die Uhrzeit beinhaltet. Ich bin mir jetzt (ohne nachschauen zu können) wegen des inneren Aufbaus nicht mehr so sicher ... ich meine aber mich erinnern zu können, dass er teilweise BCD-codiert ist und 5 oder 6 Bytes lang ist.

Gruß
Larry


----------



## Heinileini (26 November 2020)

Larry Laffer schrieb:


> Nein Heinrich ... einfach DATE nach INT konvertieren und dann die beiden DATE's voneinander subtrahieren - schon hast du Tage.


Wenn das so ist, dann kann man die CodeSys-Beschreibung in die Tonne treten, Larry!

Der erste Satz in #32 ist ein Zitat daraus und besagt, dass in dem 32-Bit-Konglomerat das Datum (DATE) bzw. Datum und Zeit (DATE_AND_TIME) in der Einheit Sekunden seit dem 1970-01-01 enthalten ist. (Und keine Rede von BCD. BCD würde die Umrechnung noch weiter erschweren.)
Konvertiert man trotzdem in INT, so gehen die höherwertigen 16 Bit verloren und das Bit 15 wird ausserdem ggfs falsch interpretiert bzw. könnte/müsste eigentlich zu einem Fehler führen. 
Übrigens hat 1 Tag 86400 Sekunden und das sind etliche mehr, als man in UINT (max. 65535) geschweige denn INT (max. 32767) unterbringen könnte.

So gesehen erdreiste ich mich, zu sagen:
Nein Larry, einfach DATE nach INT konvertieren kann nicht sein (ohne den wesentlichen Teil der Information wegzuwerfen) und die Differenz der INTs zu bilden, kann man sich dann getrost ersparen. :sad:

Gruss, Heinileini


----------



## holgermaik (26 November 2020)

Heinileini hat Recht . DT, Tod & Date sind 32bit DWord mit unterschiedlichen Zeitrastern.
@Wolfgang
Da du die "WagoAppTime" sowieso schon im Projekt hast, schau doch mal im Kapitel 3.1 "Calculations". Hier gibt es verschiedene FUN zur Berechnung von Differenzen von Date und TOD.

Holger


----------



## Larry Laffer (26 November 2020)

Sollte es so sein dann nehme ich alles zurück ... sorry. Ich muss hier jetzt gestehen, dass ich das von der Siemens-Seite her beantwortet habe. In dem Fall ist es dann wohl so, dass die jeweiligen, hier genannten, Datentypen zwischen CodeSys und Siemens nicht genormt aufgebaut sind - Schade ... 

Gruß
Larry


----------



## Ratoncito (26 November 2020)

Hallo,

vielen dank für die Antworten.

@Holger



> Da du die "WagoAppTime" sowieso schon im Projekt hast, schau doch mal im  Kapitel 3.1 "Calculations". Hier gibt es verschiedene FUN zur  Berechnung von Differenzen von Date und TOD.



Danke für den Hinweis. Gibt es die Beschreibung auch in Deutsch? Ich habe nur die englische Version gefunden, und da übersehe ich gerne mal ein paar wichtige Details.

Werde mal schauen, ob ich damit klarkomme.

Noch einen schönen Tag


----------



## Blockmove (26 November 2020)

Ratoncito schrieb:


> Gibt es die Beschreibung auch in Deutsch? Ich habe nur die englische Version gefunden, und da übersehe ich gerne mal ein paar wichtige Details.



Deutsch verspricht Wago schon lange.


----------



## Ratoncito (26 November 2020)

Hallo,



> Deutsch verspricht Wago schon lange.



Na ja, für einen deutschen Hersteller ist das ja auch eine Herausforderung 

Der Hinweis auf die Funktionen ist sehr hilfreich. Wenn man weiss, wo man suchen muss ist vieles einfacher...
Ich scheine auf einem guten Weg zu sein.

Noch eine Frage:
Für meine Berechnungen benötige ich vier Daten mit der Initialisierung
Date_1 = D#2019-12-21
Date_2 = D#2020-03-22
Date_3 = D#2020-06-21
Date_4 = D#2020-09-21
Beim Jahreswechsel soll sich das Jahr automatisch anpassen. Wie ist der Code in ST um das Jahr automatisch in die Initialisierung einzubauen?

Vielen Dank


----------



## Heinileini (26 November 2020)

Ratoncito schrieb:


> 1. Ich scheine auf einem guten Weg zu sein.
> 
> 2. Für meine Berechnungen benötige ich vier Daten mit der Initialisierung
> Date_1 = D#2019-12-21
> ...


Zu 1.: Das hatte ich ja schon angedeutet! 

Zu 2.: Benötigst Du wirklich? Warum vier "Datümer"?
Wenn Du die PeriodenLänge der SinusSchwingung weisst und wo Du die Null findest (NullDurchgang bei ansteigender Kurve - in Deinem Fall der FrühlingsAnfang), dann ist damit doch schon fast alles definiert. Es fehlt nur noch die Amplitude der Schwingung. Und an die Genauigkeit stellst Du ohnehin keine übertriebenen Ansprüche.
Ich habe noch nicht nachgeforscht, wann zum WinterBeginn und zum SommerBeginn genau SonnenAufgang und SonnenUntergang stattfinden. Das wären die Daten, über die Du auf die Amplitude schliessen kannst (einmalig zum ZeitPunkt des Programmierens - nicht bei jedem Hochlauf der PLC und nicht Jahreszahl-abhängig - eine leichte Verschiebung von Jahr zu Jahr durch die tatsächliche JahresLänge von ca. 365,25 Tagen wollten wir doch grosszügig und wohlwollend ignorieren, zumal sich die Verschiebung auch periodisch verhält, also nach ca. 4 Jahren wiederholt).

Mal ganz grundsätzlich zum Thema Initilisierung der Daten und dem Manipulieren dieser Daten. 
Initialisierung immer mit festen Werten (werden von Dir beim Programmieren festgelegt). 
Eine Nachbearbeitung dieser Daten in der PLC kann natürlich erfolgen, muss aber auch von Dir programmiert werden. 
Das automatische "Updaten" der JahresZahl musst Du programmieren.
Ganz automatisch (ohne dass Du nachhilfst) geht da nix, behaupte ich einfach mal. 



In Excel angedacht. Waagerecht die Zeitspanne 1.Jan. .. 31.Dez.. Senkrecht die Uhrzeit 00:00 ..24:00.
Die Umstellung Winterzeit <=> Sommerzeit habe ich willkürlich gehandhabt - da könnte/müsste man Jahreszahl-abhängig anpassen.
Wie bereits gesagt, für die SonnenAuf- und UntergangsZeiten habe ich keine "belastbaren" Werte genommen, sondern sie willkürlich festgelegt, nur um die "Tendenz" zu veranschaulichen.

PS:
Sorry, die Kurve "Hell" bezieht sich nicht auf die Uhrzeit, sondern die Zeitspanne zwischen SonnenAufgang und SonnenUntergang.


----------



## Ratoncito (26 November 2020)

Hallo Heinileini,

mache Dir bitte nicht soviel Mühe. Ich möchte Deine Zeit nicht überbeanspruchen. Konkrete Fragen habe ich mehr als genug...

Ich hatte schon zu Beginn geschrieben, dass meine Lebensgewohnheiten entscheidender auf die Kurven sind, als der Helligkeitsverlauf. Ich weiss genau, wo ich hin will. Bin aber immer für Anregungen und Kommentare offen.

Klugscheißermodus an:
Datümer sind Daten (von Singular Dat)  
Klugscheißermodus aus

Es hört sich aber immer blöd an

Ich hatte das ganze irgendwann beim Kaffee mal kurz überschlagen, und da ist mir aufgefallen, dass man beim 0-Durchgang das Vorzeichen wechseln muss. Bin mir aber nicht ganz sicher. Daher habe ich erst mal 4 Daten vorgesehen. 

Bei der Formel zur Berechnung bin ich mit meinen Bemühungen noch nicht angekommen. Als Erstklässler macht man halt nur kleine Schritte und bleibt auch schon mal irgendwo hängen.

Nochmal zu meiner Frage zum Zusammenbau des Datums

Ich stelle mir das so vor, dass man aus dem aktuellen Datum die Jahreszahl rausschneidet und in die Variable mit Monat und Tag einbaut und dieses als Initialwert zum Beispiel für Herbst übergibt.
Für den Winter muss die Jahreszahl um 1 verringert werden.

Bin aber mal wieder ahnungslos, wie man so etwas ausschneidet und wieder zusammenfügt.


----------



## Heinileini (26 November 2020)

Ratoncito schrieb:


> ... da ist mir aufgefallen, dass man beim 0-Durchgang das Vorzeichen wechseln muss. Bin mir aber nicht ganz sicher. Daher habe ich erst mal 4 Daten vorgesehen.


Genau das ist ja der "Trick" an der Sache, Wolfgang, dass das zwar nach MehrAufwand klingt, aber in Wirklichkeit die Angelegenheit vereinfacht!
Du bildest immer die Differenz "aktuelles Datum - Datum des NullPunktes (XXXX-03-22)":
- aktuelles Datum kleiner als NullpunktDatum ergibt automatisch eine negative Anzahl Tage bis zum NullPunkt
- aktuelles Datum grösser als NullPunktDatum ergibt automatisch eine positive Anzahl Tage bis zum NullPunkt
Da muss man nichts tricksen. Das vermutete Problem löst sich in Wohlgefallen auf. Wenn das doch immer so einfach wäre! 
Konnte ich Dich jetzt überzeugen, dass Du mit dem einen Datum besser bedient bis, als mit den vier von Dir eingeplanten?
Da gibt es auch nicht die Hürde, dass Du auf den WinterAnfang des VORjahres zurückgreifen musst, während sich die anderen 3 auf das aktuelle Jahr beziehen. 

Zum Thema, die Jahreszahl in einem Datum zu ändern, ohne die restlichen Sachen zu verfälschen, möchte am liebsten gar nichts sagen, da ich in CodeSys nicht zu Hause bin. 
In Excel bzw. VBA kann ich es (mir zu Not "erarbeiten", nachlesen, probieren, nochmal überlegen u.s.w. ... ). In CodeSys könnte ich mir sicherlich das Nötige anlesen und mir etwas überlegen, aber mal eben aus dem Ärmel schütteln kann ich es nicht und testen auch nicht. Das ist nicht sooo ganz einfach, weil die Jahre und die Monate unterschiedlich lang sind.
Man sollte schon die Hilfsmittel nutzen, die in der ProgrammierSprache schlummern, ehe man alles "von Hand" rechnet. Ich denke dabei z.B. an die Umwandlung eines Datums in einen String, in dem String zu ändern und dann wieder zurückzuwandeln. 

Gruss, Heinileini

PS:
Ja, ich weiss natürlich, dass die Mehrzahl von Datum Daten ist. Aber leider assoziiert man mit Datum i.A. etwas anderes als den Singular von Daten und mit Daten etwas anderes als den Plural von Datum.
Deshalb lasse ich mich schonmal verleiten, meine ganz eigenen PluralFormen "Datümer" oder (es geht noch umständlicher!) "Datümlichkeiten" zu verwenden, wenn ich die Mehrzahl eines ganz bestimmten DatenTyps meine.


----------



## Ratoncito (26 November 2020)

Hallo,

@Heinilein

Ja ja, die Datums.
Das erste Mal bin ich recht hinterhältig darüber gestolpert. Ich musste einen einzelnen Wert eingeben. In der recht umfangreichen Bedienungsanleitung war immer nur von "Datum" die Rede, aber das Datum ließ sich egal in welcher Schreibweise dort nicht eingeben und sorgte immer für eine Fehlermeldung. Weiter sage ich besser nichts dazu 

Nun noch mal zu Deinen "Trick"
Auf die Schnelle hatte ich das nicht durschaut und muss mir das mal ganz in Ruhe anschauen und durchrechnen. 


Nach dem Hinweis auf die TimeApp und deren Funktionen kam doch ein ganzes Stück weiter.

Als Anfänger habe ich einiges ausprobiert und bin immer wieder auf Probleme gestoßen.
In der ersten IF-Anweisung zur Ermittlung der Jahreszeit würde ich gerne die 2 IF-Anweisungen zusammenfassen indem man auf "Zwischen" prüft. Ich habe einiges probiert aber immer ohne den gewünschten Erfolg.

In dieser IF-Anweisung kann ich zwar einen Wert auf TRUE setzen, aber nicht die in der IF-Anweisung darunter ausgeführte Berechnung durchführen. Warum auch immer.

Am Ende hatte ich noch verschiedene Berechnungen ausprobiert die in die Richtung der Sinuskurve gehen sollen, aber ich scheitere schon am "Kleinen 1x1".


Allen die mir hier ein wenig auf die Sprünge helfen vielen Dank.



```
VAR
    Winter: DATE := D#2019-12-21;
    Fruehling: DATE := D#2020-3-22;
    Sommer: DATE := D#2020-6-21;
    Herbst : DATE := D#2020-9-21;
    // Tage zwischen aktueller Jahreszeit
    Tage_Diff_Ges: DINT;
    //  Tage zwischen Start und aktuell
    Tage_Diff_Akt: DINT;
    // Uhrzeit 23.12.
    AB_Winter: TOD := TOD#19:45:00;
    // Uhrzeit 21.06.
    AB_Sommer: TOD := TOD#22:00:00;
    AB_Diff: REAL;
    // Minuten zwischen AB Winter & Sommer
    AB_Minuten: REAL;
    // Aktuelles Datum
    Datum_Aktuell: DATE;
    // es ist Frühling
    M_Fruehling: BOOL;
    // es ist Sommer
    M_Sommer: BOOL;
    // es ist Herbst
    M_Herbst: BOOL;
    // es ist Winter
    M_Winter: BOOL;
    WR_1: DINT;
    Minute: REAL;
END_VAR

//Berechnung der Minuten 
//AB_Diff := FuTimeDifference (AB_Winter, AB_Sommer);
//AB_Minuten := AB_Diff /60;
AB_Minuten := FuTimeDifference (AB_Winter, AB_Sommer) / 60;        //Minuten zwischen AB Winter & Sommer
//
Tage_Diff_Ges := FuDifferenceDATE (Winter, Fruehling);                    //Tage zwischen Winter & Sommer
//
Datum_Aktuell := TO_DATE (Merker.Uhrzeit);                                    //Aktuelles Datum
//
// Berechnung der Tage
IF Datum_Aktuell > Sommer THEN                                                    //Ermittlung der aktuellen Jahreszeit
    IF Datum_Aktuell < Winter THEN
        M_Herbst := TRUE;
    END_IF
Tage_Diff_Akt := FuDifferenceDATE (Herbst,Datum_Aktuell);        //Tage zwischen Start Herbst und heute
END_IF;
IF M_Herbst := TRUE THEN
        WR_1 := Tage_Diff_Ges + Tage_Diff_Akt;    
END_IF
Minute := Tage_Diff_Akt/3;
```


----------



## Thruser (26 November 2020)

Hallo,

ich habe gerade gesehen, daß die WagoAppTime Bibliothek ziemlich mächtige Funktionen hat. So gibt es unter '06 Number of days' die Funktion FuDaysSinceJan01. Die berechnet die Anzahl der Tage seit dem 1. Januar für das gegebene Datum in dem Jahr.

Basierend auf auf Deiner Überlegung mit dem Sinus könnte man so vorgehen.

Wir nehmen mal den 21.03. als Start und sagen das ist 0. Der 21.06. wäre dann 1, der 21.09. wieder 0 und der 21.12. -1. Das sind jetzt erst einmal Annahmen, so ganz stimmt das nicht, dazu später.

Der Sinus von 0° ist 0, 90° = 1, 180° = 0 und 270° = -1, aber das ist ja bekannt.

Nun ist der 21.03. der 80. Tag nach dem 01.03. (zumindest in einem Schaltjahr).Der 21.06. der 172. Tag etc.

Umrechnung des Tags in Grad wäre

```
TagGrad = Tag / 366 * 360 //Wieder Schaltjahr
```
nun noch den Offset vom 21.03. mit rein. Die negativen Werte für ein Datum zwischen dem 01.01. und dem 21.03. stören die Funktion nicht.

```
TagGrad = (TageSeit01-80) / 366 * 360
```
in Bogenmaß dann

```
TagBogen = (TageSeit01-80) / 366 * 360 * Pi / 180 = (TageSeit01-80) / 366 * 2 * Pi
```

Der Sinus wäre dann

```
x = sin((TageSeit01-80) / 366 * 2 * Pi)
```

Leider paßt das nicht genau mit den anderen Daten, so ist der größte Wert am 19.06. und am 20.06. anstelle des 21.06. und im Herbst ist es der 19.09.

Einfache Anpassung wäre es z.B. ab dem 21.06. mit dem Cosinus (mit Offset 172 Tage) zu arbeiten, ab dem 21.09. mit -1*Sinus (Offset ...) und ab dem 21.12. mit -1*Cosinus (Offset ...), abzufragen einfach mit IF. Besser wären natürlich bei 45°, 135°, 225° und 315°.

Jetzt hast Du erst einmal die Sinuswerte. Wenn ich es richtig verstanden habe, willst Du am kürzesten Tag (Sinus = -1) schon z.B. ab 19:00 Uhr und am längsten Tag (Sinus = 1) ab 22:00 Uhr die Rolläden herunterfahren lassen. In den Zeiten dazwischen in Abhängigkeit vom Sinus.

Da kannst Du jetzt die Sinuswerte linear von -1 ... 1 nach 19:00 ... 22:00 (definiert als TOD) mit der Zweipunkteform der Geradengleichung (s. Wikipedia) umrechnen. Vorteil ist hier, daß Du gleich mit der richtigen Tageszeit arbeitest und einen Vergleich mit der aktuellen Tageszeit machen kannst: 

```
RolladenUnten = aktuelleZeit >= ZeitAbends
```

Ähnlich geht es dann morgens für Rolladen hoch, da mußt Du die Zeiten umkehren: -1 ... 1 nach 9:00 ... 6:00 (Beispiel)

```
RolladenUnten = (aktuelleZeit <= ZeitMorgens) ODER (aktuelleZeit >= ZeitAbends) //Abends schon mit berücksichtigt
```
oder

```
RolladenOben = (aktuelleZeit >= ZeitMorgens) UND (aktuelleZeit <= ZeitAbends)
```

Um mit dem Schaltjahr richtig umzugehen bei der obigen Berechnung kann man mit auf die Funktion FuNumDaysYear ('06 Number of days') zurückgreifen, die gibt an ob das Jahr 365 oder 366 Tage hat.

Wenn Du die Umrechnungsfunktionen aus der Bibliothek nimmst, solltest Du auch keine Probleme mit Sommer- und Winterzeit, sowie der lokalen Zeit haben. Hoffe ich zumindest.

Als nächstes stellt sich die Frage, ob Du stets mit denselben Daten arbeiten willst oder diese abhängig des realen Kalenders nehmen willst. Nach Wikipedia (Jahreszeit) beginnt der Frühling zumindest bis 2027 immer am 20.03., Sommer wechselt zwischen 20. und 21.06. Für Herbst und Winter gilt ähnliches.

Du könntest Dir das jetzt auch noch alles berechnen oder Du machst einfach ein Array mit den Daten auf. Am besten in dieser Form

```
Datum : ARRAY[2020..2027] OF ARRAY[1..4] OF INT := [[79,171,265,355],[78,171,264,354]];//sind jetzt nur die Jahre 2020 und 2021, Rest muß nachgepflegt werden
```
dann kann man über Datum[2021][2] z.B. auf die Anzahl der Tage für den Sommeranfang 2021 zugreifen.


Gruß

PS: Auf die verschiedenen Datenformate mußt Du noch achten. Das ist jetzt noch nicht berücksichtigt. Auch ist das noch kein ST Code.
Komme jetzt auch nicht mehr dazu das komplett in ein Programm zu fassen. eventuell morgen.


----------



## Heinileini (27 November 2020)

WOW! Dagegen komme ich natürlich nicht an! 

Ich versuche es erstmal so ...

```
FUNCTION_BLOCK QuattroStagioni

Var_Input
    datAktuell : DATE_AND_TIME ; // ??
    dtMrz23    : DATE ; // ??
End_Var
    
Var_Output     
    bFrühlg    : BOOL ;
    bSommer    : BOOL ;
    bHerbst    : BOOL ;
    bWinter    : BOOL ;
End_Var
    
Var
    dAnzTage   : DINT ;
    rPi        : REAL ;
    rAnzTage   : REAL ;
    rAbstRad   : REAL ;
    rSin       : REAL ;
    rCos       : REAL ;
End_Var

rPi := 4.0 * ATAN(1.0) ;

dAnzTage := UDINT_TO_DINT(DATE_AND_TIME_TO_UDINT(datAktuell)/86400) - UDINT_TO_DINT(DATE_TO_UDINT(dtMrz23)/86400) ; // ??
rAnzTage := DINT_TO_REAL(dAnzTage) ;
rAbstRad := 2.0 * rPi * rAnzTage / 365.0 ;
rSin := SIN(rAbstRad) ;
rCos := COS(rAbstRad) ;

bWinter := rSin <= 0 AND rCos >= 0 ;
bFrühlg := rSin >= 0 AND rCos >= 0 ;
bSommer := rSin >= 0 AND rCos <= 0 ;
bHerbst := rSin <= 0 AND rCos <= 0 ;

END_FUNCTION_BLOCK
```
... , indem ich Deiner Frage nach den IFs geschickt ausgewichen bin! 

Aber jetzt zu den IFs:
Ich vermute Du willst für jede Jahreszeit eine BOOLsche Variable haben, die aussagen soll, ob die jeweilige Jahreszeit gerade herrscht.
Du machst die Variable zu TRUE, wenn zwei Bedingungen zutreffen, ABER sie wird nie wieder FALSE! Oder habe ich die Stelle übersehen?

```
IF aktuellerTag >= FrühlingsAnfang AND aktuellerTag < SommerAnfang THEN
    Frühling := TRUE ;
ELSE
    Frühling := FALSE ;
END_IF ;
```
könnte man schreiben, aber so geht es viel einfacher:

```
Frühling := aktuellerTag >= FrühlingsAnfang AND aktuellerTag < SommerAnfang ;
```

Gruss, Heinileini


----------



## Ratoncito (27 November 2020)

Upps, über Nacht waren die Heinzelmännchen aktiv 

@Heinileini
Ja, Dein "Trick" ist okay. Habe ich so vorher nicht bedacht und vereinfacht das ganze drumherum gewaltig. Ist so gut, könnte fast von mir sein 

Nun zum Rest
Vermutlich hatte ich den Funktionsblock nur falsch benannt 

Bei der Aufteilung in vier Abschnitte hätte ich die jeweilige Berechnung in den entsprechenden Abschnitt gepackt. Der Ansatz war nur für eine Jahreszeit, der Rest sollte folgen. Aber das erübrigt sich ja nach Deinem "Trick".

Bei der Verwendung von AND hatte ich aktuellerTag nicht zweimal aufgerufen. ok
Bleibt immer noch die Frage, warum die Abfrage nach TRUE funktioniert, aber an der Stelle keinerlei Berechnung möglich ist. Ist zwar nicht mehr nötig, aber es interessiert mich schon.


@Thruser
Das scheint auf den ersten Blick eine geniale Lösung zu sein.
Da brauche ich sicher den ganzen Tag um das Umzusetzen (wenn ich es überhaupt hinbekomme)
Nur noch eine Bemerkung zur Genauigkeit. Ob der Scheitelpunkt einen Tag früher oder später ist, juckt keinen und ist unwichtig.
Und wann der tatsächliche Frühlingsanfang ist interessiert auch niemanden.


Vielen Dank, da habe ich was zu tun. Bin gespannt, ob ich das hinbekomme


----------



## Ratoncito (27 November 2020)

Hallo,

nochmal ich. 

Die Anleitung von Thruser habe ich überraschend schnell umsetzen können. Es sieht so aus, als hätte ich keinen Fehler eingebaut.

Nun bin ich an den Punkt angekommen, wo ich die berechneten Minuten (REAL) zu der Zeit (TOD) addieren müsste.
Da gibt es mal wieder Probleme wegen dem Datentyp.


----------



## Heinileini (27 November 2020)

Ratoncito schrieb:


> Bleibt immer noch die Frage, warum die Abfrage nach TRUE funktioniert, aber an der Stelle keinerlei Berechnung möglich ist. Ist zwar nicht mehr nötig, aber es interessiert mich schon.


Sorry, die Frage hatte ich gar nicht so richtig verstanden. 

```
IF M_Herbst := TRUE THEN
        WR_1 := Tage_Diff_Ges + Tage_Diff_Akt;    
END_IF
```
Drei Dinge fallen mir zu diesen drei Zeilen ein:
1. M_Herbst := TRUE ist eine WertZuweisung =) und kein Vergleich (=).
2. Ein Vergleich mit TRUE ist möglich, aber überflüssig. Statt 'IF M_Herbst = TRUE THEN' kann man schreiben 'IF M_Herbst THEN'.
  Und statt 'IF M_Herbst = FALSE THEN' kann man schreiben 'IF NOT M_Herbst THEN'.
3. Hinter 'END_IF' fehlt das Semikolon.
Der Compiler hat sich nicht zu den Punkten 1. und 3. gemeldet?


----------



## Thruser (27 November 2020)

Hallo,

versuch mal

```
FUNCTION FuRolladenUnten : BOOL
VAR_INPUT
    dtZeit : DT;       //aktuelle Zeit
    tdMorgensMin :TOD; //früheste Zeit morgens
    tdMorgensMax : TOD;//späteste Zeit morgens
    tdAbendsMin : TOD; //früheste Zeit abends
    tdAbendsMax : TOD; //späteste Zeit abends
END_VAR
VAR
    iTageSeit01 : INT;
    iTageJahr : INT;
    rX : REAL;
    aDatum : ARRAY[2020..2027] OF ARRAY[1..4] OF INT := [[79,171,265,355],
                                                         [78,171,264,354]];//sind jetzt nur die Jahre 2020 und 2021, Rest muß nachgepflegt werden

END_VAR
VAR_OUTPUT
    tdSchaltzeitMorgens : TOD;
    tdSchaltzeitAbends : TOD;
END_VAR
```


```
iTageSeit01 := FuDaysSinceJan01(DT_TO_DATE(dtZeit));
iTageJahr := FuNumDaysYear(DT_TO_DATE(dtZeit));

rX := SIN(INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1])/INT_TO_REAL(iTageJahr)*2.0*3.1415);

//y = (y2-y1)/(x2-x1)(x-x1)+y1
tdSchaltzeitMorgens := REAL_TO_TOD((TOD_TO_REAL(tdMorgensMin)-TOD_TO_REAL( tdMorgensMax))/INT_TO_REAL(1-(-1))*(rX-INT_TO_REAL(-1))+TOD_TO_REAL(tdMorgensMAX));

tdSchaltzeitAbends := REAL_TO_TOD((TOD_TO_REAL(tdAbendsMax)-TOD_TO_REAL(tdAbendsMin))/INT_TO_REAL(1-(-1))*(rX-INT_TO_REAL(-1))+TOD_TO_REAL(tdAbendsMin));

FuRolladenUnten := (DT_TO_TOD(dtZeit) <= tdSchaltzeitMorgens) OR (DT_TO_TOD(dtZeit) >= tdSchaltzeitAbends);
```




Gruß


----------



## holgermaik (27 November 2020)

> Nun bin ich an den Punkt angekommen, wo ich die berechneten Minuten (REAL) zu der Zeit (TOD) addieren müsste.


TOD ist ein 32bit DWord mit einem Zeitraster von 1 Millisekunde. 
-> wandeln der Real in DINT
-> Multiplizieren mit 60(Sekunden) 
-> Multiplizieren mit 1000(ms)
-> wandeln der Zahl in Time
diese kannst du jetzt zu TOD addieren oder subtrahieren


----------



## Ratoncito (27 November 2020)

Hallo,

@Heinilein

Zu 1 und 3 gibt es keine Meldung. Funktioniert beides.

Der kleine Unterschied zwischen Zuweisung und Vergleich ist mir nicht aufgefallen.


```
IF Datum_Aktuell > Sommer THEN                                                    //Ermittlung der aktuellen Jahreszeit
    IF Datum_Aktuell < Winter THEN
        //M_Herbst := TRUE;
        //Minute := 7/3;
    END_IF
Tage_Diff_Akt := FuDifferenceDATE (Herbst,Datum_Aktuell);        //Tage zwischen Start Herbst und heute
END_IF
Minute := 7/3;
```

Mal ganz abgesehen davon ob der Code Sinn macht oder nicht. Die Berechnung von Minute funktioniert am Ende des Codes, innerhalb von IF nicht.

Zu IF THEN

IF Datum_Aktuell BETWEEN Sommer AND Winter THEN
IF Datum_Aktuell > Sommer AND < Winter THEN

oder so ähnlich funktioniert nicht?

IF THEN und Verwandten kenne ich im Prinzip schon, aber die erlaubten Kombinationen und Schreibweisen sind hier ein wenig anders.

PS
Da sind noch 2 Antworten, werde ich ausprobieren. Gebt mir etwas Zeit, melde mich dann.


----------



## Thruser (27 November 2020)

Hallo,


holgermaik schrieb:


> TOD ist ein 32bit DWord mit einem Zeitraster von 1 Millisekunde.
> -> wandeln der Real in DINT
> -> Multiplizieren mit 60(Sekunden)
> -> Multiplizieren mit 1000(ms)
> ...


so in der Art hätte ich es normalerweise auch gelöst.

Hatte hier jetzt nur erst einmal als Schnellschuß die _TO_ Funktionen genommen zum Testen. Und es scheint damit ohne Probleme zu funktionieren.

Gruß


----------



## Ratoncito (27 November 2020)

Hallo Thruser,

mal ganz abgesehen davon, dass ich den Code nicht nachvollziehen kann, habe ich die Berechnung für tdSchaltzeitAbends mal eingegeben.
tdAbendsMax und tdAbendsMin sind 22:00 und 19:45

Das Ergebnis ist 20:52:30

Wenn ich mich zu Fuß nicht verrechnet habe, sollte ich aber bei 20:21 Uhr liegen.
Nach den zuvor genannten Formeln komme ich auf 99,1 Minuten.
22:00Uhr minus 99 Minuten ergibt ebenfalls 20:21Uhr.

Fehlen eventuell noch die 80Tage?


----------



## Thruser (27 November 2020)

Hallo,


Ratoncito schrieb:


> Hallo Thruser,
> 
> mal ganz abgesehen davon, dass ich den Code nicht nachvollziehen kann, habe ich die Berechnung für tdSchaltzeitAbends mal eingegeben.
> tdAbendsMax und tdAbendsMin sind 22:00 und 19:45
> ...



ich habe mal manuell nachgerechnet.

19:45 bis 22:00 Uhr sind 135 Minuten.

Am 21.12. ist die Schaltzeit 19:45 Uhr, am 21.06. ist sie 22:00 Uhr, richtig?

Der 21.03. ist genau die Mitte, also 135 Minuten/2 + 19:45 = 67,5 Minuten + 19:45 = 20:45 + 7,5 Minuten = 20:52:30.

Oder habe ich da etwas falsch verstanden?

Gruß


----------



## Heinileini (27 November 2020)

Ratoncito schrieb:


> 1. IF Datum_Aktuell BETWEEN Sommer AND Winter THEN
> 2. IF Datum_Aktuell > Sommer AND < Winter THEN
> oder so ähnlich funktioniert nicht?


Zu 1.: Zum Thema BETWEEN habe ich bei CodeSys nichts gefunden, ist mir aber auch von anderen Sprachen (noch) nicht bekannt.
Sieht mir ein Bisschen nach Wunschdenken aus. 
Das Schreiben von (Angst-)Klammern hätte vielleicht geholfen, den Fehler einzukreisen?
Man könnte natürlich eine Funktion namens BETWEEN schreiben, die mit den drei Parametern versorgt werden muss. Bestimmt hat schon jemand so etwas gemacht.
Ich wundere mich immer wieder, für welche Problemchen schon längst vorgefertigte Lösungen geschaffen wurden. Aber muss ich mir das antun, mir die ganzen Namen und Funktionsweisen zu merken oder zusammenzusuchen? Nur um hinterher festzustellen, dass die Funktion doch nicht ganz das tut, was ich mir davon versprochen habe? Da schreibe ich lieber mit den "sparsamen" Mitteln einer ProgrammierSprache gleich das hin, was ich haben will ... meistens geht das viel schneller.

Zu 2.: Wie würdest Du das in FUP umsetzen?
"Datum ist grösser als Datum1 und kleiner als Datum2" ist umgangssprachlich gedacht und formuliert und überfordert einen tumben Computer total.
Für einen Programmierer bleibt also immer genügend Arbeit. Er muss ständig überlegen "*wie* sage ich's meinem Computer?".
Ehrlich gesagt, z.B. die Intensität mit der Excel ständig mitdenkt und versucht meine Absichten in seine Interpretationen "umzuoptimieren", geht mir manchmal ganz schön auf den Geist! 
Da schreibe ich doch lieber den einen VariablenNamen zweimal hin, statt dem Computer zu überlassen, wie er die unvollständigen Angaben ergänzt, nach eigenem Gutdünken, abhängig von seiner Tagesform oder vom Wetter. 
Vergleich1 und Vergleich2: Ergebnis ist jeweils vom Typ BOOL. Die beiden VergleichsErgebnisse werden mit AND verknüpft und das Ergebnis daraus ist wieder vom Typ BOOL.
Auch Deine umgangssprachliche Formulierung impliziert natürlich zwei Vergleiche. Die Vergleiche werden also nicht eingespart. Nur bei dem zweiten Vergleich schenkt man sich die Angabe, *was *womit verglichen werden soll (wahrscheinlich, um einen stilistischen "WiederholungsFehler" zu vermeiden oder aus Bequemlichkeit).

Ich habe keine Erklärung für Dein Phänomen, warum die Berechnung in der IF-Selektion nicht ausgeführt wird. Passen die Abfragen, z.B. die DatenTypen, die miteinander verglichen werden, passen die Werte der Variablen, so dass der Zweig mit der Berechnung durchlaufen wird?


----------



## Heinileini (27 November 2020)

Thruser schrieb:


> Oder habe ich da etwas falsch verstanden?


Ich habe noch gar nichts verstanden, Thruser und Wolfgang.
Was rechnet ihr da? Fällt das schon in den Bereich "persönliche Gewohnheiten"?
Ich habe noch gar nicht verstanden, wie die Überleitung von den Jahreszeiten zu den Rollladen-Aktionen unter Berücksichtigung der persönlichen Gewohnheiten im einzelnen aussehen soll. :-(


----------



## Ratoncito (27 November 2020)

Hallo Thruser,

ja, das stimmt. 

Allerdings hatte ich
tdSchaltzeitAbends 
schon für die Zeit für heute gehalten. Da habe ich zu weit gedacht.
Ehrlich gesagt kann ich dem nicht mehr folgen. Da müsste dann ja noch die Verschiebung von 80 Tagen eingebaut werden?

Ich werde mal mein Glück versuchen.


----------



## Thruser (27 November 2020)

Ratoncito schrieb:


> Da müsste dann ja noch die Verschiebung von 80 Tagen eingebaut werden?



Die sind schon drin, und zwar hier

```
aDatum[FuYear(DT_TO_DATE(dtZeit))][1]
```
bzw. hier

```
aDatum : ARRAY[2020..2027] OF ARRAY[1..4] OF INT := [[[COLOR=#ff0000][B]79[/B][/COLOR],171,265,355],
                                                         [78,171,264,354]];//sind jetzt nur die Jahre 2020 und 2021, Rest muß nachgepflegt werden
```

Das Datum aus dem Bild (DT#2020-03-21-10:00:0) war nur mein Testdatum, mit dem habe ich das ausprobiert. Dort kannst Du auch das heutige Datum DT#2020-11-27-14:00:0 eintragen oder gleich mit der Zeitfunktion verknüpfen, die Dir die aktuelle Zeit gibt.

Hier mal als Excel Diagram


Gruß


----------



## Ratoncito (27 November 2020)

Hallo Heinileini,



> Ich habe noch gar nichts verstanden, Thruser und Wolfgang.
> Was rechnet ihr da? Fällt das schon in den Bereich "persönliche Gewohnheiten"?
> Ich habe noch gar nicht verstanden, wie die Überleitung von den  Jahreszeiten zu den Rollladen-Aktionen unter Berücksichtigung der  persönlichen Gewohnheiten im einzelnen aussehen soll.



Thruser hat in Beitrag #44 die Eierlegendewollmilchsau gepostet.

Die hatte ich recht schnell nachgebaut und als Ergebnis die Minuten für den heutigen Tag erhalten. Leider konnte ich dieseMinuten nicht von 22Uhr abziehen.
Darauf kam der Post #49 mit von dem ich annahm, dass dort schon die aktuelle Startzeit berechnet würde.
Daher die Fragen.


Zu 1 und 2
BETWEEN AND habe ich noch von Access im Kopf, da geht sowas.

Das Problem mit der Berechnung
Außerhalb der IF_Anweisung funktioniert sie, innerhalb nicht. Warum auch immer, ich habe es mal auf Seite gelegt.

Im Moment interessiert mich gewaltig die Berechnung für Rollade AB...


----------



## Ratoncito (27 November 2020)

Hallo Thruser,

die Verschiebung im Schaltjahr war mir egal, daher hatte ich das nicht mit eingebaut. Mir fehlt der Durchblick...

Werde ich gleich nachholen und das Ergebnis melden.

Jetzt werde ich aber erst mal einen Reset bei mir machen und eine kleine Runde bei dem schönen Sonnenschein machen.

Bis nachher...


----------



## Thruser (27 November 2020)

Ich hatte das nicht erst später integrieren wollen und so die Grundlagen schon einmal geschaffen, auch die Anpassungen wegen der leichten Verschiebungen

Das Array müßte man nach diesem Muster weiter befüllen



Gruß


----------



## Thruser (27 November 2020)

Hallo,





Heinileini schrieb:


> Was rechnet ihr da? Fällt das schon in den Bereich "persönliche Gewohnheiten"?
> Ich habe noch gar nicht verstanden, wie die Überleitung von den Jahreszeiten zu den Rollladen-Aktionen unter Berücksichtigung der persönlichen Gewohnheiten im einzelnen aussehen soll. :-(


ich bin der Meinung das war die ursprüngliche Frage. Etwas ähnliches hattest Du doch schon mit deinem Exceldiagramm gemacht. Es ging nur, glaube ich nicht direkt um den Sonnenuntergang, sondern wann die Rolläden herunterfahren sollen.

@Ratoncito
sag mal was Du noch verstehst, und wo Du dann Probleme hast

Gruß


----------



## Ratoncito (28 November 2020)

Hallo Thruser,

ja, nicht schlecht. So ähnlich hätte ich es auch gelöst - viel besser hätte ich es auch nicht hinbekommen. 

Spaß beiseite. das ist genial. Ich sitze immer noch mit weit aufgerissen Augen und heruntergefallener Kinnlade vor dem PC und starre ungläubig auf die wenigen Zeilen Code. 

Ich werde den Zauberkasten erst mal einbauen und verwenden. Anschließend noch meine restlichen Problemchen und Sonderwünsche lösen. 

Anschließend werde ich das Ding mal auseinanderbröseln und hoffe es ein wenig mehr zu verstehen.


Vielen lieben Dank!!!

Ich wünsche allen ein schönes Wochenende


----------



## Ratoncito (1 Dezember 2020)

Hallo,

nun habe ich das Ding ein wenig aufgebröselt und schon die erste Frage.


```
iTageSeit01 := FuDaysSinceJan01(DT_TO_DATE(dtZeit));
iTageJahr := FuNumDaysYear(DT_TO_DATE(dtZeit));

rX := SIN(INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1])/INT_TO_REAL(iTageJahr)*2.0*3.1415);

//y = (y2-y1)/(x2-x1)(x-x1)+y1
tdSchaltzeitMorgens := REAL_TO_TOD((TOD_TO_REAL(tdMorgensMin)-TOD_TO_REAL( tdMorgensMax))/INT_TO_REAL(1-(-1))*(rX-INT_TO_REAL(-1))+TOD_TO_REAL(tdMorgensMAX));

tdSchaltzeitAbends := REAL_TO_TOD((TOD_TO_REAL(tdAbendsMax)-TOD_TO_REAL(tdAbendsMin))/INT_TO_REAL(1-(-1))*(rX-INT_TO_REAL(-1))+TOD_TO_REAL(tdAbendsMin));

FuRolladenUnten := (DT_TO_TOD(dtZeit) <= tdSchaltzeitMorgens) OR (DT_TO_TOD(dtZeit) >= tdSchaltzeitAbends);
```

Außer in der Zeile

```
rX := SIN(INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1])/INT_TO_REAL(iTageJahr)*2.0*3.1415);
```

wird Array aDatum doch nirgendwo mehr aufgerufen, und immer nur der erste Wert (78 bzw 79) zum verschieben des Nulldurchgang der Sinuskurve verwendet.

Das teilweise Verschieben der Null- und Scheitelpunkte um 1 Tag spielt absolut keine Rolle. Daher könnte man doch die Zeile so ändern.

```
rX_WR := SIN(INT_TO_REAL(iTageSeit01-78)/INT_TO_REAL(iTageJahr)*2.0*3.1415);
```

Dann entfällt der Array und müsste nicht gepflegt werden.

Wenn das so richtig ist und nicht irgendwo von mir nicht erkannte Probleme verursacht werden, würde ich den Code abändern.


----------



## Thruser (1 Dezember 2020)

Hallo,

das ist richtig.

Frage ist, ob Du extra für ein Schaltjahr auch noch durch 366 Tage teilst oder ob Dir das auch egal ist und 365 Tage reichen. Dann könntest Du INT_TO_REAL(iTageJahr) auch noch durch 365.0 ersetzen. 

Gruß


----------



## Ratoncito (1 Dezember 2020)

Hallo,

vielen Dank für die Antwort.
INT_TO_REAL(iTageJahr) habe ich erkannt, lasse ich drin. Muss ja nicht gepflegt werden.

Nächstes Problem


```
//rX := SIN(INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1])/INT_TO_REAL(iTageJahr)*2.0*3.1415);
rx_W := SIN(INT_TO_REAL(iTageSeit01-78)/INT_TO_REAL(iTageJahr)*2.0*3.1415);
Wrx := SIN((W)/W1);
//W := INT_TO_REAL(iTageSeit01-aDatum[FuYear(DT_TO_DATE(dtZeit))][1]);
W := INT_TO_REAL(iTageSeit01-78);
W1 := INT_TO_REAL(iTageJahr)*2.0*3.1415;
```

Die ursprüngliche Berechnung von rX habe ich umbenannt in rX_W, und zum Testen in die Berechnung eingefügt, das scheint ok zu sein.

Die einzelnen Teile der Formel habe ich umbenannt und einzeln ausgeführt, die Werte sind meiner Meinung nach richtig, trotzdem liefert die Zeile mit der Berechnung Wrx ein anderes Ergebnis als rX_W.

Was ist da los?


----------



## Thruser (1 Dezember 2020)

Hallo,

nur INT_TO_REAL(iTageJahr) muß in den Nenner bei der Division.

Entweder so


```
W1 := INT_TO_REAL(iTageJahr)/(2.0*3.1415);
```

oder

```
W1 := 2.0*3.1415/INT_TO_REAL(iTageJahr);
Wrx := SIN((W)*W1);
```

Gruß


----------



## Ratoncito (2 Dezember 2020)

Hallo,

da war mein mathematisches Weltbild ein wenig durcheinander geraten.


```
W := INT_TO_REAL(iTageSeit01-78);
W1 := INT_TO_REAL(iTageJahr)

Wrx := SIN((W/W1)*2.0*3.1415);
```

Irgendwie habe ich die äußere Klammer immer wieder übersehen. Nun passt es wieder. Irgendwas ist wohl eingerostet, oder ich hatte ein ganz dickes Brett vor dem Kopf 
Den Rest lasse ich besser mal für eine Weile liegen, habe eh noch viele andere Dinge zu erledigen - muss da was entrosten.


----------



## Heinileini (3 Dezember 2020)

Ich melde mich hier mal ganz zaghaft wieder, obwohl ihr beide mich ganz schön "abgehängt" habt (besser gesagt, ich habe mich abhängen lassen, weil ich nicht so schnell bin). 

Ich habe angefangen, mal mit konkreten Zahlen (Datum+Uhrzeit) für diverse Solstitien und Äquinoktien einiger Jahre zu experimentieren.
Im Moment habe ich den Eindruck, dass man keinen Unterschied machen muss zwischen SchaltJahr und Nicht-SchaltJahr, vorausgesetzt man rechnet grundsätzlich mit 365.2422 Tagen pro Jahr und nimmt immer das Datum und die Uhrzeit des FrühlingsAnfangs des aktuellen Jahres als NullPunkt der SinusSchwingung. Und das scheint mir auch sehr naheliegend und logisch zu sein.
Ich verstehe nicht, warum eine Tabelle mit den Daten bessere Ergebnisse liefern sollte. 
Einmal im Jahr den Wert (Datum + Uhrzeit) für den FrühlingsAnfang des aktuellen Jahres eingeben und bis dahin (notfalls) einfach mit dem Wert des VorJahres (oder VorVorJahres, oder ...) weiterarbeiten finde ich gar nicht so schlimm. 

Gruss, Heinileini


----------



## Thruser (4 Dezember 2020)

Hallo,

es kommt immer darauf an, wie genau man das haben will  Bei den ersten Test mit Excel kam ich nie genau auf sin(x) = 1 bzw. -1

Das jeweilige Datum für Frühlings-, Sommer-, Herbst- und Winteranfang ist jedes Jahr etwas anders. Selbst wenn der Frühlingsanfang immer der 20. März wäre, ist das in einem Schaltjahr ein Tag mehr seit dem 1. Januar.

Nun kommt dazu das diese Tage sehr markante Termine im Kalender sind. Da könnte man den Anspruch haben, daß zu diesen Daten, zumindest Sommer- und Winteranfang, die Schaltpunkte auch genau zu den angegeben Zeiten sind, also z.B. 19:45 Uhr und 22:00 Uhr. Durch die ganzen kleine Ungenauigkeiten erreicht man diese Werte aber nicht. Nur der Frühlingsanfang stimmt, da der als Bezugspunkt gewählt wurde . Das könnte man jetzt etwas korrigieren wenn man das Jahr in vier Abschnitte teilt und mit Sinus, Cosinus, -Sinus und -Cosinus rechnet, wie weiter oben schon beschrieben. 
Als Umschaltpunkte sollte man die Mitte zwischen den vier Daten wählen.
Jetzt könnte man das natürlich alles dynamisch berechnen lassen, auch wann jeweils Frühlingsanfang, Sommeranfang, etc. sind, oder man berechnet das einmal für einen bestimmten Zeitraum vor und erstellt eine Tabelle in die man die ganzen Daten einträgt.

Meine Tabelle oben ist dahingehend auch noch nicht vollständig umgesetzt. Hatte es nur vorbereitet und dann erst einmal das notwendigste implementiert zur Demonstration.

Ich habe mir jetzt noch nicht die Mühe gemacht und mal nachgerechnet wie groß die Abweichungen sind. Die Anzahl der Tage hatte ich auch nur schnell durch Excel berechnet und nicht noch einmal verifiziert ob die Funktion dieselbe Anzahl an Tagen seit dem 1.1. berechnet.

Gruß


----------



## Ratoncito (4 Dezember 2020)

Hallo zusammen,

darf ich Euch ein wenig bremsen? Es geht nur darum, das Öffnen und Schließen einiger Rolläden in etwa an die Helligkeit bzw. die damit einhergehenden Gewohnheiten anzupassen. Ob sich da irgendetwas um ein paar Tage verschiebt oder nicht...

Wenn man bei der Berechnung berücksichtigt, ob das Jahr 365 oder 366 Tage hat, halte ich das schon für Luxus. Und ob die Scheitel- bzw Nullpunkte mit den meterologischen Ereignissen genau zusammenpasst ist auch egal. An den Tagen um die Scheitelpunkte liegt die Änderung der Schaltzeiten eh in einem Bereich den man nicht wirklich warnimmt.

Ich halte es für eine sehr komfortable und elegante Lösung die ich so nicht erwartet hatte. Ich muss mich nur noch mal mit dem zweiten Teil der Berechnung beschäftigen...

Noch mal vielen Dank für Eure Bemühungen.


----------



## Heinileini (4 Dezember 2020)

Thruser schrieb:


> Bei den ersten Test mit Excel kam ich nie genau auf sin(x) = 1 bzw. -1


Das ist aber kein Problem von Excel sondern etwas allgemeinerer Natur, wenn man mit solchen Zahlen arbeitet. Wenn man alles "zu Fuss" rechnen müsste, käme man sicherlich schneller auf die Idee, zu runden. 




Ratoncito schrieb:


> darf ich Euch ein wenig bremsen?


NEIN!!! 




So, jetzt darfst Du bremsen!
Habe durch Verschiebung des FrühlingsAnfangs um ca. 1,9 Tage in Richtung SommerAnfang erreicht, dass der Herbst ca. 1,9 Tage zu früh anfängt und der Sommer nur noch ca. einen halben Tag zu spät und der Winter nur noch ca. einen halben Tag zu früh. Ganz ohne Tabelle (die habe ich in Excel nur gebraucht, um Theorie und Praxis zu vergleichen), nicht wirklich genau aber recht ausgewogen, finde ich.
Für mich wäre das jetzt die Lösung, mit der ich leben könnte, ohne übertriebene Erwartungen an die Präzision der Äquinoktien-"Datümer".
Jetzt bremse ich auch. 

Gruss, Heinileini


----------



## ms4wago (31 Dezember 2020)

Hallo Zusammen,

hier mal kurz wie ich das ganze mache. Vielleicht ist es ja für den einen oder anderen eine Anregung:

Also ich fahre meine Raffstore und Rolladen ausschließlich nur noch über Sonnenwinkel. Damit habe ich Sommer wie Winter sehr gute Erfahrungen gemacht. So fahren bei mir zum Beispiel im Wohnbereich die Jalousien auf wenn: "Winkel Sonnenaufgang minus 3 Grad", und wieder zu wenn: "Winkel Sonnenuntergang minus 4,5 Grad" ist. Zwischendrin fahre ich je nach Sonnenhöhe und -Richtung unterschiedliche Zwischenpositionen an.

Mit der reinen Uhrzeit von Sonnenaufgang und Sonnenuntergang habe ich über das Jahr gesehen auch keine guten Erfahrungen gemacht

Gruß, Martin


----------



## Blockmove (31 Dezember 2020)

ms4wago schrieb:


> Hallo Zusammen,
> 
> hier mal kurz wie ich das ganze mache. Vielleicht ist es ja für den einen oder anderen eine Anregung:
> 
> ...



Sehr guter Ansatz, muss ich mal testen.
Kommt funktionell wahrscheinlich ziemlich aufs Gleiche raus wie die Funktion von Heini und Wolfgang


----------



## ms4wago (31 Dezember 2020)

Ergänzend muss ich vielleicht noch dazu sagen: Ich mache nur die Grundparametrierung über die Winkelangabe und diese rechne ich dann in eine Uhrzeit um. Somit habe ich zum Einem eine Übersicht wann was fährt und zum Anderen kann ich noch eingreifen und die Zeiten korrigieren (z.B.: im Sommer nicht vor 6 Uhr fahren oder nicht kurz hintereinander fahren). Zudem berücksichtige ich noch so Dinge wie Online-Wetter, Raumtemperatur, Außentemperatur, Lichtstatus im Raum, offene Fenster,...


----------



## Blockmove (31 Dezember 2020)

ms4wago schrieb:


> Ergänzend muss ich vielleicht noch dazu sagen: Ich mache nur die Grundparametrierung über die Winkelangabe und diese rechne ich dann in eine Uhrzeit um.



Kannst du bitte den Code zur Umrechnung Sonnenwinkel -> Uhrzeit online stellen.
Vielen Dank und Guten Rutsch

Gruß
Blockmove


----------



## ms4wago (2 Januar 2021)

Eine Formel für die Umrechnung von Sonnenwinkel zu Uhrzeit habe ich leider nicht gefunden. Deshalb gehe ich den Umweg über je eine Zuordnungsliste Winkel zu Zeit für die steigende Sonnenhöhe, die fallende Sonnenhöhe und die Richtung. Dies erstreckt sich bei mir allerdings über mehrere Programme und Funktion. 

Bei Bedarf und Gelegenheit kann ich ja mal versuchen dies halbwegs verständlich zusammen zu stellen


----------



## Blockmove (2 Januar 2021)

ms4wago schrieb:


> Eine Formel für die Umrechnung von Sonnenwinkel zu Uhrzeit habe ich leider nicht gefunden. Deshalb gehe ich den Umweg über je eine Zuordnungsliste Winkel zu Zeit für die steigende Sonnenhöhe, die fallende Sonnenhöhe und die Richtung. Dies erstreckt sich bei mir allerdings über mehrere Programme und Funktion.
> 
> Bei Bedarf und Gelegenheit kann ich ja mal versuchen dies halbwegs verständlich zusammen zu stellen



Mir ist eingefallen, dass es in der Oscat-Lib einen Baustein Sun_Pos gibt.




Werd ich mal bei Gelegenheit testen.


----------



## ms4wago (2 Januar 2021)

Mit der Funktion kannst du aber auch nicht von Winkel auf die Uhrzeit zurück rechnen. Dafür müsstest du schon die Formel in der Funktion umstellen


----------



## Blockmove (2 Januar 2021)

ms4wago schrieb:


> Mit der Funktion kannst du aber auch nicht von Winkel auf die Uhrzeit zurück rechnen. Dafür müsstest du schon die Formel in der Funktion umstellen



Ich hatte die Sonnenstandsberechnung mal vor vielen Jahren bei einem 841-Controller im Einsatz.
Da frass das Ding heftig Zykluszeit. Deshalb hab ich sie einmal täglich nachts um 1:30 aufgerufen und mir die entsprechenden Daten berechnet.
Mal schauen wie es jetzt auf dem PFC100 aussieht.
Evtl. geht da ein zyklischer Aufruf.
Die Uhrzeit brauch ich nicht. Es reicht ja Vergleich des Winkels.


----------



## Blockmove (2 Januar 2021)

So ich hab jetzt mal die Oscat.lib in e!Cockpit eingebunden und übersetzt und den FB SUN_POS aufgerufen.
Die Zykluszeit ändert sich kaum. Der Baustein kann ruhig zyklisch aufgerufen werden.
Die Daten stimmen mit den Ergebnissen von https://www.sonnenverlauf.de überein.

Ich geb jetzt mal den Ball an Heinrich und Wolfgang weiter.
Vielleicht könnt ihr mal checken in wie weit der Sonnenwinkel zu eurem Kurvenverlauf passt.
Soweit ich euren Ansatz verstanden habe, müßte es eigentlich schon in diese Richtung gehen.

Gruß
Blockmove


----------



## Ratoncito (3 Januar 2021)

Hallo,

ich wünsche Euch ein Frohes Neues Jahr.



Blockmove schrieb:


> Ich geb jetzt mal den Ball an Heinrich und Wolfgang weiter.
> Vielleicht könnt ihr mal checken in wie weit der Sonnenwinkel zu eurem Kurvenverlauf passt.



Den Ball gebe ich direkt weiter. Ich bin nur derjenige, der die   komfortable Lösung anwendet. Hauptsächlich geht es bei mir lediglich   darum, das Öffnen und Schließen der Rolladen und ein paar weitere   nützliche Funktionen an die vom Tageslicht abhängigen Lebensgewohnheiten  anzupassen. Dabei spielt es keine Rolle, ob die Scheitelpunkte den  längsten und kürzesten Tag genau treffen.

Genaugenommen ist der früheste Sonnenuntergang schon am 12. Dezember und  der späteste Sonnenaufgang so gegen den 30. Dezember und fällt nicht  mit dem kürzesten Tag am 21. Dezember zusammen. Wenn man das also ganz  penibel betrachtet müsste man für das Offnen und Schließen die Kurven  unterschiedlich verschieben. Heinrich hatte in einem Beitrag schon ein  paar Bemerkungen zu den Abweichungen zur Tageslänge gemacht.

Es ist also noch genügend Luft nach oben :smile:

Liebe Grüße und bleibt schön "negativ" :wink:


----------

