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!
Chris
Thanks for the kind words old bean, but more thanks for posting this (videos are such a great addition to these articles). Damn! that’s so useful and a great example of the fantastic debugging facilities LabVIEW gives us (and we then forget about!)
I knew about suspend, but I had no idea you could use it create fake outputs. Interesting trick, thanks Chris!
This is new to me. Unbelievable hidden option. Will try in my upcoming projects.
Hi all,
For TestStand users, this behavior is the default debugging mechanisms when you use ‘step into’ from a TestStand sequence to a VI.
It’s really useful to debug VIs.
Thanks for this little tip, I have used the suspend when called a couple of time because of the automatically open the VI feature, but I was unaware of the other benfits
Does anyone knows the result when we return to the caller without executing the subVI? There is a general rule? In the video the result was 4, the 1st input number. Changing the first input by a string (converted into a number inside the subVI) the result was the last output.
Hi André,
You are correct that when we return to the caller without executing the VI and the two inputs are numerics, it is returning the value of the first numeric input as the output.
If I take the same Add VI and replace the X input with a string (and add to the block diagram converting it from string to a number), now returning to the caller without executing returns whatever was on the output the last time it executed.
I don’t think I had ever encountered this use case. Normally, when I have used suspend when call, I have always either ran the VI or changed manually the output result. If I were to skip the VI all together, I would still modify the output manually to ensure it has the value I want.
I checked the documentation and there is no additional information. (see http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/suspending_execution/).
My suggestion would be to never just skip the VI, given that we have demonstrated that the output would not be something we expect, either run it or modify the output value manually before returning to the caller.
Thanks for reading our blog and for posting.
Fab