LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

sub vi in while loop does not stop while loop

I have a while loop with a sub vi inside.  The sub vi gets a output stable boolean input with a iteration input.  Once all the conditions are met, the sub vi puts out a true to the while loop stop button. 

I have several problems, which I don't understand because I have done this before and it worked.

1.  the iteration input into the sub vi does not increment correctly when observed with the highlight execution - it only increments every third or fourth iteration.

2.  Although my output stable variable is high, the sub vi does not recognize it all the time.  Using highlight execution on the sub vi shows the input to the sub vi only high every fifth iteration or so.

3.  Once the sub vi outputs a true to the stop button, the while loop does not stop.  I have confirmed the input to the stop button goes high.




metzler CLAD
0 Kudos
Message 1 of 12
(5,801 Views)
Unless you also include the subVI, we have no way to even try to reproduce the problem.  😞
Message 2 of 12
(5,785 Views)

metzler wrote:

I have a while loop with a sub vi inside.  The sub vi gets a output stable boolean input with a iteration input.  Once all the conditions are met, the sub vi puts out a true to the while loop stop button. 

I have several problems, which I don't understand because I have done this before and it worked.

1.  the iteration input into the sub vi does not increment correctly when observed with the highlight execution - it only increments every third or fourth iteration.

2.  Although my output stable variable is high, the sub vi does not recognize it all the time.  Using highlight execution on the sub vi shows the input to the sub vi only high every fifth iteration or so.

3.  Once the sub vi outputs a true to the stop button, the while loop does not stop.  I have confirmed the input to the stop button goes high.


OK- time to go back to basics.

 

Why are you using locals? the terminals are available  you only read the indicator and write to the control???? something is amiss with your understanding of code practice.

 

Iteration terminals do work.  period.  they update every iteration.

 

put a delay in loops.  Heck even wiring a 0 to a wait for next ms multiple releases the current thread!

 

Include sub-vis in your posts-  despite the gross coding errors in the vi you did post- the problem must be in the logic of the su-vi you did not post.


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 12
(5,784 Views)

Here is the sub-vi.  I am using local variables because I have parallel while loops running, and the output stable coding is in a loop that runs continuously, regardless if this loop is running or not.

 

This while loop is located inside of a case structure. 

 

Jeff, I apologize for the 'gross coding errors in the vi' I did post and I am sorry I wasted your time. 




metzler CLAD
0 Kudos
Message 4 of 12
(5,759 Views)

metzler wrote:

I have a while loop with a sub vi inside.  The sub vi gets a output stable boolean input with a iteration input.  Once all the conditions are met, the sub vi puts out a true to the while loop stop button. 

I have several problems, which I don't understand because I have done this before and it worked.

1.  the iteration input into the sub vi does not increment correctly when observed with the highlight execution - it only increments every third or fourth iteration.

I don't see this behavior at all. 

 

2.  Although my output stable variable is high, the sub vi does not recognize it all the time.  Using highlight execution on the sub vi shows the input to the sub vi only high every fifth iteration or so.

When is your output stable variable ever high (or true)?  If it starts out as false in your main VI, it is always false.  Nothing in the subVI ever changes it.  Nothing in your main VI ever changes it.

 

3.  Once the sub vi outputs a true to the stop button, the while loop does not stop.  I have confirmed the input to the stop button goes high.

The subVI does write out a true to the Stop button of your main VI.  But that Stop (or "Abort" as you called it) doesn't have any effect on the while loop in the main VI.  The only thing that stops the main VI is having a True come out of the connector "output is stable" in the upper right corner of the subVI.  That is never set to True because in the subVI, the iterations must be greater than the Min (Okay that happens) AND the Stable Input must be True.  Since the Stable Input gets its value from the Output Stable local variable in the main VI and it is never set to True (see #2), your VI will never end


You haven't seen to grasp how data flows within LabVIEW yet.  It is almost like you are expecting similarly named controls in different VI's to be somehow magically connected event though you have set a connection or a path for data to flow from one to another.

 

I would recommend you learn more about LabVIEW from here. How to Learn LV

 

PS.  Before saving your VI, please clean up your diagram and front panel a bit.  You have the front panel located in a way that your controls are off screen.  Likewise in you block diagram, the terminals for the controls are located far away from the main body of your block diagram.

Message Edited by Ravens Fan on 08-15-2009 10:22 PM
0 Kudos
Message 5 of 12
(5,735 Views)

okay, let me start from the beginnning.  I have just updated from LV 8.6.1 to LV 2009.  My vi consists of three while loops, one which runs continuously, and two others that are within event structures.  (The second while loop contains the daq coding, reading and writing to the compact DAQ.  The third (part of which I am having a problem) contains the timing sequences to perform the tests, which includes writing to excel, changing setpoints, changing loads, verifying correct outputs, cycling the product for different lengths of time, ect.)  I have not posted the entire code.

 

