LabVIEW Idea Exchange

[#1]

Title says it all. Have a slider or pull-down that increases or decreases the highlight execute rate.

[#2]

Just realized that my idea is not original. Of course, leave it to the old pros (falkpl, et. al.) to make guys like me look new.

I am really excited to see NI taking an active role in getting community feedback in an open-forum fashion, and I really respect them for showing the status of their acceptance of the ideas.

Thanks especially to guys like Darren and Aristos for keeping us plugged in to R&D.

[#3]

If it is a slider bar that increases or decreases the highlight execute rate, then there should be a negative end of the bar that "undo"s the highlight execute at a fast or slow pace.

Similar to WMP11 -> View > Enhancements > Play Speed Settings

-Branson 

[#4]

Good grief... although this would be cool, it seems nightmarish to "reverse" data operations. You would have to maintain an "undo" buffer of program's data and execution flow. Can any R&D guys comment on feasibility?

[#5]

No undo necessary but variable speed would be lovely.

[#6]

> Can any R&D guys comment on feasibility?

Considering that we now support the retroactive probes, I've been giving a lot of thought to rewindability of a VI. The problem, of course, is the asynchronous functions -- read from file, dequeue -- and the access to global data -- global VIs, shared variables, LV2-style globals modified somewhere else in your VI hierarchy in parallel. My current hypothesis is that the number of VIs on which this feature could be used is small enough to not warrant working on the feature. You guys should poke around in your VIs and see how many of them are pure functional VIs -- no property nodes, no external storage, no uninit shift registers --  and see if it would really help you to have a "step backward" type of function. In most of my use cases, the places where I would really find it useful is the asynchronous cases, which are the unsupportable ones. For the others, I just use "Create SubVI" around the part I want to rerun and then just run the subVI in isolation -- it gets initialized with the input values when the caller runs the first time, then I abort the caller and run the subVI until I get the right output. Because this option works (and works well), I think that step backward isn't worth persuing.

[#7]

Aristos,

Can you clarify "retroactive probes"?  That is the first I've heard of them.

[#8]

Also called "After probes", it's the little button on the block diagram button bar next to the execution highlighting. The tip strip on the button is "Retain Wire Values." If you turn it on before you run your VI, you can probe the wires of the block diagram and see the last value to come across on those values. Normally you have to put a probe on a wire before you run in order to get data out of it. The option makes the VI run more sluggish, but frequently it is useful for debugging at times when you trip over a value and then based on that value you have to travel upstream to find where that value came from and you don't want to "probe, run, move a bit upstream, repeat".

[#9]

Thanks.  I have seen that, I have used it, but not that often.

[#10]

No idea how i missed seeing this one!!!. Saved me some embarrasment cause I was about to post this...

[#11]

Jack--just so you know, your idea may have been original, it just wasn't unique.  Either way, I had this idea completely on my own, as well, and then saw you had posted it.  Kudos!