LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Variable Speed highlight execute

Status: New
Title says it all. Have a slider or pull-down that increases or decreases the highlight execute rate.
Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
14 Comments
Trusted Enthusiast

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.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Member

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 

Trusted Enthusiast
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?
Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Member
No undo necessary but variable speed would be lovely.
Proven Zealot

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

Knight of NI

Aristos,

 

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

Proven Zealot
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".
Knight of NI
Thanks.  I have seen that, I have used it, but not that often.
Proven Zealot
No idea how i missed seeing this one!!!. Saved me some embarrasment cause I was about to post this...
NI Employee

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!

National Instruments