Geschachtelte if-Anweisungen

[enertegus]

Das hätte ich so erwartet, dass der !-Operator stärker bindet. Erstaunlich, dass das vier Jahre lang unentdeckt blieb. Schau ich mir mal an...

Hm, habe ich eben gecheckt. Das Verhalten ist aber so, wie es sein soll, d.h. der !-Operator bindet stärker als das "or".
Ich denke die Starverzögerung steht da noch auf AUS und blockiert die Logik (so ist es ja programmiert). Wenn Die auf AUS steht, ändert sich ja die "or" Verknüfpung nicht mehr und die if-Abfragen wird nicht mehr ausgeführt.

[saft6luck]

Das hätte ich so erwartet, dass der !-Operator stärker bindet. Erstaunlich, dass das vier Jahre lang unentdeckt blieb. Schau ich mir mal an...

Wenn man den Code etwas umstellt und das Validierungschema (change(X) && X==TRUE) drauf los lässt kommt doch folgende "falsche" Variante raus:

[highlight=epc]
Startverzoegerung= AUS
PoolChange= Startverzoegerung or change("Pool_Levelsensor1-9/7/6") or change("Pool_Levelsensor2-9/7/7") or change("Pool_Levelsensor3-9/7/8") or change("Pool_Levelsensor4-9/7/9")

if change( !PoolChange ) && ( !(PoolChange == EIN) ) then {
...
} endif;
[/highlight]

Da würde ich erwarten, dass der Event einen Zyklus später bearbeitet wird, oder?

-> erklärt das Verhalten nicht wirklich.

[Matthias]

Ich denke die Starverzögerung steht da noch auf AUS und blockiert die Logik (so ist es ja programmiert). Wenn Die auf AUS steht, ändert sich ja die "or" Verknüfpung nicht mehr und die if-Abfragen wird nicht mehr ausgeführt.

Das versteh ich nicht.
Wie kann es blockieren wenn es or-verknüpft ist? die Betonung liegt dabei auf "or" (da steht nicht "and").
Das letzte change() muss doch trotzdem zum Neuauswerten führen, selbst wenn sich das erste "or" nicht mehr ändert?!?

In dem Fall wäre ja

or change("Pool_Levelsensor4-9/7/9")

bei Änderung der GA kurzzeitig gleich 1 und müsste dazu führen dass das then ausgeführt wird? Oder nicht?

Aktuell habe ich den ersten Ausdruck eingeklammert und es funktioniert wie es soll. Ich kann gern noch mal zurückdrehen und testen was passiert wenn die Startverzögerung auf EIN gegangen ist

Grüße
Matthias

[saft6luck]

Ich denke die Starverzögerung steht da noch auf AUS und blockiert die Logik (so ist es ja programmiert). Wenn Die auf AUS steht, ändert sich ja die "or" Verknüfpung nicht mehr und die if-Abfragen wird nicht mehr ausgeführt.

D.h. der Wert des Ausdruckes wird 1 und der Rest nicht mehr bearbeitet, da mehr als 1 nicht möglich ist (optimiert)?

Dann dürften weitere changes ja keine Auswirkung mehr haben. Wieso geht es dann bei gesetzten Klammern?

[Matthias]

D.h. der Wert des Ausdruckes wird 1 und der Rest nicht mehr bearbeitet, da mehr als 1 nicht möglich ist (optimiert)?

-> man benötigt eine Hilfsvariable um den change zu erkennen?
=> Sehr sonderbar!

Ich habs eben mal getestet.
Code wie in meinem initialen Posting.

So lange die Variable Startverzögerung den Wert EIN hat funktioniert es.
(Wird ja negiert und der Ausdruck ist 0)
Sobald diese auf "AUS" geht klappt es nicht mehr (weil vorn als Ausdruck eine 1 steht und somit nix mehr ausgewertet werden muss, da sich trotz change nix mehr am Ausdruck ändert)

Hmmm. Irgendwie wird da scheinbar wirklich was "falsch optmiert".
Bzw. passt das halt nicht in die Logik eines konventionellen Programmierers. Klar, wenn man jetzt länger drüber nachdenkt und die Eigenheit kennt, könnte man sich drauf einstellen. Aber das ist trotzdem eine ganz schöne Stolperfalle die da exisitert...

Kann man nichts dagegen tun? Also bei Vorkommen von change() in if-Anweisungen auf die Optimierung verzichten?

Grüße
Matthias

[Matthias]

Wieso geht es dann bei gesetzten Klammern?

