Showing results for 
Search instead for 
Did you mean: 

Community Nugget: Sub-millisecond timing in LabVIEW

This is a thread about how to a accomplish a certain task using LabVIEW. Links to your proprietary hardware could be considered spamish.
LabVIEW 2012

0 Kudos
Message 11 of 16

Somehow, the topic seems familiar.



CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 12 of 16
Yes, I think that thread is what prompted this Jeff to write this nugget.
LabVIEW 2012

0 Kudos
Message 13 of 16

Finally- Someone read the VI documentation!

"Should be" isn't "Is" -Jay
0 Kudos
Message 14 of 16

@JÞB wrote:

Windows 2000 and later only! 


What? you say its not possible?

I too was of that opinion.  Its commonly held that we are limited in LabVIEW to the mSec timer and the resolution it offers for benchmarking our vis and creating delays.  Reciently, on a related thread, I was even involed in exploding a suggestion that LabVIEW could be taught this nifty trick.  But I went back to school because I hate saying "You can't do that with LabVIEW."


The attachment contains a project of vi's that use some kernel23.dll precision timer functions to access the Precision OS Timer that exists on modern processors.  there are a few caveats:


These vis use the basic Query Precision Timer functions so DO NOT use them in cases where you don't have a spare core to burn.  There appears to be a method to create a waitable timer as well but, that is not in the scope of this post.


Also- this is not a replacement for a real time OS!  There are sources of error and the OS can (and does) interrupt the process.


There are inherant flaws in the basic input output system that contribute to jitter in calls through kernel23.dll


Some coersion errors may be introduced due to the necessity of mixing U64's and DBLs in the math.  (Hey, if anyone can solve that I'd take a lesson, I hate saying "You can't do that with LabVIEW.")



The Simple Approach:

Precision Timer

Is a basic stand-alone delay with a 100nSec resolution uSec to wait input.  Negative values are coereced, resolution is coerced to next higher 100nSec.  Actual resolution of the delay is dependant on HARDWARE or how fast your precision timer is updated.  Ths vi querys the PT frequency and the current count. calculates what the count will be in x uSec and enters a greedy loop untill the PT counter is equal to or greater than the target.

This vi DOES test if the hardware supports a precision timer and has standard error in funcionallity.


The more optomized approach:

The case structures in Precision requre a bit of undesired overhead so, for advanced users:

PT Init Querys the timer frequency and preloads the global variable Counter (Globals are not evil and this is one case where their blinding fast speed is useful)

PT Lightning reads the global instead of the actuall timer parameter and functions simillar to Precision Timer except it does not even waste the FLOPs to calculate how long we were in the loop and it has no error case. demonstrates the optomized approach and explores some of the precision timer sources for error


All vi's are fairly well documented with their execution settings (obviously default settings were undesired)


For further reading on Precision Timers I recommend starting HERE and google your hearts out.


if anyone wants to play with a waitable timer object... (I'm curious but "Time Constrained")


Additionally, those of you with existing Benchmark vi's.  I would be fairly interested in a benchmark benchmark comparing the two timer methods.

Now that I have finally installed LabVIEW 2018, it is time to update this thread.


LabVIEW 2018 Includes the new function High resolution that is a waitable object based on the high resolution timer exactly as mentioned above. 


Thank you NI!

"Should be" isn't "Is" -Jay
Message 15 of 16


LabVIEW 2018 Includes the new function High resolution that is a waitable object based on the high resolution timer exactly as mentioned above. 


Thank you NI!

And I stand corrected.  The new function is High Resolution Polling  Its Block diagram is open.  It does not create a waitable timer object as I had been led to believe it does use polling QPC.  Hardware and BIOS can greatly effect the nodes latency CAVEAT EMPTOR!  There are several improvements / Differences with this new node over the attached example in this nugget.

  1. The vi is set to run in any thread and will share its greedy loop iterations across threads and cores
  2. It has been made cross platform so it supports all OS's that LabVIEW Supports
  3. It behaves identical to Wait (ms) on RTOS's  That is, it waits at least "seconds to wait" it never returns prematurely as can happen With Wait (ms) on Windows.

"Should be" isn't "Is" -Jay
0 Kudos
Message 16 of 16