Wait Until Next ms Multiple - Millisecond Timer Rollover

[jj02520024]

The highest value the millisecond timer can hold is 2^32-1 (4,294,967,295). When the millisecond timer rolls over, is there potential the duration waited can exceed the millisecond multiple?

To demonstrate, suppose we're using a millisecond multiple of 10 ms.

#    Tick count       Comment

1    4,294,967,262    First call of Wait Until Next ms Multiple

2    4,294,967,270    Waited until next ms of 10

3    4,294,967,280    Waited until next ms of 10

4    4,294,967,290    Waited until next ms of 10

5    (4,294,967,295)  Millisecond timer max value

6    (0)              Millisecond timer rollover

7    10               Waited until next ms of 10

8    20               Waited until next ms of 10

Between #4 and #7 above, the duration elapsed would be 15 (or 16?) ms. Does Wait Until Next ms Multiple behave this way?

[JÞB · Accepted solution]

The simple answer is no.  The rollover is a multiple of every value.  You may return early but never late. +/-1mSec

[Minions]

Is this a Real-time system or is it Windows Based?

A Windows based system is dependent on when Windows allows the LabVIEW primitive to function.  We saw times where the wait times approached almost a half second due to Windows' Activities.

[jj02520024]

Windows based. I see, that makes sense as my application was throwing errors at unexpected times like when inserting a USB flash drive.

My application continuously generates an analog output waveform which can be changed on the fly. Because the waveform needs to be changed on the fly, regeneration is not allowed. Essentially, when generation is started, the application:

1. Store the waveform in a shift register
2. Set the output buffer size to the waveform size
3. Write the waveform to buffer
4. Start the task
5. Write the waveform to buffer again
6. Wait until next ms multiple, in multiples of the waveform duration
7. Go to step 5 and loop

If the wait in step 6 ends up being longer than the waveform duration because of Windows, then the write buffer will empty while still trying to generate samples and I get a DAC error.

It's pretty rare that the issue happens, but I guess I'll explore other methods of timing the manual regeneration of the wave. I can't just allow DAQmx Write.vi to run until the write buffer is full without waiting because my hardware's write buffer size is huge compared to my waveform size; my on the fly waveform adjustments wound't be as responsive.

[jj02520024]

Didn't realize the rollover counted as a multiple as well. Thanks! 

[JÞB]

Yeah, anything times 0 is valid at 0

[Kevin_Price]

Maybe you should consider using a DAQmx Event such as "Every N Samples Transferred From Buffer" instead of Wait Until Next ms Multiple.  That ties the timing more directly to the task's progress.

Another couple thoughts:

- My habit for non-regenerating outputs is to never write more than 1/2 buffer size in a single DAQmx Write call.  However, I'll sometimes redefine the entire buffer "all at once" by chaining together 2 consecutive DAQmx Write calls.

    Note: it's quite possible that this habit is obsolete.  Many years ago when I developed the habit, it was pretty important for preventing underflows.  DAQmx may do a much better job these days of handling full buffer writes.

- There's a DAQmx Channel property for "Data Transfer Request Condition."  It can be used to help control latency between writing new data to the buffer and having it show up on a terminal pin as a signal.   Note: it *only* addresses the latency due to the *additional* FIFO on the DAQ board itself.  It's still up to you, the app programmer, to handle the latency caused by the buffer you write to with DAQmx Write.

- A DAQmx Write property for "space available in buffer" may be of further help in managing this latency.

If it seems a little tricky to manage these different aspects of buffer size, latency, write rate, and timing variability, well, that's correct.

-Kevin P