LabVIEW Idea Exchange

[#1]

 

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

[#2]

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.

-D

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.

[#3]

[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

[#4]

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

[#5]

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.

[#6]

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

[#7]

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.

[#8]

OK - I think we're on the same page now.

[#9]

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")

[#10]

Thank you Darren.  I had no idea the For Loop had an optional conditional terminal. 

[#11]

Note that this idea was reposted by someone else. Additional comments and arguments pro/con are in there.