Have you ever written a program with no errors in it, that was right first time ? If so, you have led a charmed life my friend, congratulations.

If you are like the rest of us, you will have done your fair share of debugging. Fortunately for us, we use LabVIEW, and it gives us a great head start over our text based counterparts. LabVIEW comes with some great debugging tools and several more are available as add-on packages. I honestly think this that is what makes programming in LabVIEW such fun. We have the immediacy of the IDE, the instant gratification of seeing our code execute and the satisfaction of seeing the impact of the quick changes we make. We also have cool debugging tools such as probes, execution highlighting and single stepping.

(Please check out the link above for the presentation my friend Steve Watts gave on Immediacy at the 2015 European CLA Summit. As usual from Steve, it is thought provoking and brilliant)

A few years ago during an NI week presentation I discovered (and I make no apologies for being dramatic)  the-single-best-feature of LabVIEW ever !

When I first started telling people about this feature they were like “oh, I’m still on 2009 so I don’t have that”.

Well people, let me tell you, this amazing feature has been in LabVIEW since version 1 or 2 (I checked with a member of LabVIEW R&D and even he wasn’t sure, but confirmed it is a very old feature).  Most people I talk with have never heard of it, and even fewer have used it.  The feature I am referring to is “Suspend When Called”.

Suspend when called is like a breakpoint for a Sub VI.

In order to set a Sub VI to suspend when called you can do one of two things:

1. Set the VI Properties > Execution option for Suspend when called


2. Right click on a Sub VI instance and select the Suspend when called option




So you’re thinking “ok, so what? I use breakpoints all the time. Big deal!”

Here’s how Suspend when called works:

When the execution arrives at the Sub VI set to suspend when called, LabVIEW pauses. If the front panel of the VI is not open, LabVIEW opens it. Once this sub VI is suspended it will not continue without further interaction from you, the developer.

So far no great shakes, but notice how the LabVIEW toolbar looks a little different.

Here’s where the good stuff starts. The sub VI execution will not proceed until one of the following toolbar buttons is pressed:



The first button is Run, it runs the Sub VI currently suspended as if it were a Top Level VI.

The cool thing is that we can run it over and over again, we can use our probes and execution highlighting we choose and we can do so as many times as we wish.

Even better, we can modify input values by changing the values of the Sub VI’s controls and observe the output behaviour as the VI executes using the modified input values. This allows us to test a range of inputs and test the expected corresponding outputs.

A little known fact is that when the Sub VI is in this suspended state we can modify the values of Indicators, too!

The second button is Return to caller and it does exactly what is says, it returns to the calling VI (passing the Sub VI outputs) irrespective of whether the Sub VI was executed or not.

If we combine these two features, we have not only the ability to totally bypass the execution of a sub VI but also modify the returned outputs (either by changing inputs or directly modifying the indicators) of the Sub VI and therefore test the behaviour of its caller also.

If we need to abort, then clicking the Abort button of the suspended Sub VI will abort execution of the entire hierarchy.

Let’s see it in action:


So next time you’re debugging a problem, give Suspend When Called a try.

Happy wiring, folks!