improved Debugging for parallel loops (optional / selective debugging)

[Andi_S]

Parallelisation of loops is a great thing in LabView that offers a lot of possibilities and it's very easy to implement. In opposite to this debugging can drive you crazy regularly. A typical situation for me is that there are two loops in parallel whereby the first waits for user input (and handles it) and a second one cycles all the time doing some other stuff.

Assumed that the one with the user event handler needs to be debugged I place a break-point on a good place. When the execution stops there, I usually want to go step by step through the code. The problem is now the 2nd loop: because it is running in parallel the execution pointer jumps always between the two loops. I have to step through each function of both loops even that I only interested in the first one.

This becomes very annoying, confusing and time consuming if there is a lot of code in the 2nd loop, if the diagram becomes larger at all and if the highlight mode is activated.

To avoid this I suggest to show optional elements for debugging for each loop. With those elements I could decide if I only want to step through the code of the first loop while the second is executed normally (no highlighting, no single step).

Current situation:

improved functionality:

[altenbach]

Seems related to this idea.

(not entirely duplicate, because you talk about debugging in general (stepping, etc.) instead of only execution highlighting).

[Andi_S]

You're right, the linked idea is very similar. But it's from 2009 and still not implemented -

[David_Staab]

Hah, I was about to comment that I'd rather be able to lasso just the code I want highlighted...and then I saw that the other idea asks for just that. I prefer that idea to this one because it's more general-purpose.

[PrimaryKey]

What about putting the loop inside of a subVI? This kinda solves a problem of not being able to debug in parallel.

What is the problem with that?

Spoiler

[RavensFan]

1.  First you'd have to create a subVI thus somewhat changing your code.  That in itself may not be a huge price to pay.  But.

2.  If the loop goes into a subVI, and that loop is dealing with front panel elements such as terminals, or using property nodes of items in the main VI, you will now break the functionality of that loop since it can no longer directly access those objects.