Understand what the xml-interpreter is doing with the code.
- (L:Var1,bool) loads the value of L:Var1 into the stack
- 1 loads "1" into the stack
- == compares the last two entries of the stack and return 0 if they're different, 1 (or something else) if they're the same. So after the first line, either "0" or something else (probably "1") is in the stack. Let's assume it's "1" and continue...
- (L:Var2,bool) loads the value of L:Var2 into the stack
- 1 loads "1" into the stack
- == compares - as before. So after the == your stack will consists of the "1" from before and then either a "0" or something else for the second comparison. Let's assume this value is "1" as well.
- after the or, the stack is cleared and there's either a "0" or "1" in the stack, based on the or-evaluation.
- continue for the var3....
Soooo assume that Var1, Var2 and Var3 are all "0". After this block:
Code:
(L:Var1,bool) 1 ==
(L:Var2,bool) 1 == or
(L:Var3,bool) 1 == or
There will be a "0" in the stack. The next line of code is:
Code:
if{ (A:ELECTRICAL MAIN BUS VOLTAGE,Volts) 3.0 > }
And since there's a "0" in the stack, the if{ - statement is not performed, but the stack is emptied!
Next, you have:
Code:
if{ 1 (>L:Var4,Bool) } els{ 0 (>L:Var4,Bool) }
but in our example, the if{ statement has nothing in the stack and so it can go either way. It's an undefined state.
And just on a side-node: understand that only the "FALSE" state of a boolean expression is properly defined. So it's always safer to check for "0" or "not 0" when evaluating boolean expressions.
The solution to this is what you proposed, and extended to make it more robust:
Code:
(L:Var1,bool) 0 !=
(L:Var2,bool) 0 != or
(L:Var3,bool) 0 != or
(A:ELECTRICAL MAIN BUS VOLTAGE,Volts) 3.0 > and
if{ 1 (>L:Var4,Bool) }
els{ 0 (>L:Var4,Bool) }
In this case, there are no undefined states, since the first four lines will leave either a "0" or something else (most likely a "1") in the stack. Hence, the if/els will evaluate properly. I hope this helps!