Startzeit an die Jahreszeiten anpassen

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

@Blöckmove

Dann pack das Ganze mal in ein VBA-Makro und probiers in Excel.
Zum Vergrößern anklicken....

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.
 
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.
Zum Vergrößern anklicken....
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 ...
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
... konnte ich nicht entnehmen, wie Du es eigentlich gemeint hast. Die FallUnterscheidung "wenn du im ersten Halbjahr bist u.s.w." liess schlimmeres vermuten.
 
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 :)
 
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?
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
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
 
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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
"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.
 
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
 
Larry Laffer schrieb:
Nein Heinrich ... einfach DATE nach INT konvertieren und dann die beiden DATE's voneinander subtrahieren - schon hast du Tage.
Zum Vergrößern anklicken....
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
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.
Zum Vergrößern anklicken....

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
 
Hallo,

Deutsch verspricht Wago schon lange.
Zum Vergrößern anklicken....

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
 
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
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?
Zum Vergrößern anklicken....
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.

Entwurf.jpg
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.
 
Zuletzt bearbeitet:

Similar threads

J
Solar-log 500 einlesen über MODBUS TCP
Antworten
2
Aufrufe
7K
Blockmove
B
Zurück
Oben