reset all boolean indicators to default when restarting run

[horatioinc]

This is probably an easy one for an experienced user, but I am not that...

I have developed a project which tests a circuit board functionality.  The front panel contains about 30 pass/fail boolean indicators.  At the beginning of each run, I would like to have all indicators reset to default (off) values before any new testing begins.  How can this be done?  As a second similar question, I have a group of boolean selection controls also on the front panel to select individual tests to be run.  How can I blanket show them all as selected when my "run all" option button is selected?

FYI, my individual tests are run within a CASE structure.

Thanks for any help

[GerdW]

Hi horatioinc,

you could use locals or properety nodes to reset the booleans. You can also use property nodes to disable buttons temporarily...

Maybe you should also think about redesigning the UI, like using an array of booleans instead of 30 individual indicators...

[Oswald_Branford]

Hi Horatioinc!

Like GerdW said, you can use invoke nodes, local variables or property nodes. The following document shows a way to do it:

 http://digital.ni.com/public.nsf/allkb/1924FD467F21A5808625751D006DC57D?OpenDocument

The example uses a method for all the controls on the front panel. There is an specific method for one control in particular: right click the control and select Create >> Invoke Node. Then select the Reinitialize to Default Method. The downside of this is that you would need as many as 30 invoke nodes. You can try to create an array and then pass each one of them to a for loop that includes the method. There are many ways to do it!

For the button, there is also a property node that allows you to disable the button, right click the button on the  block diagram and select Create >> Property Node. Select Disabled and then right click it and select change all to write. The input is an integer with the following variations: 0 is disabled, 1 is disabled and grayed out and 2 is enabled. Just call the property node when you need it and you can control this on run time.

Hope this helps!!

Have a great day!!

[JÞB]

Be Careful-  If any of your booleans has a latching mechanical action you will get an error trying to write the Value property.

Here is a way around your problem that uses the re-initialize all method.  Boolean 4 and both loop terminators are latching booleans the rest are switchers. 

1 word of caution-  Because I used the "this vi's path" constant you have to save the vi first (so it has a path)

(grumble- that took me a couple minute to find out myself  

[elset191]

Jeff,

Is there any reason for your outer for loop?  it's going to stop when the inner for loop stops because of the stop bool, or not at all.  Why not just have the invoke node outside the small loop?  Or am I missing something?

Message Edited by elset191 on 01-21-2010 03:04 PM

[PaulG.]

I do exactly what you are doing and I always use a tree as an indicator. Tree controls are not very easy to work with at first but worth the effort to learn how to use them. They make excellent test information indicators and scale very well.

[JÞB]

---

elset191 wrote:

Jeff,

Is there any reason for your outer for loop?  it's going to stop when the inner for loop stops because of the stop bool, or not at all.  Why not just have the invoke node outside the small loop?  Or am I missing something?

Message Edited by elset191 on 01-21-2010 03:04 PM

---

the inner loop is there to provide a controlled delay (so the buttons can be pressed by the user) simulating a test process is occuring.  When either Exit itteration or Stop is pressed the test loop ends and the reset process takes its action (runs Method>Reinit all to default)the outer loop allows the code to be run again and again until stop is pressed.

[elset191]

Oh okay.  I was thinking it was just an example to show off the invoke node.  It's a bit more complex than that.  I got ya now.

[JÞB]

---

elset191 wrote:
Oh okay.  I was thinking it was just an example to show off the invoke node.  It's a bit more complex than that.  I got ya now.

---

Additionally, I you really nuke it out, the value of the stop button MUST be known when the inner loop exits.

There is  no other data flow controlling the order of "Set Stop False" (inside the method) and read value of "Stop".  In fact I wound up pressing CLT. while I worked up the example (I originally left "Stop" outside the inner loop).  Race condition AND infinite loop. 

Just shows that you need to be careful when playing in the deep end of LabVIEW ( multiple accessors to set a value)