Wondering while loop

[Canofsteam]

My code below is acting funny.  My sub vi works and operates properly on its own but when I try to control it externally it wont respond.

As in it wont stop running when then switch in the main program is pressed.

also it wont output the 'elapsed time' terminal in the sub vi doesn't return the values to the main. (only when it is stopped) I would like it to do this continuously.

Any ideas on how to correct this?

Thanks

John

Main.vi

Logger sub vi

[muks]

Why are you using a "Not" inbetween the stop and the boolean? Connect it directly.

[Dennis_Knutson]

Your code is acting exactly the way that you have programmed it. You pass execution to the subVI. The subVI has a while loop that can only be stopped by clicking it's 'Stop' button. You don't make the subVI visible so the button cannot be clicked. There is no way to pass a value from the main to the subVI once the subVI starts.

Just get rid of the while loop in the subVI.

[johnsold]

John,

The reason you cannot stop the subVI by pressing the  Log button in the main VI is fundamental dataflow:  The value passed to the subVI is the value on the wire at its input terminal when it starts executing.  Any changes in that value which occur after the subVI starts are not available within the subVI.

To get the effect which you seem to want you need to have the logging subVI running in parallel with the portion of the code in the main VI which contains the (Main) Log button.  Then the data needs to be passed by some means other than wires: a queue or notifier is good.  Other ways are possible.  Some of them must be sued with great care to avoid introducing other problems such as race conditions.  Look at the Producer/Consumer design patterns which come with Lv for examples of how to pass commands from one loop to another.

muks,

It looks like he want to stop when Log is false and run while it is True.

Lynn 

[Canofsteam]

thanks guys

i only want this particualar logging vi to run when the user activates it.

i tried the notifier methods to solve it

but still it acts the sames. ...

at the minute im just want it to stop when the external stop is pressed. ill worry about the passing back the info after i get this going.

(I Have never used or looked at notifiers before)

[johnsold]

You still do not have parallel execution.  You need two while loops with no data dependency between them.  Have you looked at the Design patterns and examples?

Lynn 

[tbob]

If you want to stop the subvi with the Stop button from the main vi, you need to pass a reference of the main stop button to the subvi, and put code inside your subvi loop to read the value of the reference so that it can stop the loop and exit the subvi.  Then control is passed back to main and it will stop also.

[Andrew McL]

Hi CanofSteam,

Thank you for contacting National Instruments. As has been pointed out earlier, it is generally bad practice to place while loops in subVIs. They halt execution at a high level and can become very difficult to remove if you want to expand your program at a later date. 

I would strongly recommend looking at the design patterns that some of the other users have suggested. These are widely accepted as being the best methods for developing LabVIEW code. 

Having said that, I have written a simple example to show how to use a reference to stop an embedded while loop. As I said above, I would not recommend this but if its what you need, here's how to do it.

This is the code for the subVI. I have included a Boolean to show that this control will not stop the while loop. This is because once the subVI while loop is running, the data from the external control cannot pass through to it. Here we should use a reference to the control at a higher level. 

The funny looking control in the middle is a reference control. We pass whatever particular boolean we wish to read the value of. The next block is a property node where we are looking at the value on this particular Boolean. 

Please ignore the vi picture above, it is misleading. Instead, look at the attached VI mainvi. In here we can see this small box marked "boolean" with an arrow at the front. This is a reference. It is basically telling our subVI which particular boolean is going to be used to control our loop. Note that the Boolean itself is not wired to the subVI. 

If you would like more information about this, the LabVIEW Core II course goes into a lot of detail about this and is a great place to find out more about these types of controls and indicators. You can use the fundamentals that it teaches to make some very complicated and interesting applications. 

I hope this helps,

Many thanks,

[tbob]

---

Andrew McL wrote:

Hi CanofSteam,

Thank you for contacting National Instruments. As has been pointed out earlier, it is generally bad practice to place while loops in subVIs. They halt execution at a high level and can become very difficult to remove if you want to expand your program at a later date. 

---

I don't quite agree with the above statement about it being bad practice to put while loops in subvi's.  Although I do agree with the statement about them halting higher level execution.  There are scenarios where while loops in subvis are good practice and necessary.  Consider the case in the test and measurement world (Labview's specialty) where the programmer wants to take 100 measurements and then average them out.  If using DAQ, you could create a task and eliminate a loop.  But if using other instruments, a loop is necessary.  This subvi could be many levels down.  Halting execution at a higher level is a must!  You don't want to let a user push buttons causing power supplies to change or switches to change until all the measurements are done.  If loops in subvis is bad practice, then I'm a very bad LV programmer.

My point is this.  We are giving bad advice to newcomers with such statements as the one above and statements about local variables being bad.  Instead of giving general statements that are not always accurate, lets teach them proper use of locals, and proper use of loops dependent upon the situiation they are used in.  I can imagine a novice going far out of his way in order to avoid a legitimate use of a local, or adding lots of unnecessary coding to eliminate putting a loop in a subvi, just because we say its bad practice.