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!
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
TimmTheEnchanter

Add Conditional Breakpoint Capability for Debugging

As a debug tool, it would be incredibly helpful for me if I could pause at a certain point in the code when a value meets a certain criterion, without having to edit the code.

This functionality already exists as the "condition" tab for an error cluster in the Probe Watch Window, but does not exist for any other type of data.  (In the image below, I'm showing that the "condition" tab will enable me to pause execution when the data on the error wire I've probed is updated, and the "error" boolean of that cluster is TRUE.)

 

probe window.GIF

 

In other words, I'd like to see this behavior become more robust/flexible for other data types.  The alternatives are:

1. In run mode, put in an unconditional break point somewhere in the code, and manually step through the code as I watch the probed wire of interest update to the value of interest, so that I can continue debugging - or

2. Stop the VI an all the VIs which are running on top of it, and in edit mode, create a case structure which evaluates as TRUE whenever the wire of interest is updated with a value I care about (as in this image):

 

Work_around.gif

 

The problem with #1 is obvious - lots of lost efficiency.

 

There are several problems with #2, being that you must enter into edit mode for this work-around to debug your code:

  • I may be inheriting a lot of complex code for which the architecture is already pre-determined, so I cannot effectively influence the VI hierarchy to make this kind of breaking work-around for debugging convenient
  • I may have some other design constraint that requires me to makes breaking in this work-around inconvenient.
  • There may be a lot of data which is loaded/unloaded dynamically by the VI, so this is lost efficiency.  Perhaps I'll need to wait hours or days for the same data to occur, such that the code is back into the same state where I can take the next step.
    (There's never a guarantee that putting in just the one brekapoint will be sufficient to capture everything I need to know to debug, so this just gets me one step closer to finding out what kind of edits I need to make next, to further debug.  That iterative process would be much easier if I didn't need to enter "edit" mode.)
  • I must often make changes to my data flow in order to ensure this debugging pauses at the correct instant in time, since the value I am waiting for probably influences something later on in the code that I want to watch with Highlight Execution or whatnot.
    (e.g. above image, I cannot simply branch off of the I32 data wire to create this case structure/breakpoint work-around.  I must re-route the wire through each case of the case structure, or something equivalent, to enforce that I break at the appropriate time.)
  • VI recompiles due to edits
  • Lots of clicking to set this up
  • I must go back and undoall the edits to the code again to put it into its original state once debugging is finished.

 

So here's what I'd like to see:

 

 

Other considerations:

  1. Obviously, we can be all sorts of creative and crazy on the implementation, asking what-ifs for if you want to pause for multiple values, or an array of values, or whatever.  That's not the 90% use case.  I really only care about pausing with one, simple comparison on one primitive value (like boolean, string, integer, and floating point.) The kind of comparison would depend on the data type under investigation (e.g. you probably wouldn't need greater than, less than, etc. for boolean, and may not need them for string.)
  2. Let's say hypothetically someone implements this, and lots of people begin using it.  THEN maybe you could consider adding support for non-primitives, such as a clusters and arrays of primitives - but I make no suggestion of how to handle those in the probe watch window.  Doing comparisons on arrays would require more processing, and at that point I think the coder is on his/her own put the right hooks into the code to pause and debug when something doesn't look right.
  3. Something I could see a more immediate use for - pause in another area of the code based on an update to a wire value.  So in other words, lay down a breakpoint in one VI, and set it to conditionally pause based on a value in another VI.  This brings up a synchronization/communication problem that could possibly be resolved by setting a flag from one VI when the value updates, and when the breakpoint of the other VI recognizes that flag, it activates upon execution.  I'm sure that's more complex than my above suggestion, though.
  4. Perhaps you could do something like this with an X control (I'll admit I don't know much about them), but that requires a preconceived notion of whether or not I'll ever need to debug by pausing for a certain value on that data type.  Also, I don't really feel like creating a custom control for an I32, just so I can try to future-proof all of my debugging.
National Instruments
5 Comments
TimmTheEnchanter
NI Employee (retired)

Well, apparently LV Idea Exchnage barfed on the So here's what I'd like to see image, so I'm re-posting it here:

 

Probe_Window_Suggestion.gif

National Instruments
AristosQueue
Proven Zealot

This already exists in LabVIEW.

 

Untitled.png

If you do not like this conditional probe, you -- or any user -- have the power to write your own custom probes. Custom probes allow you to present any sort of UI that you wish for displaying a value and breaking execution on a value.

 

The list of useful probes for data types is really large and open-ended. Several years ago, LV R&D made the call to put attention into making it possible to create custom probes rather than spend time enhancing each individual probe ourselves. From time to time, we have added new custom probes, but it has not been a priority to enhance the probes of a particular data type. But we do have the range checking probes that you asked for.

 

Since you work for National Instruments, if you do build probes that you think are better for a given data type, send them to LabVIEW R&D and see if they can be put into the next version of LabVIEW.

 

Any users who do not work for National Instruments may choose to share your probes with the community through the ni.com forums or through the LAVA Code Repository.

Darren
Proven Zealot
Status changed to: Already Implemented
TimmTheEnchanter
NI Employee (retired)

Alright, thanks for the insight.  I'll take a look at 'em.

National Instruments
X.
Trusted Enthusiast
Trusted Enthusiast

The link posted by Darren is a case of the proverbial serpent biting its own tail it would seem...