LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I tell what SubVI my program is stuck on when it is in a loop 4 SubVIs deep?

I've been programming in LabVIEW for several years and I've run into a persistent debugging issue which I hope there is a solution for. 

I have a program, for example, that has 50 SubVis, with some of them up to 4 deep inside their own SubVIs. When I run the top level VI and after performing a series of steps for 10 minutes, the program seems to be stuck and is not giving an error or completing. Somewhere in one of the SubVIs it is stuck in a loop. Is there a quick way to figure out exactly where it is stuck?

My current process of debugging is to stop the program, place a breakpoint before where it seems to get stuck, rerun to the breakpoint, and then highlight execution and step through it.

 

Is there some setting or menu item that can show me, while the program is running, that the current position of the data flow is in "Measure14.vi" for example?

 

I know I can pause the program and click highlight execution and hunt around inside SubVIs until I can find the one being executed, but this can take a long time for a complicated program. Is there a better way?

0 Kudos
Message 1 of 5
(2,876 Views)

When you have highlight execution turned on in a VI, if the execution is in a subVI, that subVI will have a green arrow on it.

Message 2 of 5
(2,845 Views)

I might be tempted to write a VI that, when called, figures out the name of the VI that called it (i.e. the VI in which it was "embedded"), then opens a "Trace" file, goes to its end, writes a line identifying its "parent", and closes the Trace.  Now, if the main routine "gets stuck", you can look at the Trace file and see the sequence of VIs, including the last one called (and possibly where it is "stuck").

 

There may also be things you can do with Profiling, but it's sometimes more fun to "roll your own".  Plus if you write your own debugging VI, you can save it and use it again when needed ...

 

Bob Schor

0 Kudos
Message 3 of 5
(2,835 Views)

That's pretty rough.  I know that sometimes it's hard to avoid, but I think you should try not to have VIs with that level of complexity.  It's been a while since I thought of it, but I think LabVIEW good coding practices recommends no more than something like three levels of complexity?  My VIs rarely have more than two levels of complexity (yet they aren't spaghetti code, either, because they are broken up into logical subVI units).  So the "top level" VI contains a bunch of subVIs that have single, or very few, functions that don't go very deep at all.  Maybe one more level.  It's much easier to debug that way.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 5
(2,797 Views)

Raven Fan posted;

 

"

When you have highlight execution turned on in a VI, if the execution is in a subVI, that subVI will have a green arrow on it.

"

That is the approach that I use as well but it works best if you have you top-level VI structured on the "lean side" in that it contains the sub-VI that do all of the work. Find the green arrow/s and start drilling down and look at the run arrows as you go. Running VIs (currently executing) will have a solid black run arrow.

 

The VI Hiarchy screen will help if you have dynamic VIs running. Do a "Ctrl-a" (show all) to show all of the VIs in memory. The VIs can be opened by double clicking the icons and then drill down.

 


@Bob_Schor wrote:

I might be tempted to write a VI that, when called, figures out the name of the VI that called it ...

 

Bob Schor


While it will not show you a log there is a feature built into the block diagram of a running sub-VI. If you look at the space that is used for font control when editing a VI, you will see it has changed to a drop-down that will show you the call stack as you would find if using the "Call Chain" function.

 

Maybe one of those idea will help,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 5
(2,783 Views)