Value Signaling Property Causing VI To Run Infinitely When Running Multiple Times In TestStand

[testdesign]

Hi everyone, I suspect my issue is with using the Value Signaling Property for a boolean when communicating between 2 while loops.

My VI: I have a VI that has 2 while loops.

Loop 1: While Loop With Event Structure in it

Loop 2: While Loop with value signaling property (ComError) used to tell Loop 1 when a communication error has happened and to tell Loop 1 to shutdown.

This VI is a generically re-written copy of my VI just for trying to figure out the issue purposes.

Issue: The idea of this VI is that the operator would hit the done button after filling out some booleans for data input (Loop1) and the other Loop 2 would be checking for communication (data) from a device to say it fully powered up.  If Loop 2 failed communication it would set a ComError value signaling property node to trigger an event called "ComError" to shut down Loop 1.

I need to run this VI twice in my teststand sequence.  Upon the first run when there is a ComError the VI completes, but upon the second run the DONE button is depressed and the code never runs.  The VI is caught in an infinite loop.

I have attached my VI and TestStand sequence.  Here is how to simulate my issue.

1. Run the TestStand Sequence

2. Upon the first run of the VI called sequence step UI Run 1, first select the "DONE" button and then select the "Trigger Error" stop button.

3. Upon the second run of the VI called sequence ste UI Run 2, select the "DONE" button.

You will notice after you hit the DONE button the DONE button stays depressed and the VI is in an infinite loop.  It's like the ComError event structure already triggered (from the Value Signaling property in Loop 2) and stopped Loop 1 so when hitting the DONE buttton since Loop 1 is already stopped the Done button won't do anything. 

Thanks for everyone's help.  I really appreciate it!  Have a great weekend!

[Bob_Schor]

Wow, that is complicated logic to follow.  Often when I look at code and I ask myself "What does this really do?", I realize I'm asking the wrong question.  A better question is "What does the User really want to do?  Why are there two Loop controls?  Is the program supposed to be run twice, or is there a sequence ("Do this test until I say "Stop", then do that test until I say "Stop")?

Sometimes, if you clearly state the conditions and sequence(s) that you want, a logical design suggests itself.  I suspect four controls (really, it is three controls and an Indicator masquerading as a Control) are too many, and leading to (my) confusion.

