Built In Delay into While Loops

[Clay_Rogers]

Many times a while loop needs a delay for one reason or another, even if its just to add a small delay so the program doesn't peg the processor.  Having this would clean up BDs, and it would also act as a reminder to make sure your code doesn't peg the processor.  (with nothing wired to it, it would default to zero)

[elset191]

See here where crelf suggested this idea.

Message Edited by elset191 on 03-15-2010 02:57 PM

[JackDunaway]

I've actually come full-circle and am going to Kudos the original idea after swallowing my initial concern.

Message Edited by JackDunaway on 03-15-2010 03:02 PM

[muks]

I was hesitant but i have a slight inclination for this and so kudos!!!

[Broken_Arrow]

You said "with nothing wired to it, it would default to zero". However, zero wired to that timer is not the same as not having a timer. We need to be able to right click and delete the timer for those rare cases where we don't want it (AE's for example).

[Intaris]

I think it would be a great addition, again with the caveat that we can disable it altogether if required.  But having it as default would be great.

[AristosQueue (NI)]

No other programming language that I know about has a wait as part of its loop syntax. Can anyone tell me why LabVIEW would need this? I refuse to believe -- barring the introduction of an actual statistical survey -- that the majority of While Loops, or even a large minority, have a Wait in them.

Conveniently, I happen to have such a statistical survey. I did it back in 2003. I ran it over all the VIs I could find inside NI as well as those customer apps that were attached to CARs that I had on my machine.  That survey found that 30 nodes constituted 90% of all the nodes dropped in LabVIEW. The While Loop was the single most dropped node, accounting for ~2% of all nodes. The Wait MS primitive was not in that top 30 list, which means that a whole lot of While Loops did not have Wait MS in them. As a point of interest, all the nodes were built-in nodes of LV, either structures or primitives, except for Merge Errors.vi.

Now, this survey I did has many problems in its choice of subVIs to survey -- my collection of VIs was probably not a statistically valid sample of customer VIs, and the survey is years old. So, let me amend my previous statement: I refuse to believe that the majority or large minority of While Loops have a wait in them unless someone reruns the survey on a larger/more recent base of VIs and finds a different answer.  But I suspect that a survey today would find even fewer uses of the Wait MS primitive since the survey was done before the Event Structure was in widespread use (it had only been out for about a year), and that eliminated the Waits from a whole lot of polling While Loops.

But let's try a test. Everyone who thinks this is a good idea, I've posted a palette and a VI to the forums. The palette replaces your existing structures palette with one with a merge VI that has a Wait MS on it. Now, I know this won't be as usable as the while loop that you can drag around code that is normally in your palettes, but as a test, use it, and keep count of how often you actually use that Wait MS in there. Compare that against the count of total while loops dropped. Here's the link: http://forums.ni.com/ni/board/message?board.id=170&thread.id=484321&jump=true

[lmtis]

I would love to see this idea implemented in a similar manner to the event structure.  A small icon in the upper left corner with the default value of -1, which equals "no wait".  Add your own wait if'n you want one.  In response to AQ, I don't know the percentage of my while loops have a wait, but it is certainly >2%.  The implementation that I suggest would definitely neaten up those loops that require a wait with no detriment to those that do not.

Jim

[AristosQueue (NI)]

Jim: Just to be clear, my 2% number was in reference to the total number of nodes ever dropped on block diagrams that were While Loops, not an attempt to guess how many While Loops actually have such waits. Having said that, the frequency of the While Loop compared to the frequency of the Wait prim overall suggests that even if every use of the Wait prim was inside a while loop, the percentage of While Loops with Waits inside would easily be under 0.5% -- that's just the max accuracy that my survey could even guess at. I'll grant that any single user might have significantly more intersection in the uses of these two nodes.

And I should also be emphatic that I'm not necessarily opposed to this "wait" idea, but it seems like this idea is open ended. For example, lots of while loops have Event Structures in them. Should there be a pop up option on While Loops for "Add Event Structure" that puts an event structure inside the loop? Should there be a terminal for "stop if this refnum becomes invalid" so that I don't have explicit checking logic inside the loop?

At some point, it turns into "Why don't I pop up on the loop and have a palette of things to pick, and why isn't the entire palette in there?" The While Loop is among the single most flexible elements of the programming language. Every other operation ends up inside a loop at some point. Many of those other operations have their own waits built in (like the Dequeue or the Event Structure). Heck, there are even different types of waiting -- the wait in parallel with my loop iteration and the wait between each iteration. Do we need boolean terminals to indicate that distinction? Many operations do not want any waits (like purely functional operations: math, sorting, optimization routines, etc). In those cases, you want your CPU fully loaded doing the calculations. I have a very hard time with the idea that the Wait MS prim should be encouraged by being made a fundamental part of the While Loop syntax, even if leaving it unwired as the default makes it behave just as it does today. 

Message Edited by Aristos Queue on 03-19-2010 03:06 PM

[Darin.K]

Very interesting test by AQ.  I wrote code to scan my LV9 VIs on this computer.  A large, but not overwhelming data set.  Overall I found 121 While loops and 11 Wait (ms) functions inside those loops.  Seems like a low percentage overall, but much higher than I expected.  Then I analyzed only the VIs that were related to forum posts (ie. fixing other peoples' code or quick and dirty examples) and discovered that 10 of the 11 wait statements were in that folder.  I guess I like my loops to spin.

I am ambivalent about changes that I can ignore or are configurable.  If anything, default should be off.

With the Event structure it is hard to see a lot of uses for this.  If I only had the Base package (or LV4) and was polling everywhere, perhaps this makes sense.

Second Test:  More than 60% of the while loops had Event Structures, maybe that should be an option.  Not really, and at any rate I'd suggest the reverse, an option to automatically drop a while loop around the Event Structure.   

Message Edited by Darin.K on 03-19-2010 01:19 PM

[smercurio_fc]

I would have to agree with Aristos and I fail to see the need to make this part of LabVIEW, default or not. We don't need to thrown the kitchen sink at LabVIEW. This is something that's better handled by other tools, such as a merge VI, or the JKI RCF, as suggested by Darren in the original suggestion of this idea.