Home > Community > Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!

A native ms wait in every loop

Status: New
by Active Participant crelf Active Participant on ‎06-01-2009 06:34 PM
If unwired it would default to 0, and at least let thread switching occur.  You could maybe right click on the loop and remove the wait node to make it run as fast as possible (like it is now), but it should be there by default...  Maybe also right-click on it and get to choose between "Wait (ms)" and "Wait until Next ma Multiple"?
(PS: I know that you can do this using timed loops, but I'd like to see it in all of them - I've seen too many "programmers" complain that their CPU is at 100% because their loops are going nuts).
by Trusted Enthusiast
on ‎06-02-2009 02:38 PM

I like the native wait idea, but I would prefer it be non-default, and have it be shown via a right-click option (like the conditional terminal on For Loops).  I think that 8 times out of 10, my While Loops run as fast as possible because I want them to.




P.S. - Another option would be to write a plug-in for the JKI Right-Click Framework.  Right-click on While Loop > Add Wait would drop a normal Wait primitive in the lower corner near the stop conditional, with a constant already wired with a user-specified default value.

by Active Participant crelf Active Participant
on ‎06-02-2009 09:43 PM

[Darren] I disagree about the deafult/non-default.  I think that most programmers don't understand the difference between no wait and a 0ms wait - they think they're the same thing, so they don't see the point of a 0ms wait.  I'd prefer it to be ther by default, and then people who know what they're doing can remove it if they so choose (through the right-click mechanism you mentioned).


Sure, there are a lot of ways this can be acheived right now: JKI right-click framework, a merge VI in our reuse library, etc, but I want something that's automatically inutative - I don't want to have to think about it.  If I could distribute a reuse package that replaced the loops in the palette with my own merge VIs with loops and the wait already in there, then I totally would, but that functionality doesn't exist in VIPM... yet Smiley Happy

by Member K1200LT_rider
on ‎06-03-2009 07:15 AM

>> ...most programmers don't understand the difference between no wait and a 0ms

>>  wait...


Well, that includes me.  I had no idea.  Even though I went through the LabVIEW Basics CDs, I don't remember that ever being mentioned.  Add this as a suggestion for being added to the training CDs (if they are still sold and if it isn't already in there).  I learned something new today.


I vote for it being default.  I don't think I have ever had a loop without a time delay, and it does get old having to manually find and place it every time (in LV versions without Quickdrop), and finally create a constant.  Maybe that could be another related idea: When you manually place a time delay icon, automatically place a wired constant ready for typing a value.


- Brad

by Trusted Enthusiast Trusted Enthusiast
on ‎06-04-2009 05:54 PM
I would have to vote against this idea... If you begin to require our friends at NI to force "good programming practices" on us, our power to control our apps is diminished.
by Active Participant crelf Active Participant
on ‎06-05-2009 09:26 AM
[mechelecengr] How so? The suggested idea allows you to turn the feature off, so your power to control apps isn't dimished at all.  I don't understand your comment...
by Trusted Enthusiast Trusted Enthusiast
on ‎06-09-2009 10:33 PM
Perhaps I was a little harsh. With Darren's right-click non-default option, this becomes a handy bell and whistle for some people. As long as it can be turned off, I do not oppose this idea. Most of my work is HMI, so I use an event structure or queue/notifier timeout for metering loops, so I would have this feature turned off 95% of the time. Embedded programmers (or new HMI programmers) might appreciate the auto-wait-insert for polling loops. As an aside,  the primitive to "Wait til next ms multiple" rather than "wait" might get a more predictable loop rate.
by Active Participant crelf Active Participant
on ‎06-10-2009 02:15 PM
OK - I think we're on the same page now.
by Trusted Enthusiast Trusted Enthusiast
on ‎03-15-2010 03:09 PM
Yes, we are on the same page now. So Kudos to the defaulted-off version of this idea. (And even though it's subtle, looking at your 100msec wired to the "Wait Terminal" reminded me of the un-blurring the "Show Constant Folding", just like "Show Buffer Allocations")
by Active Participant lmtis
on ‎03-19-2010 02:12 PM
Thank you Darren.  I had no idea the For Loop had an optional conditional terminal. 
by Knight of NI Knight of NI
on ‎03-19-2010 03:34 PM
Note that this idea was reposted by someone else. Additional comments and arguments pro/con are in there.
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!
Idea Statuses
Top Kudoed Authors