Functionality available with the existing "Suspend When Called" feature.
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)
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.
Functionality available with the existing "Suspend When Called" feature.