LabVIEW RT - Unexpected 1s lag in DAQmx Read from PXIe-4302 (Voltage Input)

[LVUser94]

I am using LabVIEW 2020 RT to read continuously from a 32-Channel PXIe-4302 at 100 Hz Scan Rate. My Loop rate is set to 100ms, and I ask for 10 samples per read. When I monitor that actual loop time, it is indeed 100ms and I am getting 10 samples per read. However the voltage values are typically lagging the actual voltage input (from a potentiometer connected to the channel). It takes > 1 second for any signal level change to appear in the data.

The same code (except that I am using a cDAQ-9201 8-channel DAQ module instead of the 32-Ch PXIe-4302) on LabVIEW 2020 (Windows) runs fine and any signal level change appears almost instantaneously in the data.

I have also played with the DAQmx Read Properties (Relative To Recent Sample, and Offset set to -1) but see no improvement in the RT. The 1s delay remains. 

The DAQmx version on the RT PXI System is NI-DAQmx 21.0.0 .

Has anyone seen this noticeable lag in RT and not in Windows? 

I am enclosing a stripped down Main VI and its SubVI for your examination.

Thanks for your time!

[Bob_Schor]

I noticed that in your cDAQ Test Init case, you wired in the Scan Rate (100 Hz) but not the Samples/Channel (default 1000).  Could this be a confounding factor?  [I can't think why it would be ...].

Bob Schor

[LVUser94]

Thanks for your reply.

The Samples Per Loop is only used in the "Read" case so I did not wire it in "Init" case.

The "Samples Per Channel" default is 1000 as you noted. I did not change it as it will give me 10 s buffer size which is large enough.

[LVUser94]

I did some more tests today, but this time I used the NI MAX Test Panels instead of my VI, using the same settings for Scan Rate (100Hz) & Samples to Read (10).

With the MAX Test Panels (in RT), there is still the same 1-2 s latency. So does this indicate a driver issue or PXI card issue?

[Kevin_Price · Accepted solution]

Spoiler: Looking over the code, I can't explain a 1-2 second latency

Tip: to read the "N" most recent samples (which you should receive immediately, once the acquisition has run long enough to capture at least that many in the first place), you should set RelativeTo=Most Recent Sample and set Offset=(-N).   In your example, N=10 so offset should be -10 from the most recent sample.

    Setting it to -1 means that you'll get 1 recent samples and 9 future ones that you have to wait for.  Still, this would only explain ~90 msec, not 1-2 sec.

Oh wait -- here's part of it:  I just looked up the 4302 to find that it's a Delta-Sigma device with an inherent filter delay.   According to the specs (especially page 7), you can expect a ~58 sample delay when you sample at 100 Hz.   Granted, that's still not a full second worth, but it's getting us in the ballpark.

-Kevin P

[LVUser94]

Kevin_Price, you got it!

I think the Delta Sigma ADC delay is what I am seeing! It does account for 582ms delay, and my 1 second measurement is not exact by any means (just a feel).

By reading the manual closely it seems that the digital filter delay is specified in # of Samples (i.e., not a fixed time value like 50 ms for example)

So the delay can be reduced by just increasing the scan rate. If i increased the scan rate from 100 Hz to 1000 Hz, I can potentially reduce the delay by a factor of 10.

Thanks very much for your insightful answer!

[LVUser94]

I set the Scan Rate to 2000 Hz. That took care of the latency (or minimized it to unnoticeable levels).

Thank you Kevin Price!