Startzeit an die Jahreszeiten anpassen

Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
... 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. ;)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.


Code:
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;
 
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
Code:
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.
Code:
TagGrad = (TageSeit01-80) / 366 * 360
in Bogenmaß dann
Code:
TagBogen = (TageSeit01-80) / 366 * 360 * Pi / 180 = (TageSeit01-80) / 366 * 2 * Pi

Der Sinus wäre dann
Code:
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:
Code:
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)
Code:
RolladenUnten = (aktuelleZeit <= ZeitMorgens) ODER (aktuelleZeit >= ZeitAbends) //Abends schon mit berücksichtigt
oder
Code:
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
Code:
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.
 
WOW! Dagegen komme ich natürlich nicht an! :oops:

Ich versuche es erstmal so ...
Code:
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! :ROFLMAO:

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?
Code:
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:
Code:
Frühling := aktuellerTag >= FrühlingsAnfang AND aktuellerTag < SommerAnfang ;

Gruss, Heinileini
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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. :oops:
Code:
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

versuch mal
Code:
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
Code:
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);

2020-11-27 11_00_44-Window.jpg

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

@Heinilein

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

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

Code:
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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
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
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ß
 
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?
 
Zuletzt bearbeitet:
Hallo,
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?

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ß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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! :ROFLMAO:
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?
 
Zuletzt bearbeitet:
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. :-(
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da müsste dann ja noch die Verschiebung von 80 Tagen eingebaut werden?

Die sind schon drin, und zwar hier
Code:
aDatum[FuYear(DT_TO_DATE(dtZeit))][1]
bzw. hier
Code:
    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
2020-11-27 13_52_48-Window.png
Gruß
 
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...
 
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...
 
Zurück
Oben