LabVIEW Idea Exchange

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.)

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):

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.

It would be nice if there were an ability to grey out and not allow selection of an ENUM item if it has already been selected in a previous menu. 

For instance, if for "AO Channel 1" you select AO3, when you click the drop down for "AO Channel 2" there should be a way to disable AO3 since it is already in use.

Hi

Suppose we have a big code in that a part of the code need not be executed ( still obeying the data flow).There is no option to do that .Those who are familiar with Matlab /Python  know there is acommenting option .Once commended thet statements will not get executed.The problem with LabVIEW now is in abid code if we want to try if a node need not get executed we have to delete it then claerind of wire will come.If we want to include it again we still have to do thwe same thing.If something is there ( may be a rectangle) when drawn around  a particular node keeps it away from the execution it will make development/testing  easy