Reading multiple channels with DAQmxReadAnalogF64

[chandan]

Hi,

I'm acquiring a fixed number of samples from 2 analog channels like this:

...
DAQmxCreateAIVoltageChan(task, "/dev2/ai0:1', "foo", DAQmx_Val_RSE, minVoltage, maxVoltage, DAQmx_Val_Volt, NULL);
DAQmxCfgSampClkTIming(task, NULL, smpFrequency, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, nSamples);
// task is started here
DAQmxReadAnalogF64(task, nSamples, TIMEOUT, DAQmx_Val_GroupByChannel, buffer, nSamples*2, &gotSamples, NULL);

"buffer" is big enough to hold nSamples*2 samples.

If "gotSamples" is less than "nSamples" for whatever reason, where will the data acquired from the second channel
be in "buffer"? I'm guessing that the data acquired from the second channel starts at "buffer[nSamples]" and not at
"buffer[gotSamples]".

If one of you gurus out there confirm this, I'll greatly appreciate it.

Thanks,
Chandan

[Travis G.]

Hello Chandan,

I tried this out and it looks like the way the DAQmxReadAnalogF64 function works, if the number of samples actually acquired is less than the number of samples supposed to be acquired, all the data will be in the beginning of the array.  Therefore, with the fill mode set to DAQmx_Val_GroupByChannel, the data for the second channel will begin at 'buffer[gotsamples]''. 

I hope this helps,

Travis G.
Applications Engineering
National Instruments
www.ni.com/support

[chandan]

Thanks Travis.

Your observation appears a bit counter-intuitive unless DAQmxReadAnalogF64 moves the data around after it acquires it. My reasoning follows.

The analog channels are scanned in this sequence: ai0, ai1, ai0, ai1 and so on. So the sampled data coming out of the D/A converted should be in the same order and stored in the onboard buffer (FIFO?) in the same order. Since the driver wouldn't know what "gotSamples" is till it's done, it will not be able to place the first ai1 sample at buffer[gotSamples]. The simplest place to put it would be at buffer[nSamples]. After the acquisition is complete (with gotSamples) it could move the data from buffer[nSamples] to buffer[gotSamples], but why bother?

Maybe the DAQmx developers can shed more light on this?

Thanks again for the help.

Chandan

[Travis G.]

Hello Chandan,

I see your reasoning here, but let me see if I can articulate my counter point properly.  When you start your DAQ device acquiring data with the DAQmxStart function call, the driver takes care of moving acquired data into an onboard FIFO buffer on the card, and also moves data across the PCI bus into another buffer in your computer's memory.  This double buffered acquisition and transfer of data into system memory occurs completely behind the scenes by the driver.  Every time you call the DAQmxReadAnalogF64 function, what you are doing is pulling data from the buffer in your computer's memory into another 'application' memory space allocated when you initialize the readArray[ ] array in your programming environment.  This means that all the data pulled into your application's memory space with the DAQmxReadAnalogF64 is already in another location in memory.  Its not just being placed into this array one sample at a time as its acquired.  How I tested this out was to let the DAQmxReadAnalogF64 function timeout.  So what occurred was the DAQmxReadAnalogF64 function was waiting for the number of samples sitting in the intermediate memory space to reach what I specified in the 'numSampsPerChan' argument for that function.  When that number of samples was never acquired and the function timed out, it instead just grabbed all the available samples in that memory space and copied them into readArray[ ] according to the format specified by fillMode.

I hope this helps to shed some light onto why the function behaves like this and let me know if you have any further questions.

Regards,
Travis G.
Applications Engineering
National Instruments
www.ni.com/support

[chandan]

Hi Travis,

Thanks very much. Your explanation makes a lot of sense.

Chandan