handling while loop in subvi

[KSU Flyer]

I have a subvi that currently contains a while loop.  The while loop is responsible for sequentially illuminating a grouping of LEDs continuously.  This is the desirable function of this subvi.  (if there is a better way to do this without a while loop I'm all ears)

Secondly, I have a main vi using event structures.  To make things generic, lets say the user can select the LED grouping by selecting the 1st LED and the last LED to illuminate by editting two text fields in the main vi.  After the user enters the LED values in the two text fields, they click OK, the range is sent to the subvi, and the subvi starts controlling the sequential illumination of LEDs.  Got this working great!

Here is where I have the problem.  The user now wants to change the range of LEDs and send these to the subvi.  Nothing happens because the subvi is stuck in it's while loop.

whats the best way to handle this.?.it's kick'n my butt currently, and a simple example would be wonderful!

Thanks,

Mike

[Rob_Calhoun]

Use more than one thread. Have the event loop throw messages ("illuminate LEDs {2,3,4}") into a queue. In the reader (your subVi) you probably have some kind of wait, because otherwise your LEDs would be updating 100,000 times per second. Replace that wait with a Dequeue element with a timeout. LV will not use any CPU while waiting. If it times out, do whatever you were going to do before. If it doesn't time out, you have new commands from user.

The attached snippet is a sort of prototypical set-up. The top loop is the UI, the bottom loop does the work. When the top loop quits, it kills the queue, which will release the bottom loop with an error. We call this code pattern "scuttling the loop." Most of the time you want to wait with no timeout (-1) but if the loop should keep doing stuff with no new input, you will want one.

 

[RobCole]

There are a few ways of doing this. The quick and dirty way is to access all the controls on the front panel using references that are passed into the subVI and then property nodes in the subVI to read the controls and set the LEDs. This will work as long as you are reading the property nodes inside the while loop in the subVI.

All of the references are passed in to the subVI.

[tbob · Accepted solution]

Robert Cole beat me to the punch, but here is an example of his solution.

[KSU Flyer]

---

Robert Cole wrote:

There are a few ways of doing this. The quick and dirty way is to access all the controls on the front panel using references that are passed into the subVI and then property nodes in the subVI to read the controls and set the LEDs. This will work as long as you are reading the property nodes inside the while loop in the subVI.

All of the references are passed in to the subVI.

---

Help me out guys, I just moved the references in the subvi outside of the while loop and it still works

[RobCole]

The reference can be outside of the while loop. And, I would suggest that this is how it should be.

The property node to read the values of the controls has to be inside the while loop. Otherwise you are not reading the values every loop and changes to the front panel controls will not update the values seen in the subVI while loop.

I hope I didn't make that too confusing and that it helps.

     Rob

p.s. I can't read tbob's VIs since I do not have LabVIEW 2009 loaded.

Message Edited by Robert Cole on 04-26-2010 09:38 AM

[RavensFan]

---

KSU Flyer wrote:
Help me out guys, I just moved the references in the subvi outside of the while loop and it still works

---

Of course.  The references get defined at the time the subVI is called.  They never change.  Remember, the reference doesn't contain the current value of the control.  It is a "reference" to a control.  As long as you are reading the property node for value inside the while loop that the reference is connected to, you'll get the current value of the control that is in the other VI.