The while loop that I am having a problem with is located inside an event structure, and inside of a case structure.  Again, this is a design that I have used in previous vis and did not have a problem. 

 

The while loop that runs continuously contains the code to determine if the output is stable, and sets the output stable variable true.  I have confirmed it works correctly. 

 

When using highlight execution, I can observe the output stable variable go true, but it only changes to true inside of the sub vi every third or fourth iteration.

 

In order to help troubleshoot this problem, I had removed the variable and inserted a switch.  I then observed the same problem - inside the sub vi, it only changes to true every third or fourth iteration, then back to false.

 

Also, when observing the iteration terminal, the iteration increments inside the while loop, but does not increment inside the sub vi (stable output hp404 5050.vi).

 

The wiring to the stop button is intended to stop that while loop, not the main vi.

 

I wonder if the problem is the event structure - once triggered, will the event structure finish.  Or maybe I am having a timing problem with the loops?

 

I can post more of the circuitry, but I don't think this would solve the problem - just distract from it.

 




metzler CLAD
0 Kudos
Message 6 of 12
(5,706 Views)

metzler wrote:

My vi consists of three while loops, one which runs continuously, and two others that are within event structures. 

 

The while loop that I am having a problem with is located inside an event structure, and inside of a case structure.  Again, this is a design that I have used in previous vis and did not have a problem. 


There's part of your problem. You should not have while loops inside of event structures. That's backwards.

 


 

I wonder if the problem is the event structure - once triggered, will the event structure finish.  Or maybe I am having a timing problem with the loops?


The event structure will not finish until the code inside the event finishes. If you have a loop that doesn't end, then the event structure cannot complete. That's why you should not have while loops inside of event structure. This is bad programming. You said it worked before - you got lucky.

 

 


 

I can post more of the circuitry, but I don't think this would solve the problem - just distract from it.


In LabVIEW code is called a block diagram, not circuitry. Smiley Wink

0 Kudos
Message 7 of 12
(5,687 Views)

smercurio_fc wrote: 

The event structure will not finish until the code inside the event finishes. If you have a loop that doesn't end, then the event structure cannot complete. That's why you should not have while loops inside of event structure. This is bad programming. You said it worked before - you got lucky.

The while loop in the event structure does have two different ways it will end the while loop, if the conditions are met for output stable, or the iteration limit is reached,  so ending the while loop is not an issue.  The purpose for this sub vi is that it repeats until the conditions are met.  I originally started out using time delays, but the amount of time until the output is stable varies, depending on the response of the PID loop, the product performance, and the load it is under.  This part of the state diagram is called out probably six or seven different times during the automatic test, and the delay until the output is stable is different for each instance.

 

I put this in an event structure so this portion of the block diagram was not running continuously, using up system resouces.  I had tried master/slave architecture, and that did not accomplish what I needed. 




metzler CLAD
0 Kudos
Message 8 of 12
(5,672 Views)

This is a simplified example of what I am doing. 

When you run this vi and press 'toggle', the local variable output goes true, and lights the indicator. 

When you press 'start event structure', the event structure starts, which includes a while loop.  This loop will either run until the local variable is high and over the required number of iterations then stop the while loop (as indicated by the loop iteration stopping), or will stop the main vi when the iteration count gets to 20. 

Press and hold 'toggle' after 'start event structure'.  The while loop stops, and event structure is finished. 

This is basically the same thing I am doing.  When observing with the highlight execution, I can see the iteration take place but the iteration does not increment. 

 




metzler CLAD
0 Kudos
Message 9 of 12
(5,646 Views)

metzler wrote:

This is a simplified example of what I am doing. 

When you run this vi and press 'toggle', the local variable output goes true, and lights the indicator. 

When you press 'start event structure', the event structure starts, which includes a while loop.  This loop will either run until the local variable is high and over the required number of iterations then stop the while loop (as indicated by the loop iteration stopping), or will stop the main vi when the iteration count gets to 20. 

Press and hold 'toggle' after 'start event structure'.  The while loop stops, and event structure is finished. 

There is no need to hold toggle.  It's behavior is switch when pressed.  Holding it doesn't do anything special. 

 

This is basically the same thing I am doing.  When observing with the highlight execution, I can see the iteration take place but the iteration does not increment. 

Whether highlight execution is on or off, the iteration indicator increments.  I don't see the behavior you describe where you say it does not increment.  If the loop iterates, there is a value of i written to the iteration indicator on every iteration of the inner while loop.  It is basic dataflow and I don't see anyway it can't happen.

 


PS, in your upper while loop, there is no need to wire a value to the local variable terminal and to a local variable of the local variable terminal.  It is redundant.

0 Kudos
Message 10 of 12
(5,635 Views)