Which is better between Wait (ms) and wait until next ms multiple when input is 1 ms

[edmonton]

Hi Alex,

Thank you very much for your input. 

I do not fully understand the meaning of your CPU spike. Did you mean the spike as shown in Altenbach's reply? some spikes have approximately 3 ms, My understanding of it is that there are many windows processes running in background scheduled by windows scheduler,  a spike arises when one of the windows process starts, pulling CPU resource. 

I will do more tests to see stability of my application VI. I will also try timed while loop.

As for the LabVIEW crash, I am not sure if I will encounter. 

Regards,

Gu

[edmonton]

Hi Yamaeda,

Thank you for your suggestion. 

I checked my LB2015 and could not locate the high resolution time polling wait. It might be included in higher versions of LB. So I could not give it a try.

One thing I could not figure out is that the input is number of seconds as the link below shows. 

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/vi-lib/utility/high-resolution-polling-wai...

How can a specified number of seconds to control a loop in sub-millisecond?

Regards,

Gu

[altenbach]

---

@edmonton wrote:

How can a specified number of seconds to control a loop in sub-millisecond?

---

It is DBL, not an integer, so you could enter 0.01 for 10ms or 0.0001 for 0.1ms. Right?

[edmonton]

Thank you Altenbach

gu

[alexderjuengere]

---

@edmonton wrote:

Hi Alex,

I do not fully understand the meaning of your CPU spike.

---

sorry, cpu spikes in Windows Taskmanager CPU Diagram - 

if I remember correctly we where using higher polling times, e.g. not 1 or 2 milliseconds, but rather 10 milliseconds+

[alexderjuengere · Accepted solution]

---

@edmonton wrote:

Hi Yamaeda,

Thank you for your suggestion. 

I checked my LB2015 and could not locate the high resolution time polling wait. It might be included in higher versions of LB. So I could not give it a try.

---

if I remember correctly, the "high resolution timer.vi" was officially introduced in labview 2020, but was available before 2020 in the "hidden gems library".

A ccording to this, the high resolution timer appeared in LabView 2017 Hidden Gems.

However, according to this snippet, the high resolution timer.vi was available in LabView 2014

you might take a look into your vi.lib folder an search for it, to add it manually (e.g. drag and drop from Windows Explorer) to Block Diagram

..\National Instruments\LabVIEW 2015\vi.lib\Utility\High Resolution Relative Seconds.vi

the general topic is "busy waiting", in terms of Iterations of an N loop, this means you put in a While Loop, which is running as fast as possible to check if the desired wait time has been reached, if true the while loop is terminated

more over, the high resolution timer can be mimiced with Microsoft's "kernel32.dll:QueryPerformanceCounter"

I can't find the forum post(s), where this has been originally  discussed

from my archive:

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/vi-lib/utility/high-resolution-relative-se...	kernel32.dll:QueryPerformanceCounter in 2015-01-06_tick_count.vi
	attached as labview 2015
	500us
	1ms

 

the set wait time apears to be the most common value (modal value), but

the histogram of "time waited" is  unilaterally limited ( because of  which you probably want to change from > to >=) on the "left side" by the wait time set e.g. 500us, 1 ms

as that is the case, differences won't chancel each other out, if it were the case for a normal distribution around the expected value e.g. 500us, 1ms

therefore, those thiny differences might built up over a period of time somewhere in a later stage in your project.

[edmonton]

Hi Alex,

Thanks.

I had high resolution relative second VI in my program already for timing the software-timed data acquisition loop, it is one of the time functions included in my LB2015. It is different from high resolution polling wait VI, which is not included in Vi library of LB2015. I will test my program more for stability check.

Regards,

Gu

[Yamaeda · Accepted solution]

You should get slightly better timings if you use Greater or Equal. 🙂

[altenbach · Accepted solution]

As was mentioned, these techniques are polling using a greedy loop that burns all resources of a CPU core it can get, so there could be damaging side effects and there are still no guarantees!  (i.e. it is using the same annoying technique as the proverbial little kid in the backseat constantly asking "are we there yet?!").

The Stock "high resolution polling wait" is a bit smarter and only switches to polling once it is close to the target time.

Instead of insisting to run your measurement right on the edge, you should re-think the approach and either use a lower sampling rate or switch to a realtime system. How quickly does the signal actually change? Maybe you could stick with the 1ms wait, measure the actual loop time and create missing values by interpolation for a clean output with 1ms increment..

[edmonton]

Hi Altenach,

My code is as you suggested. I used 1 ms wait in data acquisition loop, then used moving average to smooth data, then used interpolation to produce an equal spaced data as a final result. 

Thanks,

Gu