Geschachtelte if-Anweisungen

[Matthias]

Hallo zusammen,

im Handbuch steht ja zum Thema "Verschachteln von if-Anweisungen" auf Seite 111:

Bei Abfragebedingung==EIN invalidiert die If-Funktion jede Anweisung im then-Zweig.

Hier mein Beispel was nicht tut was es soll:

[highlight=epc]

PoolLevelString=$intit$;

if !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") then
{
PoolLevelString=$$;
if "Pool_Levelsensor1-9/7/6" == EIN then PoolLevelString = $1$ endif;
PoolLevelString=PoolLevelString+$,$;
if "Pool_Levelsensor2-9/7/7" == EIN then PoolLevelString = PoolLevelString + $2$ endif;
PoolLevelString=PoolLevelString+$,$;
if "Pool_Levelsensor3-9/7/8" == EIN then PoolLevelString = PoolLevelString + $3$ endif;
PoolLevelString=PoolLevelString+$,$;
if "Pool_Levelsensor4-9/7/9" == EIN then PoolLevelString = PoolLevelString + $4$ endif;
} endif;
[/highlight]

Je nach Status der Gruppenadressen sollten also zum Schluß ein String wie: 1,2,3,4 oder 1,2,, oder auch 1,,,4 usw. rauskommen.

Was heisst "invalidiert jede Anweisung im then Zweig"? Ich würde es so verstehen dass jedes if im then Zweig neu ausgewertet wird.

Konnte ich aber nicht beobachten. Ich habe gestern zum Testen die GA "Pool_Levelsensor4-9/7/9" per ETS mit dem Wert "1" auf den Bus geschrieben.
Im Debugger hatte die GA auch den Wert "EIN".
Jedoch im String der Variable PoolLevelString fehlte die "4".

Hab ich da was falsch verstanden?

Grüße
Matthias

[rennsemmel]

Hallo Bin selbst Einsteiger also meine Antwort bitte mit Vorsicht genießen. Ich verstehe das so:

Invalidierung bedeutet m.e., dass die Variable "PoolLevelString" auf invalid gesetzt wird und daher im nächsten Zyklus neu berechnet/zugewiesen wird.

Auf Seite 52 im Handbuch ist ein Beispiel was zu deinem Problem passen könnte. Und es steht geschrieben: "Wenn auf die Gruppenadresse "Freigabeschalter-1/0/1" ein EIN gesendet wurde, nachdem ein AUS vorlag, wird die innere if-Anweisung genau einmal ausgewertet."

[enertegus]

Was heisst "invalidiert jede Anweisung im then Zweig"? Ich würde es so verstehen dass jedes if im then Zweig neu ausgewertet wird.

Genau so ist das.

Konnte ich aber nicht beobachten. Ich habe gestern zum Testen die GA "Pool_Levelsensor4-9/7/9" per ETS mit dem Wert "1" auf den Bus geschrieben.
Im Debugger hatte die GA auch den Wert "EIN".

Kann es sein, dass eine der anderen GAs auf AUS wechselt, und du dann den leeren Status bekommst?
Reduziere einfach mal den Code auf nur eine GA und das Ergebnis solllte so sein, wie Du es wünscht und auch richtig verstanden hast.

[saft6luck]

Jedoch im String der Variable PoolLevelString fehlte die "4".

Was passiert denn bei den anderen GAs? Kommen da die Werte 1-3, auch in Kombinationen?

Hab ich da was falsch verstanden?

Glaub nicht.

[Matthias]

Was passiert denn bei den anderen GAs? Kommen da die Werte 1-3, auch in Kombinationen?

Habs eben noch mal überprüft. Die GAs haben die Werte:

"Pool_Levelsensor1-9/7/6" = EIN
"Pool_Levelsensor2-9/7/7" = AUS
"Pool_Levelsensor3-9/7/8" = EIN
"Pool_Levelsensor4-9/7/9" = AUS

Jedoch sieht der String aktuell so aus: 1,,3,4

Es kommt mir so vor als wenn nicht alle ifs invalide werden. Also als wenn nur die ersten 3 (?) ifs neu getriggert werden aber das 4. if nicht neu ausgewertet wird..

Irgendwas funktioniert da nicht wie es sollte.



Grüße
Matthias

[saft6luck]

Es kommt mir so vor als wenn nicht alle ifs invalide werden. Also als wenn nur die ersten 3 (?) ifs neu getriggert werden aber das 4. if nicht neu ausgewertet wird..

Dann stell doch mal testweise um. Falls immer der Letzte ein Problem hat, kannst du ja mal ein weiteres if hinzufügen

[rennsemmel]

Da meine erste Antwort nicht richtig gewesen ist habe ich mir erlaubt Deinen Code zu testen. GA wurden natürlich angepasst.

Ich habe weiterhin die Variable !Startverzögerung aus der If Anweisung raus gelassen (spielt die in Deinem beobachten Verhalten vieleicht eine Rolle?) und die geschweifte Klammer eine Zeile nach oben gesetzt, da mein compiler gemeckert hat.

