LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

1 ms wait is the same as a 2 ms wait

A 1 ms wait and a 2 ms wait are the same for me. This is probably a limitation of the OS (Win 10) right? No way to do better?

Example_VI.png

0 Kudos
Message 1 of 14
(2,939 Views)

@nanocyte wrote:

This is probably a limitation of the OS (Win 10) right?


That is correct.  If you need more exact timing, you need to go to a Real Time OS where determinism is more important than a GUI or being a general use OS.


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
0 Kudos
Message 2 of 14
(2,932 Views)

You could try the High Resolution Polling Wait VI and see if that's any better.

 

But in general yes, if you need exact timing, use a real-time OS.

0 Kudos
Message 3 of 14
(2,891 Views)

(Edit: why didn't I see the previous reply? Oh well, to repeat: )

 

You are measuring the wait time with low resolution. Measure using the High Resolution Relative Seconds and see what you get.

Certified LabVIEW Architect
0 Kudos
Message 4 of 14
(2,822 Views)

Just comment to clear up a little confusion:

 

"High Resolution Relative Seconds" doesn't help - at least not for me.

"High Resolution Polling Wait" did the trick. Well, at least much closer than the original vi 😃

 

thois - brain malfunction when you repeated??? 

0 Kudos
Message 5 of 14
(2,816 Views)

@thols wrote:

(Edit: why didn't I see the previous reply? Oh well, to repeat: )

 

You are measuring the wait time with low resolution. Measure using the High Resolution Relative Seconds and see what you get.


He's measuring the time to do 100 sequential waits, so the regular resolution timer should be fine- he should see 100 ms of time, then 200, 300, etc.

0 Kudos
Message 6 of 14
(2,797 Views)

@nanocyte wrote:

A 1 ms wait and a 2 ms wait are the same for me. This is probably a limitation of the OS (Win 10) right? No way to do better?

 


Nope, can't do better with a normal wait. Why would you need it to? You can use a High Resolution polling wait, or e.g. set up a AI sampling and read 1 sample at a time as clock or something more exotic...

(I think you can hack the registry to change some windows clocks and timings, but it's not worth it)

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 7 of 14
(2,713 Views)

Note that 0 ms is special.

 

In your test it doesn't seem to do anything, but it does switch thread (or clump?). If there are no other threads, it won't effectively 'wait', but if there are other threads it might actually result something not 0.

 

Waiting 0 ms is not the same as putting the wait in a case and skipping it completelly.

Message 8 of 14
(2,704 Views)

Some interesting information on the subject.

https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 9 of 14
(2,681 Views)

 


wiebe@CARYA wrote:

Note that 0 ms is special.

 

In your test it doesn't seem to do anything, but it does switch thread (or clump?). If there are no other threads, it won't effectively 'wait', but if there are other threads it might actually result something not 0.

 

Waiting 0 ms is not the same as putting the wait in a case and skipping it completelly.


Can you point to documentation that describes this? Is it Windows specific? My intent was to have a small wait so as not to starve other threads but 2 ms was too long so a 0 ms wait might be just what I'm looking for.

0 Kudos
Message 10 of 14
(2,672 Views)