Boolean expression fails sporadically

[pwaszkewitz]

In a TestStand 4.1 sequence we have a local container with some configuration flags which are set from a configuration file; currently these flags are all true.

We observe that the following if-condition sometimes fails, i.e. the if-block is not executed although everything should be True:

True && Locals.ConfigContainer.SomeCondition

Disregarding for the moment the sensibility of the "True &&", is this possibly a known issue that such an expression can fail sporadically? What could be a possible reason?

The sequence is running concurrently in two separate executions; as far as I know, Locals should not affect each other between executions or threads.

Regards

Peter

[~jiggawax~]

Without knowing more about your sequence file it is hard to give you advice on this issue.

If you break right at that step can you look at the variable (SomeCondition) to see what value it is?  Is it set to false?  If not then there is no reason you should see that statement go to false.

Hope this helps,

[JoLe]

Hi Peter,

I can confirm that Locals should not affect each other between executions or threads.

At the moment I just have a presumption what could be a possible reason for the behaviour of your IF command.

In most programming languages the definition of TRUE and FALSE is like that:

0 = FALSE, every other value = TRUE

In your IF command you do a logic AND operation between a TRUE constant and the value of a flag. In the case that the value of a flag is coded in one bit (bit = 0 -> FALSE, bit = 1 -> TRUE) the AND operation will work fine.

In Teststand, the value of one flag is coded hexadecimal in half-bytes, hence not bit-wise.

For example, the value of your flag could be 0x4 which corresponds TRUE. But the AND operation would work like that:

1000     (0x4, value of flag, corresponds TRUE)

0001     (TRUE constant)

-------     &&

0000     = FALSE

That could be a possible reason for the behaviour of your IF command.

The IF command checks the value of the given argument on TRUE or FALSE. Value = TRUE, the code of the IF block is executed. Value = FALSE, the code of the IF block is skipped.

Regarding to that it is not neccessary to perform a AND operation in the argument of the IF command. To evaluate the values of the flags, you should write the IF command like that:

IF(Locals.ConfigContainer.SomeCondition)

{...code...}

I hope you can fix your problem with this suggestion.

Best regards,

JoLe

National Instruments

Applications Engineering

www.ni.com/support

[JoLe]

Correction:

0x4 = 100 in binary, so the example has to be like that:

0100     (0x4, value of flag, corresponds TRUE)

0001     (TRUE constant)

-------     &&

0000     = FALSE

Best regards,

JoLe

National Instruments

Applications Engineering

www.ni.com/support

[~jiggawax~]

JoLe I would have to disagree with you sorry....

You have described the bitwise operator which is a simple &.

In the case of the && operator both operands are evaluated to a true/false value before they are operated upon.

So it would look more like this:

0100 => TRUE

0001 => TRUE

--------------------- &&

             TRUE

If you want to prove this you can put Str(0x4 && TRUE) into a message popup and see what comes out. 

So my theory is that if the Local variable is not 0 or False then the evaluation should always be TRUE.

Regards,

[pwaszkewitz]

Thanks a lot for all your input.

I was away from the project for some time and will now introduce a monitoring of the values hoping to find out more about the circumstances when it fails.

I will let you know if I find something.

Best regards

Peter

[dug9000]

There is a bug that was fixed in TestStand 2010 related to boolean expressions that begin with a constant (e.g. True && <something>, False || <something>). In the case of 'True && <something>' what can happen is that at edit time, if the expression evaluates to false, TestStand incorrectly thinks the expressions contains only constants and caches that resulting 'false' value. Then at runtime, it uses the cached 'false' value rather than re-evaluating the expression. To avoid the bug either don't put 'True &&' in the expression (it doesn't really do anything anyway, so not sure why you are doing this), or switch the order around (e.g. <something> && True).

Sorry for any inconvenience. Let me know if you have any additional questions about this issue.

-Doug

[pwaszkewitz]

Hello Doug,

thank you very much for the in-depth reply.

The "True &&" is actually an editing convenience, since, as you rightly point out, it does not really have an effect.

All the other flags are read from configuration files, sometimes deeply nested, and in order to make it simple to disable a complete if-block temporarily, we changed the "True &&" into a "False &&".

We will remove this construct and see if the problem disappears (it will take a while to be sure, the error sometimes occurred only after days of operation).

Thanks again

Peter