DAQmx latency/synchronization, AO to AI

[OneOfTheDans]

I'm having trouble identifying a latency between two simple DAQmx tasks. Please let me know if you have any insights!

There is a simple Continuous Samples voltage read task. A loop pulls samples off the task buffer every 100ms (timed by DAQmx Read). After each chunk it writes a single On Demand voltage to the other task. When I change the voltage on the GUI, it gets clocked out after the read, and the new voltage is measured during the next 100ms read window.

When I step the voltage, it shows up in the 100ms window with some latency. I expect this because the output is On Demand and DAQmx buffer is always a little behind. Here's where I'm stuck: the latency is extremely dependent on the read sample rate! 50 kSa/s might cause 5ms latency, but 2 kSa/s can push the edge out to 30ms. Why would the read sample rate affect where the edge lands? If anything, I would expect faster sample rates to delay the edge more, because the buffer is slower to transfer with more samples; the opposite is true!

Any good ideas why this is happening? I'm also open to different timing/synchronization schemes, but at this point the drifting latency really has its hooks in me.

Thanks,

Dan

[Kevin_Price]

Please post your test code, preferably saved back to LV 2020 or earlier.  That'll probably make things clearer quicker than going back and forth with words.

-Kevin P

[OneOfTheDans]

Yep, fair enough. I've been staring at it long enough it's simple in my mind, but I know a picture's worth a 1000 words!

This is a little mockup of the code. Of course, the real code is intertwined within a huge application. 

 

[mcduff]

I did not see a huge latency effect with your example and a USB 6366. However, the following may improve your latency; only change the output voltage when it changes, use an event. Snippet and VI attached. Using the VI below, change was almost immediate.

EDIT: Change your device, I used my 6366 and did not change it back.

[Kevin_Price]

Judging by your device names (Mod1, Mod2), I suspect you're using cDAQ modules.  Which ones?   Are either or both using a Delta-Sigma converter?  D-S converters have a built-in digital filter delay which is largely based on a fixed # of samples.  Thus, higher sample rates result in lower *time* latency than lower rates.

Also, exactly how are you measuring your latency?  Are you just seeing which sample within a given 100 msec packet shows the step change?   That's actually probably a pretty decent method.  (I'm assuming you have a simple loopback from AO to AI).

-Kevin P

[OneOfTheDans]

Thanks for looking at this!

mcduff, that's the coolest LabVIEW thing I've learned in a while - I didn't realize you can pipe DAQmx into a User Event! Unfortunately, the output used to be asynchronous like what you shared (I just set it outside the loop). But I moved it into the loop to debug why the edge was moving. Ideally, we want the edge synchronized with the 100ms capture window so we know roughly where the transition happens, and when transients are settled out.

Kevin, yes, it's a cDAQ-9185 (Ethernet) with NI 9263 voltage output and NI 9238 voltage input.

I found out about the input/group delay recently and thought that was the big answer.

40*(5/512)/Fs + 3.5us

Fs = 50k -> 11.3us

Fs = 1k -> 394us (yes, this would round to ~1300Hz or something)

But that's relatively tiny - I'm actually seeing like 20-30ms difference between fast & slow Fs. Did I use the wrong equation, or miscalculate these delays?

Yes, I'm judging latency on where the edge falls in a single graph shot. It's not very precise, but that's ok. I just wouldn't expect a large obvious dependence on Fs (beyond the ~1ms filter input delay).

The external hardware isn't a simple loopback, but I don't think that matters. Analog out drives a tracking power supply. Voltage in basically measures a shunt on the supply's output. All the hardware/config is constant, but I can very reliably move the edge by changing the read task's Fs.

[mcduff]

---

@OneOfTheDans wrote:

Thanks for looking at this!

mcduff, that's the coolest LabVIEW thing I've learned in a while - I didn't realize you can pipe DAQmx into a User Event! Unfortunately, the output used to be asynchronous like what you shared (I just set it outside the loop). But I moved it into the loop to debug why the edge was moving. Ideally, we want the edge synchronized with the 100ms capture window so we know roughly where the transition happens, and when transients are settled out.

---

There is an Event Case for changing the voltage output in the VI, so you can change it while it is running.

The Change Voltage Event will occur in between 100 ms data captures. Event order is queued.

[mcduff]

One more thing to check the latency, use the Event Inspector with my example.

Below is an output. The "Null" Event is a Voltage Read event, the 3rd number in the column is millisecond timer value. You can see all the Null events are separated by 100 ms. You can also see exactly when the Voltage Change Event occurs before the next Voltage Read Event, you can see if your delays match up.

[OneOfTheDans]

Another cool LabVIEW feature! The Event Inspector, I never knew that existed... unfortunately though, I don't want the voltage changing at arbitrary times, it's supposed to be aligned with the capture window so it happens in roughly the same place each window.

[mcduff]

---

@OneOfTheDans wrote:

Another cool LabVIEW feature! The Event Inspector, I never knew that existed... unfortunately though, I don't want the voltage changing at arbitrary times, it's supposed to be aligned with the capture window so it happens in roughly the same place each window.

---

Sorry. I am not sure what you want. In the example I provided the voltage only changes when the user changes it; it does not arbitrary change. The Event Inspector will show you exactly when you changed it along with the Read Voltage Events, so you know when it occurs with respect to the capture window and its delay.