LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

when stepping into a VI, do not read controls before pausing

when stepping into a VI,

do not read controls before pausing

because latch value should not be reset prior to pause
and because debugging capability would be enhanced with ability to change control values at step in (like TS LV adapter)

2 Comments
Proven Zealot

Short answer:

LV already has this. The feature you want to use is "Suspend When Called."

When in edit mode, right click on the subVI and choose "SubVI Node Setup." In the dialog that appears, put a checkmark in "Suspend when called". When the subVI executes, it will break execution. The subVI will be opened. You can change the controls before running, and the buttons on the diagram will let you move through the subVI AND reset it to the beginning to run again and again. Even more powerful, you can simply set the values of the indicators and force the values that will be returned to the caller. It is one of the least known and most powerful debug tools in all of LabVIEW.

 

This suspend feature has to be enabled on the subVI node at compile time because it has to change how the caller VI is compiled.

 

Detailed answer:

In a regular subVI call, the subVI does not read from the controls that are on the connector pane when the caller calls it. The controls get a value written to them from the block diagram if and only if the front panel is open. The value that is on the wire in the subVI doesn't come from the controls... it comes from the caller and is often shared memory with the caller diagram (avoiding memory copies). Because it is shared, it cannot be independently changed inside the subVI (because you'd rewrite the caller diagram, possibly changing the value of block diagram constants or other branches of the caller wire).

 

By enabling "Suspend when called", you tell the caller to compile itself to not share the data going into the subVI. You also inject code into the subVI that not only writes the values to the controls (so you the user can see them) but it also makes the VI read from those controls when you step into its diagram (in case you decide to adjust those values). And it puts the VI in a test harness that lets you restart the subVI over and over without aborting or stopping the caller VI.

 

If you don't want to break on every call to the subVI, you can use this trick:

drop a case structure and put the subVI in both the True and the False case. Enable "Suspend when called" on only one subVI node in one of the frames. Then have the condition on the case structure decide which one to call.

Example Gatekeeper
Status changed to: Already Implemented

Functionality available with the existing "Suspend When Called" feature.

DNatt, LV R&D