Windows 11 not getting 16ms accuracy VIA Timed Loop (timestamp in file jitters between 15 and 17ms)

[nayil100]

Hi Guys,
I am not getting consistent 16ms accuracy with this Timed loop. Am I stuck because I am using Windows OS? 

I will eventually hook it up to compact daq HW for my IOs. Am I doing something wrong?

[ZYOng]

Windows is one factor.

Another bigger issue is the file I/O. From Avoid Common Sources of Jitter

File I/O—Avoid file I/O operations within deterministic loops. Hard disk access can introduce unbounded jitter in a deterministic loop.

Try using producer/consumer loops and implement the file IO in the consumer. For better deterministic performance, use RT FIFO instead of Queue. However, note that:

Queues work with any data type, while the data types that can be used with RT FIFOs are limited. Usually any data type that involves additional memory allocations cannot be used with RT FIFOs in order to preserve determinism.

[nayil100]

Thank you, ZYOng

So, my producer loop will be the timed loop along with the state machine and the consumer loop will just be the while loop for the file IO?

[rolfk]

What you are expecting is beyond Windows capability for many reason:

1) Internal timing in Windows that not even a specially designed plugin, that the timed loop relies on, can circumvent.

2) Windows task and thread scheduling that can suspend threads and tasks for much more than 1ms whenever Windows feels that something is more important (your virus scan, a network packet arriving in the adapter and issuing an interrupt, a rogue process taking up more time than it should, 100ds of Windows kernel drivers and services running in the background and claiming their share of CPU randomly).

3) As mentioned, the file IO in your loop that makes the code execution even more non-deterministic.

Your computer can do a lot in 1ms but Windows may for any reason it likes, suspend your process for 100ds of milliseconds at any time, and there is nothing LabVIEW can do about that. If you need 1ms accuracy, a desktop OS is not the way to go and you need a real-time system. If you want to go below 1ms, the only reliable way is hardware timing with according memory buffers (FIFO), such as dedicated DAQ hardware or FPGA logic.

One way you could try to make your loop a little more deterministic is by sending the data through a queue to another loop which does the actual file IO. However you should consider that the timed loop has to do some integer arithmetic to calculate and try to maintain the interval and that integer arithmetic easily ends up having rounding issues so an exact 16ms interval over a long period is a fantasy dream. Overall it will average out at about 16 ms, but a +-1ms accuracy is as good as it will get.

[crossrulz · Accepted solution]

---

@nayil100 wrote:

I will eventually hook it up to compact daq HW for my IOs. Am I doing something wrong?

---

Then I would not worry about the Timed Loop. Using a hardware timed task (ex Analog Input reads at 1kS/s, read 16 samples per iteration) will give you the timing you need.

[nayil100]

Hey Crossrulz,

But I need to be able to save the data in a text file, like I am doing here. Will writing to the file cause issues even while reading the data fast enough using HW timer?

[RTSLVU]

---

@nayil100 wrote:

Will writing to the file cause issues even while reading the data fast enough using HW timer?

---

Yes, if you use a proper program architecture for high speed data acquisition like a Producer/Consumer.

Simple explanation: The Producer Loop will handle the DAQ and place data in a Queue. The Consumer Loop deques the data and can then process, analyze, save, and display the queued data without affecting the data acquisition taking place in the Producer lopo.

[nayil100]

Thank you, guys, for the response. 
I will try it with Producer/Consumer loop. Very rusty on it, since I never had the need to use it before. 
Only used it during Core 2 training back in 2012, and last used Labview back in 2015...

[santo_13]

I am late to this discussion, in general, use Timed Loop only with RT and not regular windows. As already described Windows is NOT designed for time critical execution (learn more about RTOS).

Always use hardware timed features of the DAQ or instrument for the best time accurate actions and not software determined timing.

[nayil100]

Hi Santhosh,

Would this be an example of HW timed loop? Please ignore the broken wires.