Hab mich selbst veralbert - habs direkt nach dem Systemstart getestet, als die Variable noch auf "EIN" stand.
Sonst hab ichs wohl immer erst danach getestet..

[saft6luck]

Hmmm. Irgendwie wird da scheinbar wirklich was "falsch optmiert".
Bzw. passt das halt nicht in die Logik eines konventionellen Programmierers. Klar, wenn man jetzt länger drüber nachdenkt und die Eigenheit kennt, könnte man sich drauf einstellen. Aber das ist trotzdem eine ganz schöne Stolperfalle die da exisitert...

Frage:
- Was willst du mit "Startverzoegerung" erreichen? Wenn der normale Status AUS ist, ist das überflüssig (or) und beeinflusst den Programmablauf sogar negativ.

Es sieht nach einer einmaligen Abarbeitung während des Inits aus, daher hat das wohl keiner gesehen.

[Matthias]

Frage:
- Was willst du mit "Startverzoegerung" erreichen? Wenn der normale Status AUS ist, ist das überflüssig (or) und beeinflusst den Programmablauf sogar negativ.

Wenn ich mich recht entsinne sollte damit erreicht werden, dass manche Sachen erst 90s nach Systemstart aktiv werden.
In dem Fall hier um auf die GAs in InitGA zu verzichten - aller 60s empfängt der EibPC den Status der GAs. Nach 90s hätte ich einen definierten Stand gehabt. Aber ich mein da gab es auch noch einen anderen Grund, aber der fällt mir grad nicht mehr ein.

Grüße
Matthias

[saft6luck]

Wenn ich mich recht entsinne sollte damit erreicht werden, dass manche Sachen erst 90s nach Systemstart aktiv werden.
In dem Fall hier um auf die GAs in InitGA zu verzichten - aller 60s empfängt der EibPC den Status der GAs. Nach 90s hätte ich einen definierten Stand gehabt.

Wenn es eine Einschaltverzögerung sein soll, sollte ein '&&' rein:

[highlight=epc]
if (!Startverzoegerung) && \\
(change("Pool_Levelsensor1-9/7/6") || change("Pool_Levelsensor2-9/7/7") || \\
change("Pool_Levelsensor3-9/7/8") || change("Pool_Levelsensor4-9/7/9") ) then
{
...
[/highlight]

[Matthias]

Wenn es eine Einschaltverzögerung sein soll, sollte ein '&&' rein:

Das stimmt. Keine Ahnung wie ich auf das "or" gekommen bin oder was ich damit noch bezwecken wollte. *grübel*

[klaus]

Das versteh ich nicht.
Wie kann es blockieren wenn es or-verknüpft ist? die Betonung liegt dabei auf "or" (da steht nicht "and").
Das letzte change() muss doch trotzdem zum Neuauswerten führen, selbst wenn sich das erste "or" nicht mehr ändert?!?

Dein Denkfehler ist, dass du wohl davon ausgehst, dass die IF-Abfrage neu ausgewertet wird (invalid wird), wenn sich einer der Parameter der IF-Abfrage ändert. Dem ist aber nur so, wenn zuvor alle Parameter auf FALSE waren. Wenn einer der Parameter (in deinem Fall die Startverzögerung) bereits TRUE ist und dann liefert noch ein weiterer Parameter TRUE wird, ändert sich das Ergebnis der IF-Abfrage nicht mehr, da diese bei einer OR-Verknüpfung ja bereits TRUE liefert.

[saft6luck]

[..]dass die IF-Abfrage neu ausgewertet wird (invalid wird), wenn sich einer der Parameter der IF-Abfrage ändert. Dem ist aber nur so, wenn zuvor alle Parameter auf FALSE waren. Wenn einer der Parameter (in deinem Fall die Startverzögerung) bereits TRUE ist und dann liefert noch ein weiterer Parameter TRUE wird, ändert sich das Ergebnis der IF-Abfrage nicht mehr, da diese bei einer OR-Verknüpfung ja bereits TRUE liefert.

NB: Einfache Definition "if-Abfragen": if (Ausdruck) then { Befehlsblock } [else {Befehlsblock} ] endif, wobei der else Zweig nicht betrachtet wird

Ich fasse mal zusammen und ergänze

1. Ausdrücke werden neu berechnet, wenn deren Teilausdrücke (Variablen, Funktionswerte) sich ändern.
2. In der Hauptebene wird der then-Zweig dann ausgeführt, wenn der Ausdruck der Abfragebedingung sich auf TRUE ändert.
3. In tieferen Ebenen wird der then-Zweig dann ausgeführt, wenn der Ausdruck der Abfragebedingung TRUE ist.