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

[Kevin_Price]

---

Would this be an example of HW timed loop?

---

The answer is "mostly no."

1. The lower loop is *definitely* NOT hardware timed.  The msec multiple timer is a software timing function.

2. The upper loop may be overconstrained for timing, depending on your sample rate.  You should avoid having 2 simultaneous methods for controlling your loop timing!

2a. The msec wait is a software timing function that will limit the loop rate to be no faster than 1 iteration per 100 msec, or 10 iterations per second.  Depending on the parallel actions in the loop, it *can* go slower than that, but the forced wait prevents it from iterating any faster.

2b. Requesting DAQmx to read 5 samples at a time from a hardware-timed *task* can get you to "kinda sorta hardware timing" for your loop iterations.  It will wait for the DAQmx driver to deliver the next 5 samples to the task buffer, then return those samples to you.

    If your sample rate is something like 1 sample per second, you'd typically be waiting 5 seconds per iteration.  The DAQ hardware would be indirectly controlling loop timing, but it still won't be absolutely exact under Windows.  The 100 msec software wait would be done long before the 5 seconds of data are delivered.

    If your sample rate is 100 samples per second, the DAQmx task parts of the code would be ready to get you to a loop rate of 20 iterations per second.  However, the software 100 msec wait would limit you to 10 iterations per second.  Data would keep accumulating in your task buffer each iteration during this extra wait time and you would eventually cause a task error due to overflowing the buffer.

Lesson: if you have a hardware-timed acquisition task, you can use your calls to DAQmx Read as the *only* method for controlling loop timing.  Remove any software wait calls from that loop!

-Kevin P

[ZYOng]

Please refer to Producer/Consumer Read Waveform Data and Write to TDMS at Two Different Rates

The DAQmx Configure Timing (Sample Clock) VI is what makes the acquisition hardware timed. The acquisition will be timed using the onboard clock on cDAQ, not by the PC timing.

If you are okay with TDMS file, which we recommend for high speed streaming. TDMS is a binary file and takes much lesser space than a text file. You can use the built-in DAQmx TDMS Logging feature. See shipping example at Help >> Find Examples >> Hardware Input and Output >> DAQmx >> Analog Input >> Voltage Input (Continuous).vi

[nayil100]

 

Thank you so much for the help, guys. Is this something close to what I need to do? I do not have the DAQ HW with me yet, so haven't setup the channels. 

My text file should now have a constant timestamp of 16ms, hopefully? I will need to check with the client if they will accept TDMS file format. 

[Kevin_Price]

Things that are generally on the right track:

1. The DAQ loop is pretty lean, acting as a Producer.

2. The DAQ loop is timed solely by the acquisition task, no longer overconstrained with software waits.

3. All file writing has been moved into a parallel Consumer loop.

Things that should be changed:

4. Avoid the Dynamic Data Type conversions!!!  You're converting an array of multi-sample waveforms into a 1D array, throwing away some of your data (as well as some useful metadata such as sample period held in the waveform)!    Simply make the queue's datatype to be an array of waveforms instead and enqueue directly from DAQmx Read.

5. You very likely don't need to iterate your DAQ loop at ~60 Hz (16 samples per iteration at 0.001 sec per sample).  Use the typical rule of thumb to read & iterate at 10 Hz or less.  I.E., read 100 or more samples at 0.001 sec per.

6. You haven't quite coordinated your loops properly for termination.  Generally, it should be the Consumer loop's job to release the queue at the right time.  Often it should be the Producer loop's job to send a special "sentinel" value to indicate when it IS "the right time."

Things that probably need more work, but I don't know enough to make definite specific suggestions:

7. The overall structure of the Consumer loop state machine in terms of logic, timing, and signaling back to the Producer.  (For example, it seems to me that when the Consumer changes from the DAQ state to the Deactivate state, it might be time for the Producer to stop producing?  Otherwise it'll just keep building up backlog in the shared queue and an re-activation will start by processing this potentially large backlog of stale data.)

8. You're likely better off saving to TDMS, especially once you change your queue to carry waveforms.  NI provides a free plugin that imports TDMS into Excel pretty cleanly.

-Kevin P

[LVNinja]

Hi 

If your sampling rate is defined in HW, then your data will be streamed in constant flow, you don't need to rely on Windows to have a consistant timing loop. 

IF the samples are acquired continuously, then you don't need to add time stamp for every sample, as long as you have the starting time. 

[ZYOng]

Please see the attached VI for the modification to save data into a text file.

[nayil100]

Hey Kevin,

Let me try to explain what this project is. I am pressurizing a vessel and data logging breathing patterns at user defined set pressures. I am controlling temperatures in certain sections of the process and of course performing pressure controls. There are cases where we will require Fast DAQ, 16ms interval of data for 10 mins per segment/set pressure (that would be 62.5 hertz and 1 sample, I believe). 

We will need it to acquire data fast only during that time. Apart from that it can run slow (100ms) since I have a Front Panel which will be monitored and operated upon. Do I just keep releasing the queue when I am not performing Fast DAQ (even during the initial case of my state machine)? Yes, deactivate is when I am not performing that Fast DAQ, 

I can create a variable and request slower sampling rate at that point?

We will have quite a few IO cards, 2 AIs (8 channel), 2 RTD cards, 1 Relay Out, 1 Digital Out. Do I run all of them through the producer loop or create software timed DAQmx tasks for the rest. Fast DAQ will only occur for 3 Inputs located in the first AI card.

Also, is this the way to unbundle channel 0 of the 8 channel AI card?

Here's the initial case of the DAQ state machine,

Thanks again

[ZYOng · Accepted solution]

You can test with Simulated NI-DAQmx Devices

You can use Channel Expansion to synchronize multiple AI channels.

Do you need to synchronize and/or log the output data?

[nayil100]

No, I do not need to log the Output data. Just 2 AIs channels in AI card #2. That card doesn't have any else wired to it. 

For my other cards, I do not need fast timing, around 100ms give or take is fine. Do I need to create a separate software timed DAQmx tasks for those? Each in it's own loop something like this?

Thank you for sticking around for me and showing me so many vital steps. Also, I do not need to synchronize those channel or points. My rate for everything else is slow, 100ms.

Also, in NI MAX I need to select 1 sample (On Demand), right?

[ZYOng]

For my other cards, I do not need fast timing, around 100ms give or take is fine. Do I need to create a separate software timed DAQmx tasks for those? Each in it's own loop something like this?

Software timing is adequate for 100ms. You need to separate task as you cannot mix input and output tasks together. Ideally a separate loop is preferred so that they don't impact each other.

Also, in NI MAX I need to select 1 sample (On Demand), right?

If you are using the example I shared, the code has configured the DAQ task. You don't need to configure it again in NI MAX.