Community Nugget: Sub-millisecond timing in LabVIEW

[SteveChandler]

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

[Norbert_B]

Somehow, the topic seems familiar.

Norbert

[SteveChandler]

Yes, I think that thread is what prompted this Jeff to write this nugget.

[JÞB]

Finally- Someone read the VI documentation!

[JÞB]

---

@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 VIS

The Simple Approach:

Precision Timer Wait.vi:

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 Timer.vi requre a bit of undesired overhead so, for advanced users:

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

PT Lightning Wait.vi reads the global instead of the actuall timer parameter and functions simillar to Precision Timer Wait.vi except it does not even waste the FLOPs to calculate how long we were in the loop and it has no error case.

Benchmark.vi 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 Wait.vi that is a waitable object based on the high resolution timer exactly as mentioned above. 

Thank you NI!

[JÞB]

---

@JÞB

LabVIEW 2018 Includes the new function High resolution Wait.vi 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 Wait.vi  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.