clear boolean indicator after ERROR

[danielleoh]

 Hi All,

Have a fairly Newb question here, I'm afraid.  The image below shows two examples of the issue; the Stop button and the Error Detected LED.  The problem is this; when the application is stopped, the current state of either of these indicators is locked in, and when the program resumes it resumes in this state.  So if someone stops the code by hitting the Stop button (pretty common, naturally enough) they can't restart because the Stop button's state is 'True'.  If they stop the program while the Error Detected LED is lit then it restarts but there's a flashing red indicator on the screen and everyone thinks there is a problem; which is where I found things this morning.  (note that I am using a fairly draconian method of clearing all errors each iteration of this loop, because I thought it would avoid this problem; it does keep the program running when there's a hardware error, which is typically due to power outage, and when the power comes up the program just starts up again as if nothing had happened.  This is unrelated to my question, but I figured someone would ask; it does explain why the program will restart but the indicator isn't cleared, I think).

So the question is how I can clear boolean controls and indicators automagically when the program stops, rather than having to teach each user how to go in and restore the default state, before restarting.  Any ideas?

Thanks,

Danielle

[Mark_Yedinak]

Right click on the controls and select "Create->Invoke Node->Reinitialize to Default". You can place this either before, after or before and after your main program loop.

[James_W · Accepted solution]

1) Right click on the indicator/control that you want to initialise to a default value and create an invoke node - type "Reinitialise to Default" from the drop don menu. Put all of these on the left of your block diagram and wire the error clusters through to ensure the run before the loop. Don't forget to wire the last error clutter on to the start of the loop even if you don't use it in the loop.

Some other tips: 

2) Wire your error out from the DAQ assistant into a shift register and feed it around the loop (don't use the feed back node) - clear the before running the DAQ Assistant if you want.

3) Change the False constant to a control (otherwise you can't stop the loop) - you should never use the Red button at the top.

4) Add a time delay into the loop if you don't already have one to stop the loop runing stupidly fast, grabbing all of your processor power and killing your PC.

[danielleoh]

Hi Mark,

This reveals my lack of understanding about how VI program flow works.  Since the entire program is wrapped in a While loop, I placed this node outside of the loop.  But is there any way to control whether it is, in terms of execution, 'before' or 'after' the iterations of the loop?  It's working something like every other time now, so I know I am still doing something wrong...

Thanks,

Danielle

[danielleoh]

Thanks, James.  It took me a minute, but I get it, now. 

~Danielle

[James_W]

Try this (replace the sequence strcucture with your DAQ assistant express VI) - LV 8.6

(Slow connection - trying to help with a VI as well)

Message Edited by James W on 04-07-2010 04:16 PM

[Mark_Yedinak]

The most basic description of data flow is that if a node (can be a case structure, while loop, subVI, or other blocks of code) has a wire coming into it, it has a data dependency on the node before it that has this wire as an output. Nodes will execute as soon as all of their inputs are satisified. An input is satisifed as soon as the data associated with it is available. Therefore, if subVI A has an output wired to the input of subVI B you are guaranteed that A will always execute before B. If you have subVI A and subVI B on a block diagram with no wires between them (and for the most simple explanation) no wires as inputs you have no guarantee which subVI will execute first. Either one is free to execute since all os its inputs are satisified (they have no inputs). LabVIEW's scheduler will decide which order they wil execute. Theoretically speaking the order could change every execution.

As suggested, if you wire the error out from the invoke nodes to the while loop they will execute before the loop. If you wired an error out from the loop to the error in of the invoke node it would execute after the loop.

[danielleoh]

Thanks for that clear explanation, Mark!  I've mostly worked in 'C' of various flavors, so I often feel as if I'm looking for the start and stop points of things in LV.  This helps enormously.

Danielle

[James_W]

Kudos for a great description of data flow.