Q about timing loops in both VI and subVI

[camerond]

Well, this is probably something just about anyone here can answer immediately, but it seems to be a black hole in my LabVIEW knowledge, and has been bothering me for a while.

I certainly appreciate that if you have a VI with a loop without any timing information, it will loop as fast as possible, hogging the CPU's resources, leading to Bad Things (TM). However, if you have a VI with a loop containing a subVI with a second loop which does have timing information (say, polling a fast serial line @ 1 ms), do you also need a timer in the outer VI, or not? I almost always err on the side of caution and put one in, but if it's redundant, I'd naturally rather leave it out.

Thanks in advance,

Cameron

[JÞB · Accepted solution]

An interesting question that deserves an answer with a simple example.  So, I whipped one up to demonstrate

I Did take a minimallist approach!  Assume that this snippette represents a simple sub-vi with a loop that contains some timing and, a caller that is not sure if it is a greedy loop or not.  (A bajillion other examples could exist but this one is hopefully very clear) 

A simple run and inspection of the timing chart will prove that the delay in the outer loop will have no effect on the for loop performance as long as it delay is less than or equal to the total time the for loop takes. Go ahead and enable and disable the case containing the while loop delay.  You will not see a difference in the Timing chart.  In other words- the sub-vi provides all the "Pacing" that the module requires and the while loop is not greedy.

HOWEVER:  Now that you proved the while loop is not greedy set "numeric"=0 and try again 

[William1225]

Hi, Jeff,

What do you mean "GREEDY" in a while loop?

Does it mean the ability to rob the resource of the SubVI?

The sequence of "as long as the outer while time is less than or equal to the total time of the for loop takes" confused me a little, I thought no matter the timer of the while loop is, the timer of the for loop will work as expected.

Thanks for your sharing.

[crossrulz]

Jeff put together an excellent example.  It also shows how a FOR loop behaves if you tell it to run 0 times (there are some fun bugs associated with that if you are not careful).

My 2 cents.  If you fully understand what is happening inside that loop all the way down the VI hierarchy and you know there is stuff in there that will control timing (DAQmx, VISA, Dequeue, waits), there is no need for the wait in the upper loop.  But if you are unsure at all, err on the side of caution and throw in a small delay.  Though, all you need is a 0ms delay to alleviate the greedy loop syndrome.

[crossrulz]

---

William1225 wrote:

What do you mean "GREEDY" in a while loop?

Does it mean the ability to rob the resource of the SubVI?

The sequence of "as long as the outer while time is less than or equal to the total time of the for loop takes" confused me a little, I thought no matter the timer of the while loop is, the timer of the for loop will work as expected.

---

A greedy loop is a loop that will hog the CPU, not letting other resources work.  Since the subVI is inside of the loop, it won't be impacted.  So if there is timing/waiting inside of the subVI, then the main VI's loop will not be greedy.

The wait in the outer loop will run in parallel with the "subVI" since there is no data dependency.  So as long as the outter loop's wait is no longer than the time it takes the "subVI" to run, you will see no timing difference for the entire main loop.  If that wait is larger than the time that it takes for the "subVI" to run, then the main loop will start to loop at a slower rate.

[camerond]

Thanks, Jeff,

That was clearer than anything I'd come up with to test it.

"Now that you proved the while loop is not greedy set "numeric"=0 and try again "

Well, when the numeric is "0", nothing (apparently) happens, since the charts are not updated from the for loop. But (here comes the "apparently") the program is running at warp speed, which you can see if you wire an indicator to the while loop index.

Cameron

[camerond]

---

@crossrulz wrote:

---

 The wait in the outer loop will run in parallel with the "subVI" since there is no data dependency.  So as long as the outter loop's wait is no longer than the time it takes the "subVI" to run, you will see no timing difference for the entire main loop.  If that wait is larger than the time that it takes for the "subVI" to run, then the main loop will start to loop at a slower rate.

---

Ahh! ( "Light Bul-lb!" * ) I hadn't thought about the wait timers running in parallel because of data dependency! Now it's all making sense, because I put it into a loop for a particular purpose, I just (incorrectly) thought of the wait timer as a "special case," when it really isn't. Thank you.

* Gru in "Despicable Me"

Cameron

[JÞB]

---

@camerond wrote:

---

@crossrulz wrote:

---

 The wait in the outer loop will run in parallel with the "subVI" since there is no data dependency.  So as long as the outter loop's wait is no longer than the time it takes the "subVI" to run, you will see no timing difference for the entire main loop.  If that wait is larger than the time that it takes for the "subVI" to run, then the main loop will start to loop at a slower rate.

---

Ahh! ( "Light Bul-lb!" * ) I hadn't thought about the wait timers running in parallel because of data dependency! Now it's all making sense, because I put it into a loop for a particular purpose, I just (incorrectly) thought of the wait timer as a "special case," when it really isn't. Thank you.

* Gru in "Despicable Me"

Cameron

---

Congrats!  Now, go do that execise again with task manager up and look at CPU usage.  You will find "Bad Things" TM and a bit more on "Greedy Loops".  Then, Re-Read Crossrulz's posts.

Thanks for the explaination Tim.