highlight execution speed

[falkpl]

I have always been very impressed with Labview's debugging tools but one limitation has bugged me (no pun intended) for a while and I way hoping for a workaround, the highlight execution is too slow.  Is there some way of adjusting the highlight speed (I am still on LV 7.0 but will be moving to 8.0 soon).  Is this hiden in an .ini setting or is there some option somewhere that I just missed.  If not NI should consider replacing the highlight execution with a 3 or 5 speed mode which can be adjusted on the fly.  I find myself stuck when debugging long process algorithms and have to put a lot of stop and conditional probes all over a code or just wait the several minutes to make it through all the highlighted code.  While I am at it it would also be nice to be able to auto arange/dock probes so they are easily organized similar to a watch window.  I also wouldn't mind seeing probes that can be turned automatically into a stack (concatenating array) to document a historical/iterative evolution of a variable or wire.  I dont mean to complain since labview has some of the best debugging tools of any language but there is always room for improvement.  Perfection is a direction not a point.  If there are any implementations of these features I would love to know about them.

Paul

[Marc_A]

From the help file:

"Note:  Execution highlighting greatly reduces the speed at which the VI runs."

I think the point of highlighting is to slow down the execution so that you can see what your program is doing.  If it were much faster, it would become useless.  LV 8.0 also has a feature that lets you retain wire values, so after a VI runs you can probe the wires.  I find this very useful, and maybe it's something that would be better for you.

[falkpl]

Thanks, I agree that much faster highlight is not useful but I could handle maybe a 2x increase especially when the code is highlighting less important sections of my code, I was envisioning like a DVD control where you can quickly scan forward and then slow down the highlighting on more pertinent spots.  I would assume that in the highlight execution code there is a wait(delay) function so that the highlight speed is tied to the system clock in some way, if I could modify or customize this delay it would make me more productive.

Paul

[tst]

I agree, using a slider to control this instead of using breakpoints and such would be good.

Someone suggested once that this slide should have negative values as well so we can do reverse debugging and even see the commands coming back from the instruments.

[altenbach]

Speed is one thing, more important would be selectivity.

I would prefer if I could lasso parts of the code, and execution highlighing would then only occur within the selected diagram area. 🙂

(One possible implementation: Clicking highlight execution turns the diagram a very light grey. Now we can use an eraser like tool, lasso, etc. to make desired areas white. Execution highlighting will only occur in the white areas. )

Ideas?

[JeanPierre]

When the Highlight Execution is too slow or executing a long uninteresting loop I put a break point outside the loop and stop Highlight Execution. After the break occurs, I put back Highlight Execution. It would indeed be simpler if I could select an object and select "Resume Highlight Execution here" in a single click.

[falkpl]

I am glad I am the not the onlyone who would like a little finer control over the highlight execution, currently we are stuck with a on/off model and the only method of manipulation is either a quick hand/eye (for switching between modes) or a well placed break point. The problem with break points is that at least for initial debugging you might not know where too look for the bug.  A simple vi which could be placed inline with any wire and toggles the highlight execution instead of stopping it would help some.

Paul

[altenbach]

Here's another idea:

What if the other debugging buttons would be kept active during highlight execution?

Wouldn't it be nice if we could e.g.  click "Finish loop" during highlighting, and it would finish the current loop without highlighting, but then start highlighting again with the code following the loop?

I think I would use that very often! 🙂

[johnsold]

Good idea!

Lynn

[simplemaan]

I've really wanted the execution highlighting variable speed option for a long time.  I realize that by using breakpoints efficiently you can skip ahead to sections of code that you want to watch without watching slow bubbles, but what about if you are watching a loop progress and you know that your issue doesn't occur until after several loop iterations?

So you have some options: you can set a breakpoint on an object inside the loop and click through each loop, but after so many clicks, it gets annoying.  You could also add code to test the iteration count and trigger a case structure with a breakpoint inside of it or something even more creative, but it would be nice to be able to just move the slider to "faster", let the loop progress for a while, then move it back to "slower" and check on it.

I just wanted to point out that there is a feature in TestStand for variable test execution speeds and it is very helpful.