LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

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

0 Kudos
Message 11 of 24
(612 Views)

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

0 Kudos
Message 12 of 24
(599 Views)

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

Message 13 of 24
(585 Views)

Thank you Altenbach

gu

0 Kudos
Message 14 of 24
(576 Views)

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

 

 

 

Message 15 of 24
(560 Views)
Solution
Accepted by topic author edmonton

@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

alexderjuengere_0-1701958461717.png alexderjuengere_4-1701959578457.png

 


 

  attached as labview 2015
 

500us

alexderjuengere_2-1701959382869.png

 

 

1ms

alexderjuengere_3-1701959439620.png

 

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

the histogram of "time waited" is  unilaterally limited ( because of alexderjuengere_0-1701961812171.png 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.

 

 

 

 

 

 

 

 

 

 

 

Message 16 of 24
(535 Views)

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

0 Kudos
Message 17 of 24
(512 Views)
Solution
Accepted by topic author edmonton

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

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

Qestit Systems
Certified-LabVIEW-Developer
Message 18 of 24
(510 Views)
Solution
Accepted by topic author edmonton

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..

 

 

Message 19 of 24
(492 Views)

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

0 Kudos
Message 20 of 24
(467 Views)