Mein Ergebnis: Funktioniert, wie es in der Theorie sollte.

Schritt 1: Lese PoolLevelString = init
Schritt 2: Schreibe "Pool_Levelsensor1-9/7/6" = EIN => PoolLevelString = 1,,,
Schritt 3: Schreibe "Pool_Levelsensor3-9/7/8" = EIN => PoolLevelString = 1,,3,
Schritt 4: Schreibe "Pool_Levelsensor4-9/7/9" = EIN => PoolLevelString = 1,,3,4
Schritt 5: Schreibe "Pool_Levelsensor4-9/7/9" = AUS=> PoolLevelString = 1,,3,

[Matthias]

Hallo zusammen,

erst noch mal ein Dank an rennsemmel für seine Bemühungen!

Ich bin einen kleinen Schritt weiter.
Habe heute angefangen mit dem Syslog Makro zu "spielen" und lasse mir am Ende des if-Zweiges eine Syslog Meldung schicken.
Was ich festestellen musste: das "or change("Pool_Levelsensor4-9/7/9")" im äußeren if wird nicht getriggert! Ich habe die GA per ETS definitv geändert (von AUS auf EIN und umgedreht) - jedoch bekomme ich keine Syslog Meldung..

Kann man change() nur 1x im Programm für eine GA nutzen? Ich habe noch weiter oben im Quelltext in einem anderen Zusammenhang ein "if change("Pool_Levelsensor4-9/7/9")" stehen... ?

Grüße
Matthias

[saft6luck]

Kann man change() nur 1x im Programm für eine GA nutzen? Ich habe noch weiter oben im Quelltext in einem anderen Zusammenhang ein "if change("Pool_Levelsensor4-9/7/9")" stehen... ?

Nein. An solch einem Problem bin ich aber auch schon verzweifelt.

Wie schon geschrieben solltest du einfach mal umstellen, um das Problem einzugrenzen.

Ansonsten würde ich eine Hilfsvariable verwenden:

[highlight=epc]
PoolLevelString=$intit$;
PoolChange= 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 (!Startverzoegerung) || PoolChange then {
PoolLevelString=$$;
if "Pool_Levelsensor1-9/7/6" == EIN then PoolLevelString = $1$ endif;
PoolLevelString=PoolLevelString+$,$;
if "Pool_Levelsensor2-9/7/7" == EIN then PoolLevelString = PoolLevelString + $2$ endif;
PoolLevelString=PoolLevelString+$,$;
if "Pool_Levelsensor3-9/7/8" == EIN then PoolLevelString = PoolLevelString + $3$ endif;
PoolLevelString=PoolLevelString+$,$;
if "Pool_Levelsensor4-9/7/9" == EIN then PoolLevelString = PoolLevelString + $4$ endif;
} endif;
[/highlight]

[Matthias]

Wie schon geschrieben solltest du einfach mal umstellen, um das Problem einzugrenzen.

Hey Marc,

hatte ich ja auch schon gemacht, jedoch nur _innerhalb_ der if-Anweisung die Reihenfolge der geschachtelten ifs vertauscht.
Dass jedoch die Äußere das Problem bereitet hätte ich so nicht erwartet...

Das ist schon tragisch wenn man sich nicht auf die korrekte Interpretation des Codes verlassen kann...

Ich werde heute mal deine Variante mit der Variable ausprobieren..

Grüße
Matthias

[Matthias]

Fehler gefunden!

Hallo zusammen,

Fehler ist gefunden.

Was der Programmierer geschrieben hat:

[highlight=epc]
if !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") then
{
[/highlight]

Was der Programmierer gemeint hat:

[highlight=epc]
if (!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") then
{
[/highlight]

Was der Compiler wohl verstanden hat:

[highlight=epc]
if !( \\
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") \\
) then
{
[/highlight]

Mein Fazit:
Das "nicht" sollte nur bis zur ersten logischen Verknüpfung gelten. Oder?

Grüße
Matthias

[Uwe!]

Das "nicht" sollte nur bis zur ersten logischen Verknüpfung gelten. Oder?

Würde ich jedenfalls auch so erwarten!

So oder so ist es immer ein guter Tipp sich den Output vom Compliler anzuschauen!

[enertegus]

Das "nicht" sollte nur bis zur ersten logischen Verknüpfung gelten. Oder?

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...

[Matthias]

So oder so ist es immer ein guter Tipp sich den Output vom Compliler anzuschauen!

Ähm, das oben war jetzt meine fiktive Darstellung der Compiler-Interpretation um das Problem zu verdeutlichen.
Das findest du so nirgends..

[Uwe!]

achso!

ich dacht, dass der Output vom Compiler das schon so (falsch) umgestellt hatte. Dann hab cih Dich falsch verstanden. Meinen Tipp kann ich Dir aber trotzdem nur ans Herz legen, auch wenn er in diesem Fall nichts geholfen hätte.