Is an interesting discussion on the need for a reliable wait routine. A general concensus exists that an "ideal" general purpose wait would meet the following specifications:
Since LabVIEW version 5.1 (or earlier) NI-DAQ has encluded "Wait +(mS).vi." This vi meets only the requirement to include the error cluster and has been noted to fail the other requirements. Several years ago I had the unfortunate, and rare, occurance where the Wait +(mS).vi was called just prior to a millisecond timer rollover. Since the 33rd bit of a I32 was never set the vi never returned. I've had some version of this vi in my reuse library ever since. It does meet the three criteria listed above- at some CPU usage cost (Although I've made some attempt to optimze the cost.)
Snippet in LabVIEW 2015. Attached 2015.
UPDATE: Darren's Nugget on Stall Dataflow.vim seems to have re-ignited the age old debate on a Wait with Error Handling discussion.
After several more years, and a large handfull of clients, the source for CCI Delay.vi has undergone some further improvements.
to re-iterate key points on the code:
From the help on Wait (ms)"Note The Wait (ms) function behaves differently on Windows and the LabVIEW Real-Time Module. On Windows, the Wait (ms) function waits up to the value specified in the milliseconds to wait input. On the RT Module, the Wait (ms) function waits at least the value specified in the milliseconds to wait input. The Wait (ms) function has a margin of error of plus or minus one millisecond.
Delay.vi is not obsoleted by Stall Dataflow.vim available in 2017 which adds support for all datatypes including “Green” clusters ( any cluster of <Bool, I32, String> ) but is an alternate to Stall Dataflow.vim where Standard Error Functionallity is desired
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
That VI looks like it could be simplified quite a bit by using the High Resolution Relative Seconds instead of the Tick Count. That whole middle loop to handle the roll over would not be needed anymore.
Another option is to just use the Stall Dataflow vim inside of this VI, you just handle how the error.
That VI looks like it could be simplified quite a bit by using the High Resolution Relative Seconds instead of the Tick Count. That whole middle loop to handle the roll over would not be needed anymore.
Another option is to just use the Stall Dataflow vim inside of this VI, you just handle how the error.
I thought about that Tim, Unfortunately:
The middle section HAS to use Wait until next millisecond multiple. The predictive exit loop might have some wiggle room for optimization but hasn't failed me yet.