LabVIEW Probes- Create Debug VI

[JW-JnJ]

I hate to say it, but there is one thing I sorely miss from my days of coding in Matlab. The ability to pause code mid-execution and dynamically try our new code or analyze data. Here is my suggestion for what this may look like in LabVIEW.

Lets say we have a complex set of code that ocassionally has a quirk and you have it paused in that exact spot.

You know your complex equation is causing a problem now, but you don't know why the data in is bad and what to do to solve it. Before, you would have alter your code multiple times to add in analysis VI's and insert possible fixes, then somehow work your way back into the exact state that caused the problem.

I suggest adding a button to the probe window.

This will open up a new VI with controls as each of the probes currently open. These will be linked to the place in memory where the probe data is.

These controls have the exact data as seen in the probe window. You can create new code and run it while the old code is paused.

Now this next part is optional, but might be useful. Changing the control to an indicator would allow you to alter the data in memory. So in the example above, if you changed the Results array using another (fixed) VI, you could continue on with your code and see if it causes problems later.

What does this allow?

• Detailed analysis of data like running an FFT or filter on probe data on the fly without creating a custom probe
• Creating a new, fixed VI to see if it responds to the same inputs correctly
• Test out a new inserted VI before actually inserting it
• Easily export to a file

I'm sure this could do a lot more than I'm anticipating. That's the case with anything you open up to customization by coders.

Either way, I can see this greatly reducing the analysis/fix/test coding cycle by a lot. If you can do in-depth analysis mid-code and try out multiple iterations of a fix without stopping and running again, I can see this being a great time saver.

[admin edit]

NOTE: A large portion of this idea exists in LabVIEW today. Please see Darin K's first post below for details. The idea is being left open because many of the details of how the system works today could be improved.

[Darin.K]

What you describe is an awesome way of debugging, and the best part is that you can do it right now!  Right-click on that SubVI and Choose SubVI Node setup, then choose to show the front panel and suspend when called.  When the SubVI executes, the FP opens with the input data populated.  You can run the subVI with the input data, change the input data and re-run, or simply plug in the desired output values into the indicators.  Then you push a button to return to caller and the code carries on.

[JW-JnJ]

Wow, learn something new every day. I guess I should have seen that coming when I had a response from Darrin.

However, this only solves part of the problem I brought up. It allows you to alter inputs, but not code. Changing inputs will help you understand what is causing problem, so yes it's a good debug method. However, this does not help with finding a solution. Right now you have to take a guess, change it, then work your way all the way back to the error.

You also have the added benefit of customized probes on the fly.

(I'm wondering if I described this "debug VI" well enough. I was hoping it would be an alterable and runnable vi while the current execution is still paused. This debug VI will have access to memory locations of the probes)

[Darin.K]

It also allows you to alter outputs, so you can see what would happen if your code had produced different results.  I have used some quick copy-paste action to try a few things on a separate subVI and then pasted the results into the suspended subVI to check the results in the main program.

[JW-JnJ]

Nice to know. Thanks.

Kinda deflates my idea

[Darin.K]

Just think of it as such a good idea it was already there...

You could either spend the next 10 3 years waiting for this idea to go from the IE to LV or happily stomping nasty bugs...

[AristosQueue (NI)]

I'm going to leave the idea open, but I'm going to ask a moderator to add a note about the existing functionality. The existing functionality is useful, and I think should be mentioned if anyone else comes looking for the idea, but it could certainly be taken further and so remains a good idea worth keeping.

[GregR]

This is basically a variation on the modifiable probe concept and shares a significant obstacle. We can't let you modify a buffer if there is the possibility that another piece of code may be sharing it. This means you either get inconsistent behavior because some wires can't be modified or LV must have compiled without inplaceness so every wire is modifiable. If we compile without inplaceness everywhere, then it will likely have noticable performance impact. If we allow the user to specify when to not use inplaceness, then you still have to declare your intent to do this before you run the top level.

The approach I currently favor is actually expanding and promoting the suspend behavior mentioned above. Right now, very few people know suspend mode exists and even those may have a hard time using it. Like I was describing above you have to declare you want to suspend before the subVI is called. I'd like to be able to enter suspend mode on the current VI from any breakpoint. This gives you VI granularity rather than per wire, but does not require changes to the compile. We could also extend suspend mode with the ability to generate an alternate "debugging VI" which would match the inputs and outputs of the existing VI but be editable. Running it could automatically push its results back to the original VI. When the VI went idle, there could be the option to apply the changes to the original.

This isn't quite the same experience but I think it is more easily achievable in the LV code.

[JW-JnJ]

GregR, that was the one thing I wasn't sure of. The compiling and memory handling. If something like this is better handled by suspending a VI and creating an alternate "debugging VI", then I think that still accomplishes the exact same thing I was going for. Creating the "debugging" VI could just create a duplicate VI instead of what I described above. I think the main things I wanted to accomplish (inline code testing and on the fly probe customization) would still be possible with what you propose. The ability to push debug code back to the original is an interesting concept too, but would that wreak havok on the execution if you forced a new compile?

Thanks for the suggestion.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.