Wait for less than 1ms.

[rolfk]

That function may make some people happy, but it can not even remotely guarantee that it waits 50us. The only guarantee you get is that it waits at least 50us. When Windows decides to start a virus scan right at that moment, or anything else of a million different actions, it may take 1 ms, 10ms, or even more than a second before that function returns. And it is a polling wait, so something is spinning in a loop somewhere to check if those 50us have elapsed.

If someone is really concerned about those 50us rather than waiting about 1ms, this is NOT the function to use.

[Petru_Tarabuta]

Hi Rolf,

Yesterday, before posting my previous comment, I briefly tested the High Resolution Polling Wait.vi on a Windows 11 laptop running LabVIEW 2025 Q3 64-bit. During that brief test the VI performed very well. I measured the amount of time it waited by surrounding it with a "Timing Sequence" (a flat sequence structure that uses two instances of High Resolution Relative Seconds.vi to measure the execution time). The measured execution time was always very close to what I had fed as input into the High Resolution Polling Wait.vi (a few microseconds difference).

I don't know enough to dispute that the High Resolution Polling Wait.vi may take 1 ms, 10 ms, or even more than a second, but my gut feel after testing is that this is unlikely.

What makes you think it may take even more than a second?

[rolfk]

So you created a test VI that does nothing else than call the High Resolution Timer value before and after High Resolution Polling Wait. And concluded that function works exactly as you desire. On a computer that is most likely idle, meaning no other applications actively doing anything on the system. Basically there are 8 or more cores doing nothing and you grab one of them to spin in a loop (internally in the High Resolution Polling Wait) and declare victory.

Now you build a real application. Acquiring 16 analog signals from a DAQ card, talking to 4 serial devices, communicating with a network database, saving all the data to disk and displaying it on your screen. And to make matters a little more interesting your IT department starts a preliminary download in the background for a OS update that will be performed after you log out from your computer and Windows decides it needs to do a system check and security scan and your 50us wait that you so happily depended on since you have "proven" that it works so reliably, takes several milliseconds or more and your motion control system runs over its limits and destroys the 10000 $ sample!

Yes that High Resolution Polling Wait can be fairly accurate on modern computers, IF the computer is more or less only busy doing that Wait. It's an entirely different story, if your application and computer also does real world work besides that.

Moral of the story, if you need 50us accuracy do it in hardware, anything else will maybe work when the system does nothing else but will sooner or later go off into the woods. If you don't need 50us accuracy, why not just do a 1ms delay? It won't guarantee 1ms either, but if you do timing in software on a non-realtime system you simply can't depend on ANY specific timing. Yes it will be in most cases in the ms range accurate, but there is simply no guarantee! The 1 second delay or more is an extreme outlier, but absolutely not unheard off. Most of my work computers tend to acquire after about 1 to 2 years of use the annoying habit of sometimes simply "freezing" up for several seconds whenever I do something specific like for instance starting up an application!