Without worrying about how to code what you want, can you state what you want to accomplish?  Do you run the program once (and two two tests in sequence) or twice (and do a different test each time)?  Do the tests stop themselves or do you stop them manually?  Do you need two Stop buttons?  [There's a Good Programming Principle that, sadly, I only recently began to understand and occasionally use -- "Write the Documentation First!"].

Bob Schor

[testdesign]

Bob, the VI attached is not my actual VI since it is more complex.  I created a simpler VI which I attached which points out the same issue I see in my real VI.  For company proprietary reasons, I can't disclose the real VI.

The real VI has the following purpose:

The VI runs two tasks at the same time.

Task 1 (While Loop 1): Read data the user inputs by boolean buttons (test failures/failure sheet) on the front panel.  It also looks for the ComError event if triggered from Loop 2 via a Value Signaling Property Node.

Task 2 (While Loop 2): Looks for  two things:

1. Looks for a communication byte upon the device under test power up.  When the DUT is fully powered up the communication line will send a certain byte to the VI to validate the communication link and when the byte is received or the timeout is hit my VI will shut down this loop.

2. VISA Communication Error in Error Cluster - If there is an Error with the communication link and the VI cannot access the communication link over VISA the error cluster will become TRUE.  I unbundle the error cluster STATUS and if it is TRUE my VI flags this and appropriately shuts down Task 1 by using a Value Signaling Property.  This is a crucial ERROR and filling out the boolean sheet in task 1 is irrelevant.

The VI runs twice in my sequence, right at the beginning of testing and right after the last test is run in the sequence.  Since the DUT power up takes some time the idea is that the operator could fill out the failure sheet while the DUT was powering up and Loop 2 was looking for the communication byte.  This would run these two tasks in parallel would save some crucial test time.

First Run Of VI: Check for the failure sheet filled out (boolean buttons input) and the Done button was hit by the user.  In this case, both Loop 1 and Loop 2 are active.  Loop 1 checks for the user to fill out the failure sheet and the DONE button (DONE event).  If the DUT communication link has ERRORED (Error Cluster = TRUE) and the user still has not finished filling out the sheet and hitting the Done button, I want the VI to shut down completely since the communication failure is a CRUCIAL test failure.  The way I do this is by triggering the communication link error in Loop 2 by a "Value Signaling Property Node called "ComError" which signals the event ComError in Loop 1 to trigger and shutdown Loop 1.

Second Run Of VI: Loop 1 is active and Loop 2 is shutdown.  Loop 2 is specifically for DUT power up communication and that was already done in the first run of the VI.  Loop 1 is active to wait for the user to fill out any new boolean sheet failure comments that occured during testing from the first run of this VI.  The VI exits by the DONE button being selected by the user when they are done filling out the boolean sheet.

For the simplified VI I attached, here is how my real VI integrates with it:

Done button (control): This button is the DONE button the user will hit after filling out the boolean sheet of failures.

ComError button (control): The COM Error is NOT included in the user interface front panel.  It is a event control that is triggered in Loop 1 code by the error cluster in Loop 2 from the DUT VISA communication link failing.  I show it in this simplified VI to get the point through but the operator never sees this control on the front panel.  This control will get set to TRUE in Loop 1 when there has been a communication link failure (VISA Read ERROR causing the Error Cluster Status to = TRUE).  When Loop 2 Error Cluster Status = TRUE, it uses the ComError "Value Signaling Property" to trigger the ComError event in Loop 1 to shutdown Loop 1 only if the operator has not shut down Loop 1 with the Done button..

Stop Loop 2 button (control): This button simulates that the DUT power up communication byte was received before the timeout.  Thie control is NOT seen by the OPERATOR either.

The only button that is actually seen by the operator is the DONE button.

I hope this makes things clearer.  Please run the sequence file with the VI and run the steps in the first post to see the issue.

Thanks so much!

[Bob_Schor]

---

@testdesign wrote:

Bob, the VI attached is not my actual VI since it is more complex.  I created a simpler VI which I attached which points out the same issue I see in my real VI.  For company proprietary reasons, I can't disclose the real VI.

The real VI has the following purpose:

The VI runs two tasks at the same time.

Task 1 (While Loop 1): Read data the user inputs by boolean buttons (test failures/failure sheet) on the front panel.  It also looks for the ComError event if triggered from Loop 2 via a Value Signaling Property Node.

Task 2 (While Loop 2): Looks for  two things:

1. Looks for a communication byte upon the device under test power up.  When the DUT is fully powered up the communication line will send a certain byte to the VI to validate the communication link and when the byte is received or the timeout is hit my VI will shut down this loop.

2. VISA Communication Error in Error Cluster - If there is an Error with the communication link and the VI cannot access the communication link over VISA the error cluster will become TRUE.  I unbundle the error cluster STATUS and if it is TRUE my VI flags this and appropriately shuts down Task 1 by using a Value Signaling Property.  This is a crucial ERROR and filling out the boolean sheet in task 1 is irrelevant.

The VI runs twice in my sequence, right at the beginning of testing and right after the last test is run in the sequence.  Since the DUT power up takes some time the idea is that the operator could fill out the failure sheet while the DUT was powering up and Loop 2 was looking for the communication byte.  This would run these two tasks in parallel would save some crucial test time.

First Run Of VI: Check for the failure sheet filled out (boolean buttons input) and the Done button was hit by the user.  In this case, both Loop 1 and Loop 2 are active.  Loop 1 checks for the user to fill out the failure sheet and the DONE button (DONE event).  If the DUT communication link has ERRORED (Error Cluster = TRUE) and the user still has not finished filling out the sheet and hitting the Done button, I want the VI to shut down completely since the communication failure is a CRUCIAL test failure.  The way I do this is by triggering the communication link error in Loop 2 by a "Value Signaling Property Node called "ComError" which signals the event ComError in Loop 1 to trigger and shutdown Loop 1.

Second Run Of VI: Loop 1 is active and Loop 2 is shutdown.  Loop 2 is specifically for DUT power up communication and that was already done in the first run of the VI.  Loop 1 is active to wait for the user to fill out any new boolean sheet failure comments that occured during testing from the first run of this VI.  The VI exits by the DONE button being selected by the user when they are done filling out the boolean sheet.

For the simplified VI I attached, here is how my real VI integrates with it:

Done button (control): This button is the DONE button the user will hit after filling out the boolean sheet of failures.

ComError button (control): The COM Error is NOT included in the user interface front panel.  It is a event control that is triggered in Loop 1 code by the error cluster in Loop 2 from the DUT VISA communication link failing.  I show it in this simplified VI to get the point through but the operator never sees this control on the front panel.  This control will get set to TRUE in Loop 1 when there has been a communication link failure (VISA Read ERROR causing the Error Cluster Status to = TRUE).  When Loop 2 Error Cluster Status = TRUE, it uses the ComError "Value Signaling Property" to trigger the ComError event in Loop 1 to shutdown Loop 1 only if the operator has not shut down Loop 1 with the Done button..

Stop Loop 2 button (control): This button simulates that the DUT power up communication byte was received before the timeout.  Thie control is NOT seen by the OPERATOR either.

The only button that is actually seen by the operator is the DONE button.

I hope this makes things clearer.  Please run the sequence file with the VI and run the steps in the first post to see the issue.

Thanks so much!

---

It sounds to me that you need independent control of your two loops.  Something that comes to mind is a pair of Queued State Machines, which would allow each loop to control itself (including stopping itself by setting its next state to "Stop"), while at the same time accepting control from "outside" (such as the Stop state being put on its Queue).  You could also have an Event loop for the Front Panel Controls, which would most likely enqueue a Start for the loop the Control was supposed to start.  If Loop 1 wanted to stop Loop 2, it would put Stop on Loop 2's Queue.

When Loop 1 or Loop 2 exited, it would release its Queue.  When both Loops stop, both their Queues would be released, but there would still be the Event Loop running.  You can stop it, in turn, using its TimeOut case, running every 100 msec (or slower) -- simply have it do a Queue Status on both the Loop1 and Loop2 Queues and if both return Errors (because both queues are destroyed), stop the Event Loop.

I'm not sure where there's a good example of a Queued State Machine -- if you need one and can't find an example on the Web, come back here ...

Bob Schor

[testdesign]

Thanks Bob for the advice.  I will give that a try.  I was also going to try to get rid of the Value Signaling Property nodes all together.  Instead of handling errors from loop 2 as events in loop 1 I was going to handle them as booleans for loop 1 to handle outside of the event structure.