Why Am I Experiencing a One-Point Delay in Synchronous Acquisition with DAQmx?

[MapleBay]

Hello everyone,

I'm currently working on a project involving synchronous data acquisition using the USB-6341 device and LabVIEW 2020 (32-bit). However, I’ve been facing an issue where there seems to be a one-point delay in my data acquisition.

Here are the details of my setup and the steps I've taken so far:

Experiment Conditions:

• Device: USB-6341
• Software: LabVIEW 2020 (32-bit)

What I've Tried:

1. Using the same clock source for the sampling clock.
2. Using various triggers such as AO StartTrigger, AI StartTrigger, and PFI0 as the trigger source.

Despite these attempts, the one-point delay persists. Below, I've attached my code and some screenshots from my experiments for reference.

Has anyone encountered a similar issue or have any suggestions on how to resolve this delay? Any insights or recommendation

 

s would be greatly appreciated!

Thank you!

[rolfk · Accepted solution]

So you output an analog signal on an analog output and read it back on an analog input that is synchronized to the same clock? And you expect the analog input to instantaneously (within 0.0ns) to see that voltage? How fast do you want the electrical signal to propagate through a wire? Entangled Quantum states are not something that happens on this physical plane. Besides the DA and AD converters are not working instantaneously either, they do require some time to output the actual analog value and convert it back. The clock is when these operations are triggered, so the sampling of the input voltage is triggered at the same moment the output value on the DAC is transferred to the output stage.

You can reduce that delay theoretically by delaying the clock to the ADC by the sum of what the DAC needs to generate the voltage on the output plus the delay of the ADC sample and hold input stage, but you can never make this go to 0. And such a delayed clock will make your entire DAQ setup a lot more complicated and require you to add an additional counter to generate a controlled delay.

[Kevin_Price · Accepted solution]

Sometimes, the simplest useful thing to do is work around the issues rolfk brought up.  Just accept the fact that for any AO sample # i, the AI sample that responds to it will be sample # i+1.  You could just discard the first AI sample and keep the rest.

The easiest thing to try to *solve* it is to use a shared sample clock, with one task using the rising edge and the other using the falling edge.  I don't happen to know the pulse width of the internal sample clock signal or its idle state, but there's only 2 ways to set them up for opposite polarity, so you can try both and see if one of them works.

However, the pulse width may be too short for this to work.  A little more delay may be needed.  If so, you can use one of your devices counters to generate a pulse train that both AO and AI use as their sample clock.  Then you can control the pulse width between rising and falling edges to make sure you provide enough time.  This also comes in very handy in a typical stimulus-response system where you *also* need to allow for system response time between the new AO stimulus sample and the next AI response sample.

With the counter approach, be sure to start both AO and AI tasks before starting the counter task.

-Kevin P

[MapleBay]

Thanks.

Is it possible then to understand that it is because it takes some time for the AO to be transferred from the physical wiring to the AI, so inevitably a gap of one point is created.
So it's really a question of physical transmission.

MapleBay

[MapleBay]

Thanks for your response.

I understand from rolfk and your reply that this is a physical transmission issue.

MapleBay

[Kevin_Price]

It's less about the physical transmission from an AO terminal to an AI terminal and more about the internal circuitry response times for the AO DAC and the AI ADC.   But like I said before, you can sometimes kinda "hide" that by doing AO on the leading edge and AI on the trailing edge of the same clock.  If the internal sample clock has too short a pulse width, you can make a wider one yourself with a counter that both AO and AI use as their sample clocks.

Depending on the specific app & system in question, it may still be simpler to just understand this issue and ignore the first AI sample.

-Kevin P