Example Code

Wait with error

Community Verified
by: Knight of NI JÞB Knight of NI

Code and Documents

Attachment

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wait-ms-with-error-pass-through/idi-p/1177437/page/3#c...

 

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:

 

  1. Include "error in (no error)" and "error out" for data flow.
  2. Take no action when error in is true.
  3. Exit correctly regardless of the system millisecond timer's current value.

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

 Delay.png

 

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.

 

  1. The FP has been given a bit of a silver update
  2. Execution priority settings have had a few tweaks and the vi is now inlined
  3. The "Seconds" input is now a DBL (with appropriate resolution limiting code)

to re-iterate key points on the code:

  1. LabVIEW Shipping delay funtions have no Standard Error functionality.  i.e. it still waits with an error in = TRUE. This is often undesirable when rolling up an error to the handler.
  2. If Built in function are called during a ms timer rollover the routine never returns.  Nasty and insidious.
  3. I avoid the U32 limit on the max wait limit
  4. This routine behaves the same on Windows and RT.
  5. Last it adds support for seconds as dbl floored to mSecs.

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


"Should be" isn't "Is" -Jay

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
crossrulz
Knight of NI Knight of NI
Knight of NI
on

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
JÞB
Knight of NI Knight of NI
Knight of NI
on

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:

  1. There in no guarantee the target even has a High Resolution Timer
  2. Resolution of High Resolution timers varies target to target
  3. High resolution timers have no tie to an absolute time reference and therefore drift (with no specification limit on the drift rate)
  4. Stall Data Flow.vim still depends on Wait (ms) so, the original problems with roll-overs and 0x7FFFFFFF limits remain.

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.  


"Should be" isn't "Is" -Jay
Contributors