I have a subVI that is running in an infinite loop. Which subVI is it?

[InfiniteNothing]

I have a top level VI that's running and it calls many subVIs. One of those subVIs is stuck in an infinite loop and won't let the top level subVI finish running. Is there and easy way to figure out which subVI is the culprit. The best I can figure is to go into the VI hierarchy and open every front panel until I find the one that has the "running" run arrow. 

[Chazzzmd]

Greetings,

Even with many sub-vi's using the highlight execution in conjunction with breakpoints should identify your infinity loop pretty easy. If your code is "all over the place" it may take a little bit more time, but if it's done correctly should work like a charm. Just make sure to install breakpoints accordingly (after loops) so you're not waiting for any loops to execute hundreds of times in highlight mode. And if you never reach your breakpoint, well, you know it's in the loop prior to the breakpoint, and can debug from there.You should be able to systematically break it down in no time.

Good Luck.

Chazzmd

[Darin.K]

You are not alone:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Need-a-way-to-visualize-VI-call-chain-hierarchy/idi-p/...

[RavensFan]

What version of LabVIEW are you using?

In highlight execution mode, the running subVI will show up with a green arrow over it.  However, there are a couple of versions (LV 2009, 2010 I believe) that had a bug where that wasn't occurring unless you had turned on highlight execution before starting the VI.  That bug was fixed in LV 2011, and older versions (8.6 and earlier) worked fine.

[InfiniteNothing]

I've kudosed that idea though I can see limitations like hung primatives, reentrant VIs, etc. A VI task manager (another idea out there on the exchange) might be useful.

The green arrow is a good method but I feel like sometimes I've been flipping through case structures forever sometimes and that I never find the stalled VI. I don't think it works on hung primatives either.

Sometimes you can use highligh execution and you can search for the gray unexecuted code and trace backwards.

Maybe a pause button that drills down to the ultimate culprit node and highlights it could work