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.
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.
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.
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. )
LabVIEW, C'est LabVIEW
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.
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! 🙂
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.