NI TestStand

Showing results for 
Search instead for 
Did you mean: 

how to negate a boolean value

Go to solution

Hello @ all,


I'm a little embarrassed, but I found no solution that works.


I receive a boolean value from a VI wich is "TRUE = Passed / no Error". I deliver this value to "Step.Result.PassFail".

Now I need the same value in another variable in TestStand, but I have to negate it, so "FALSE = Passed / no Error".


Is it possible that I can set both variables (one of them negated) easily with one VI output?

I tried several expressions with "! operator" at "post expression" and "module-tab --> value cell" of the VI call in TestStand , but no one works fine.



0 Kudos
Message 1 of 13

Use this in your step post expression :

Locals.x=!Step.Result.PassFail  ( where locals.x is a boolean value which you want to negate)

Hope this helps.



0 Kudos
Message 2 of 13

Hey Ravi,


thank sfor this approach, but it don`t work.


"RunState.SequenceFailed = !Step.Result.PassFail" in post expression always make my test "Passed".

I set "Step.Result.PassFail" with the boolean output of a VI and add your expression to post expression of this step.


I found a solution, but it isn't really nice... and needs a lot of work to change the existing tests.

I create an additional output to my VI where "PASS = False" instead of "PASS = True" and deliver it to "RunState.SequenceFailed".


Other idea?

0 Kudos
Message 3 of 13



the expression from Ravi is working well.
You wrote that you are in post expression.
The RunState.SequenceFailed is done AFTER Post expression, that means your stuff will be
override at all.  For more Information see TS-Manual Chapter 3 Table3-3

You could use a Statement-Step after your step
and use: RunState.SequenceFailed = !RunState.PreviousStep.Result.PassFail




NIWeek 2017: Standardized HIL Test Automation With TestStand
NIWeek 2016: Capturing ATE Requirements With Requirements Gateway

Feedback or kudos are welcome
0 Kudos
Message 4 of 13

Hi Juergen,


thanks a lot for your hint.

I don't understand to difference between using the post expression and the the way I described for my solution.

If I deliver the VI output directly to RunState.SequenceFailed it works well. Why will this doesn't get override?


Your suggestion with a statement-step is not really usefull for my tests because I have many (many many) calls which need to set SequenceFailed directly.




0 Kudos
Message 5 of 13



honestly, i have a hard time to understand the underlying issue.


The point is that the sequence state is set to fail by default if:

A step gets the Result.Status = "Failed" AND the step has the option set to "Step Failure Causes Sequence Failure" (which is the default setting in the RunOptions of the step!).


So in my understanding the default setting should already perform as you want. The only situation where this is not the case is if you are using "New Thread" or "New Execution" setting for the sequence call.

As the subsequence runs in parallel to the calling sequence, the sequence call step simply states "Done" as Result.Status. This is completly acceptable, as the call is done correctly but the step does NOT wait for the subsequence to return a result.....



CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 6 of 13

Hi Norbert,


sadly TestStand perfom NOT what I want in my case and I have to set RunState.SequenceFailure by myself. This is also the answer from NI-Servicedesk!


In the SequenceCall I use the default settings you describe (not a "new thread" or "new execution"). I only "ignore run-time errors" in station options, that's all I have changed.

If you run the Sequence in the attachment (exampleMaster) you can see that TestStand always make the VI-Call in "exampleSub" SubSequence "Passed" & "Failed" regardless if the boolean VI-Output is TRUE or FALSE.


The example show a simplified version of my test-logic. To start it run exampleMaster...



0 Kudos
Message 7 of 13



this is expected behavior.



Open the TestStand help and search for "Step Execution".

You will find a table showing several components of the step instance. Order of execution is top to bottom, some parts depending on settings (see remarks).

Please note the text below that table. It states the behavior of TestStand if an error occurs.


This behavior for the step creating the error is obviously independent of the setting "Ignore Runtime Errors".

As TestStand behaves like this at least as of version 3.0, it might be an unexpected behavior for you, but common to all TestStand-based test systems all around the world.

So NI will not likely change that behavior, even if it might look un-intuitive.




EDIT: As indicated by the mentioned text, you can use the PostStepRunTimeError-callback to revoke the error state. If you do this, you can proceed by setting the step result as you want. Please note that NI recommends you to handle errors as ERROR, not as "DISLIKED SITUATION".......


CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 8 of 13
Accepted by topic author DonBorste

Another thing to add... if you look into the table, you will see Action Number 27 sets the sequence failed state. As the step has an Error, not a Failed, the SequenceFailed state is not set to TRUE....



CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 9 of 13

I think this is the problem why TestStand always displays "Passed". I assumed that "ignore run-time errors" errors factual ignore them related to display the dialog box which asked "WHAT SHOULD I DO".

My tests have to run without user-interaction fully automatic (over night and weekends). Because of that, I have to deaktivate all dialogs from TestStand.

It's a little confusing, but now I got it.


When I don't deliver the VI error path to "Step.Result.Error" it works!


Thanks a lot!






0 Kudos
Message 10 of 13