LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Nested while loops

Solved!
Go to solution

Attached is a very simple VI with two nested while loops and two buttons on the front panel.

 

Button 1, when pressed exits the inner loop.  Button 2 when pressed exits the outer loop and the program should stop.  I put in a probe at the outer loop terminator and sure enough a TRUE goes to the terminator when I press button 2 but the program does not stop.  Apparently, all inner loops must terminate before the outer loop can terminate.

 

Obviously, somebody at NI made this design decision a long time ago, but the justification puzzles me.  If a loop terminator gets a TRUE it should terminate, no?

 

While the example is trivial, the problem it illustrates is a real one for me.  I want to provide a panic stop button is a large and complicated program and I don't see how I can do that with things as they are.

0 Kudos
Message 1 of 6
(9,013 Views)
Solution
Accepted by David_Lieberman

What you are seeing is the result of the dataflow paradigm used by LV.  As you stated, all code inside the loop must complete/terminate before the outer loop will stop.

 

Providing a single Stop button to stop everything in a large program can be a complex task. The key issue is that EVERY loop, function, subVI, case structure, event structure, sequence structure, and so on... must stop to stop the loop.  If you have something like a file write or a read from GPIB instrument which takes 100s of milliseconds or seconds to complete, the stop process will take at least that long, assuming the time-consuming node was running when the stop was issued.

 

Another point: You should place the Button 2 terminal inside the the event case which responds to the button. That assures that the button will be read so the mechanical action works as expected.  With it outside the loop it will only be read once.

 

A Notifier can be used to "spread the word" when it is time to stop.  The timeout will keep it from waiting forever and will also allow other code parallel to the inner while loop to execute during the waits.

 

Lynn

Message 2 of 6
(9,005 Views)

You need to understand a few basic things here: Your event structure and while loop execute in parallel, and the outer loop cannot iterate until both have completed. However, it cannot go to the next iteration unless the event structure has fired once, which only occurs if you want to stop the outer loop. (Since you did not wire a timeout value, the timeout will never happen). Since the outer loop stops unconditionally after the first iteration here, it has no purpose here.


@David_Lieberman wrote:

Obviously, somebody at NI made this design decision a long time ago, but the justification puzzles me.  If a loop terminator gets a TRUE it should terminate, no?


You'll soon learn that dataflow as implemented is very powerful, beautiful, and functional. You just need to get the hang of it.:D


@David_Lieberman wrote:

While the example is trivial, the problem it illustrates is a real one for me.  I want to provide a panic stop button is a large and complicated program and I don't see how I can do that with things as they are.


Obviously, all your desired functionality is easily possible if correctly implemented. A big mistake is to have an event structure in parallel to blocking code in the same loop. As long as the inner loop spins, the event structure can only handle the first event it sees.

You need to decouple the user interface interaction from the processing, which is most easily done with two parallel loops, one to handle events and one to do your processing. Have a look at producer consumer arcitecture or similar.

 

 

 

 

Message 3 of 6
(9,001 Views)

Thanks for your help.  Indeed, a notifier looks like a good solution although in my case the implementation will be difficult.

0 Kudos
Message 4 of 6
(8,954 Views)

Thanks for your comments.

 

Yes, the dataflow model is powerful except where it isn't.  In which case it is a pain in the ass.

 

Ironically, I think that NI understands this;  Sequence structures violate the dataflow model but are essential for some appllications. 

 

What I would really like to see is a Stop-Execution-and-Return-to-Caller function which would solve my problem and lots of others.

 

David

0 Kudos
Message 5 of 6
(8,951 Views)

David_Lieberman wrote:

Yes, the dataflow model is powerful except where it isn't.  In which case it is a pain in the ass.


If it is a pain in the @$$, you are using it wrong. 😮 One of the big advantage of dataflow is parallelism and levering the power of data dependency will automatically protect your critical sections. I have a fancy LabVIEW program that runs 17x faster on my fancy 16 core Xeon compared to the same code forced to execute sequentially.

 


David_Lieberman wrote:

Ironically, I think that NI understands this;  Sequence structures violate the dataflow model but are essential for some appllications. 


Sequence structures don't violate dataflow, they are part of dataflow to enforce execution order if it cannot be enforced by other means (e.g. data dependency). A direct data dependency is highly preferred and almost always possible. Of course if all data dependency is destroyed by overuse of local variable and value property nodes, it will force overuse of sequence structures. Two wrongs don't make a right.


David_Lieberman wrote:

What I would really like to see is a Stop-Execution-and-Return-to-Caller function which would solve my problem and lots of others.


You are looking at this very simplistically. A program that interacts with the outside world (high voltage, high speed, etc.) cannot simply drop what it is doing and return to idle, it typically needs to follow a defined shutdown procedure. Similarly, if you are doing a lenghty 2D FFT, how is it supposed to quit unless you write the FFT routines yourself and constantly poll for a shutdown signal. It probably will be orders of magnitude slower, so what's the point?

Again, shutdown will be slow if your code is trapped in a lengthy sequence structure, but that's not good programming! If you would replace the sequence with a proper state machine, it can react much quicker because there are many more exit points and at the same time it can  invoke defined shutdown states that may be needed.

 

 

 

 

Message 6 of 6
(8,939 Views)