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

[edmonton]

Hi Application engineers,

I can use either wait(ms) or wait until next ms multiple, using 1 ms input, Can any one tells me which function is a better option in a while loop for data acquisition? or a more even iteration.

The explanations of the two functions are as below

When LabVIEW calls a VI for example, if millisecond multiple is 10 ms and millisecond timer value is 112 ms, the VI waits 8 more milliseconds until the millisecond timer value is 120 ms, a multiple of 10.

When LabVIEW calls a VI for example, if millisecond timer value is 112 ms and milliseconds to wait is 10 ms, the VI finishes when millisecond timer value equals 122 ms.

I checked millisecond time value  for both cases, they always give a very large number, for example 610698828, keeps increasing. 

Thanks,

Gu

. 

[santo_13]

You shouldn't be using either of them for Data Acquisition, typically Data Acquisition is best when Hardware timed by the instrument used to capture the data.

What instrument do you use?

[Bob_Schor]

I wonder if the Time functions, particularly the difference between Wait (ms) and Wait Until Next ms Multiple from when I wondered about this (maybe 10-15 years ago), looked it up, and said "Oh, that makes sense" ...

The "old" explanation was that Wait Until Next (which I'll abbreviate as WTN) was meant to synchronize parallel loops that should run "synchronously". That is, if you have two loops that you want to run once/sec, but to run "in synch", starting at the same time (to the nearest millisecond), you use WTN -- it not only gets the loops to run at 1 Hz, but they stay "in synch" with each other.  I believe the idea is they were triggered when the "time" on the CPU's internal "clock" was a multiple of the number of ms coded in this function, it would "end its wait" and run.  This means that these functions (if set to the same multiple Time) would work even if in different sub-VIs, potentially even in separate LabVIEW executables running at the same time (since there is only one System Clock, so when its "tick time" is first synchronized to a "whole millisecond", all subsequent calls to WTN will execute essentially "in synch".

Bob Schor

[altenbach]

To answer your second question, the output of both functions is the same as "tick count", i.e. a relative U32 1khz counter that can be used to calculate relative times by subtracting two such ticks.

[AndersSekanina]

I think maybe a better option would be to use a timed loop, especially if you want SW controlled 1 kHz data aqusition. 

[alexderjuengere]

---

I can confirm what Bob wrote in https://forums.ni.com/t5/LabVIEW/Which-is-better-between-Wait-ms-and-wait-until-next-ms-multiple/m-p...

my usecases:

## usecase: polling

 I prefer "miliseconds wait" , as the execution time of "miliseconds multiple" is guranteed to be a multiple of the time in ms set, which can result in cpu-% spikes, when working with multiple loops, each one calling multiple wait.  

## usecase: syncronization

instead of "milliseconds wait/multiple", I use a timed while loop for data generation and queues to do the syncronisation between further loops, as has been already suggested by AndersSekanina. 

for data acquisition, the heavy lifting in terms of timing is usually done by your -more accurate- hardware as Santo13 stated. when you use tcp or udp to communicate with your hardware from within the loop, this will have an syncronisation effect on your labview loops: the loop executes an iteration, when a (udp) package has successfully arrived, and the loop is idle, when no packages are there to be processed. therefore, a simple while loop is sufficient.

[altenbach]

---

@edmonton wrote:

I can use either wait(ms) or wait until next ms multiple, using 1 ms input, Can any one tells me which function is a better option in a while loop for data acquisition? or a more even iteration.. 

---

As has been already said by many here, both are very poor choices for a 1kHz software timed data acquisition. You cannot get a 1ms regular loop time (see below) and if your loop code is heavy (e.g. including fancy math transforms, file IO, and other code running in parallel, etc.,  an iteration might even occasionally take much, much longer than 1ms, throwing everything off. I assume you are running on Windows, which is not designed as a real time OS anyway.

Even with very (very!) lean loop code, both 1ms wait flavors give you a loop time of 1ms and 2ms with about equal probability and around 1% of 3ms, even the very occasional 5ms. You cannot get a regular 1Khz ever with these functions! They are maybe useful for loop times of a few tens of ms. (Detailed results can vary between processors and LabVIEW versions, so try this yourself)

Here's a quick demo that you can try:

Unfortunately, you did not really specify your requirements or even what you are trying to measure, what hardware capabilities you have, and how you are communicating with it. Instead of making random suggestion based on a poorly defined problem, I'll wait until we have all requirement details.

[edmonton · Accepted solution]

Hi There,

Thank you all who replied my original post. 

My application has no capability to use hardwire timed loop for data acquisition, a 8-channel 32 bit each.  I have to use software timed loop.

I did some experiment comparing the two time functions, here below is a summary of the result.

 First, I removed the time function from the loop to see how fast the data acquisition loop can run, I got approximately 20k samples per second. Then, I used 0, 1 and 2 ms as input to the two time functions, respectively, I noticed that wait until next ms multiple runs slightly faster than Wait, but the difference is negligible when 1 ms is used. I choose wait until next ms multiple for my application. CPU usage can be reduced from 65% to 10%.

Gu

[alexderjuengere]

---

@edmonton wrote:

---

I'd say there is no significant diffrence - like significant in terms of relative error - between the two functions.

when I said cpu-%-spikes, I was refering to a phenomena that is not easily to show or benchmark in a simple demo.vi with two sub.vis

the use of many instances of  ms multiple in several .vi's in your project (10-100 .vis, can't remember exactly) can crash labview.

it is an annoying error to debug, because it does occure rarley over time and can be fixed via restarting your application. a better fix is to replace ms multiple with wait ms or don't use it at all. 

Nevermind.

[Yamaeda]

---

@edmonton wrote:

Hi There,

Thank you all who replied my original post. 

My application has no capability to use hardwire timed loop for data acquisition, a 8-channel 32 bit each.  I have to use software timed loop.

I did some experiment comparing the two time functions, here below is a summary of the result.

 First, I removed the time function from the loop to see how fast the data acquisition loop can run, I got approximately 20k samples per second. Then, I used 0, 1 and 2 ms as input to the two time functions, respectively, I noticed that wait until next ms multiple runs slightly faster than Wait, but the difference is negligible when 1 ms is used. I choose wait until next ms multiple for my application. CPU usage can be reduced from 65% to 10%.

Gu

---

Due to limitations/choices in Windows, any wait(ms) lower than 3 will be very erratic. Since you can sample well over 1k that's not the limitation. You can use a high resolution time polling wait, which is a cpu burner strategy, but might be the best choice in this case.