Several DAQmx calls and counter reading

[PaskalM]

I have an experimental setup with a load cell that provides an analog output and an encoder to measure the position of my motor. Both are connected to my DAQ card.

I need to acquire data at a high frequency (>10 kHz).

I am having trouble understanding how the readings work, as I need to make two separate DAQmx calls: one for the analog data from the load cell and one for the counter from the encoder.

I know it is better to read multiple samples at once, but I’m concerned that if I do this, the data from the load cell and the encoder will be out of sync. This is because N samples from the load cell would be read before N samples from the encoder (or vice versa, but in my understanding, they are not read at the same time).

To address this issue, I thought the best solution would be to read one sample at a time, ensuring that both data sets are synchronized. Is this understanding correct?

However, my biggest concern is with the counter reading. In the past, I read one value at a time and encountered unexpected jumps in the position data from the encoder, which I suspect were related to the FIFO of the counter.

This is the part I’m really unsure about. When I read 127 samples at once (since my counter FIFO can handle 127 samples per counter), the position data becomes linear and free from jumps, which looks good. But how can I be 100% sure that the last value in the 127 samples is the most recent count from my counter? I’ve tried reading more samples, but the counter still returns the N values I requested, with the encoder pulse value constantly increasing.

I just need to read the most recent value stored in the counter’s memory. I don’t understand why this seems so complex.

[santo_13]

Checkout this example - https://forums.ni.com/t5/Example-Code/Synchronous-Analog-and-Encoder-Inputs/ta-p/3996087

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kJt7SAE&l=en-US

[Kevin_Price]

You have some misconceptions.  Understandable ones, but misconceptions nonetheless.

Your calls to DAQmx Read are *not* limited by the FIFO size.  You're reading from a separate task buffer held in PC memory which can be very much larger (like 100's of MB when needed).  The device and the DAQmx driver work in the background to get data out of the FIFO and into the task buffer for you.  Your app-level program NEVER deals with the FIFO directly.

Reading 1 sample at a time would be a very bad idea, especially when sampling at >10 kHz.  A typical recommendation is to read about 1/10 sec worth of data per call, so something > 1000 samples per read.

Once you set up your task's clocks (and sometimes also triggers, though not necessary here) properly to make sure *sampling* happens in sync, then you just need to read the same # samples from both tasks each loop iteration and that'll make sure that corresponding samples will be in sync.  (The example that Santhosh linked probably does this correctly -- I can't personally vouch for it % though because the screencap there was illegible and I don't have LV available to look at code.)

The main way to be sure that your multi-sample reads give you the very most recent measurement data is to keep your DAQ loop really lean and do basically nothing other than read N samples per iteration and deliver it off to a processing loop using a producer / consumer approach.  That puts DAQmx in charge of  your loop timing where it'll wait for N new samples to be pushed into the task buffer, then immediately return them to you.  Then you start the next iteration and wait for the next N samples.  And so on.  Just make sure N is large enough that you can keep up with the data acq tasks.  N=1 won't be large enough at > 10 kHz.  N = sample rate / 10 easily will be.

-Kevin P