AI DAQmx read continuous samples read most recent

[Coherent_L]

Hi everyone,

I’m working on an analog acquisition task where I continuously read out samples after switching between multiple PCBA boards.

Here’s my setup:

• Sample rate: 100 kS/s

• Each readout: 100 samples

• Before each readout, I use digital output lines to select the target PCBA board (address lines).

• After switching, I insert a 20 ms delay to ensure the board output is stable before reading.

To test this, I alternately switch between two boards:

• Board 1: ~3.9 V output

• Board 2: ~3.2 V output

However, the results show it has error, but if i change the delay into 50 ms, it works

So it seems the readout order is misaligned.

I’m using continuous sampling mode to avoid repeatedly calling Start and Stop, but it appears difficult to control exactly which samples are read from the buffer. I’m not fully clear on how the buffering works — does DAQmx keep reading until the PC-side buffer is full? How large is this buffer by default?

At a 100 kS/s sampling rate, the buffer fills very quickly, and after a 20 ms delay there should already be plenty of new data — theoretically enough to read only the most recent 100 samples. However, in practice this doesn’t seem to work as expected, and the readout doesn’t always align with the timing of the board switching.

[wsimpson0050]

I made some edits to your VI, try it. I believe there might be a problem with the "stall data flow.VI". I believe the reason for your misalignment is in the part where it reads from the buffer, it is set to read a certain number of elements from the buffer at a time.

Example of elements in buffer when "stall" happens (should be an even number of samples):

ch1

ch2

ch1

ch2

ch1 <---- misalignment (total # of samples = 5)

after the stall and on the next cycle you end reading 

ch2

ch1

ch2

ch1

[Coherent_L]

Hi Thank you for your reply, I noticed you delete the "stall"

But I need some delay like a 1 ms delay, to make sure the address selection is stable then to read out the latest volts using AI. Do you have some ideas on that?

[crossrulz]

Seems like you should not be using the Continuous Samples mode. Change your timing to be Finite Samples. Then when you do a read, it starts the acquisition.

[Coherent_L]

Also, first of all — I ran the VI you shared, but it threw an error as shown in the first picture.

Second, I’ve encountered the same error before. It seems to occur because there isn’t enough offset available for the initial readout, according to the discussion in the link below. Following the suggestion in that post, I tried adding an overwrite with an initial offset of 0 before the first readout, as the post recommended. The idea is that when there aren’t enough samples to apply an offset, the offset should be set to 0.

After the first loop iteration, I set the offset to -100. However, the results I obtained seem misaligned:

The first value is 3.2,

The second through eleventh values are all 3.9,

And the twelfth through fifteenth values are all 3.2.

I’m quite confused about how the readout mechanism works with the buffer and how the offset impacts it.

Reference:
NI Forum Discussion – Error 200277: Invalid combination of position and offset in DAQ Read

 https://forums.ni.com/t5/LabVIEW/Error-200277-Invalid-combination-of-position-and-offset-in-Daq/td-p...

[Coherent_L]

Thank you for your reply, I also just run your code, but it has another error.

Error code: -200278
Message: Attempted to read samples that are no longer available — The requested sample was previously available, but has since been overwritten.

[Coherent_L]

Oh, by the way, when I run the VI in debug (highlight execution) mode, only the first loop iteration returns valid data — in the following loops, the readout is zero.
I believe this happens because the task is configured to acquire only 100 samples.
If I want to use finite sampling, I have to start and stop the task inside the loop. I’ve tried this approach before — it works, but it’s quite slow, since starting the task takes about 20 ms and stopping it takes around 7 ms.

[Kevin_Price]

Lots of comments & questions here in no particular order.

1. I don't see an obvious problem in the original screencap.  Are you sure you're using a device capable of sampling 16 channels at 100 kHz *EACH*?   This question is inspired by your remark about "working" with a 50 msec delay rather than a 20 msec delay.

2. You make reference to "misalignment".  What exactly do you mean by that?

3. The suggestion from crossrulz to use finite sampling is a simpler approach conceptually.  I can't experiment on hw now, but try his code after *removing* the AI task call to DAQmx Start before the loop.  Then each call to DAQmx Read in the loop might auto-start a distinct finite acquisition.  I think that's what he was going for.

4. What exactly are your requirements around timing from digital write to dataset to be collected?  I ask because you are combining the imprecise and variable software timing of "Stall Data Flow" with the much more precise and repeatable timing of your DAQ device's sample clock.  If you need precise and *repeatable* timing from digital write to AI capture, you would need careful hardware level sync between your Digital and AI task.

5. What DAQ device are you using?  (I ask because some devices won't support the timing sync referenced in #4).

6. To follow my example you linked to, your code in msg #5 should read 100 AI samples *before* the loop (while offset is 0)  to preload the buffer.

7. I'd highly recommend simplifying your acquisition as part of troubleshooting.  You're accumulating a 3D array and it can be tricky to be sure you're indexing into it correctly for the data subsets you're interpreting.  Do a 1 channel AI acquisition, read a 1D array, and accumulate a 2D array instead -- that's much more straightforward to display and interpret.

-Kevin P