DAQmx's DAQmxReadAnalogScalarF64 takes long time to execute

[Dhanakorn]

Hello,

Currently, we are using NI PCI-6259 (M-series) for data acquisition with DAQmx driver (8.0) on Linux system.

I use the function DAQmxWriteAnalogScalarF64 to read in one sample from analog channel. Apparently, this function takes about 20usec to process before it returns back.

20usec is too long for just reading in one sample – a few microseconds are what I expect.

In addition, the counter reading function DAQmxReadCounterScalarU32 also takes about 30usec – which is much longer than I anticipate.

Please find my code snippet in attached file. Please let me know if you need more information.

Thank you very much,

Dhanakorn

Message Edited by Dhanakorn on 09-15-2008 12:51 PM

[Brooks_C]

Hello Dhanakorn,

The 20 usec you're seeing is essentially the overhead associated with any read.  The PCI-6259 is able to read at rates up to 1.25 Msamples/sec, but this is achieved by reading many samples at a time.  While it may take 20 usec to read 1 sample on your system is may only take 200 usec to read 100,000 samples (once they are available).  These numbers are system dependent, but the point is that it is much more efficient to make fewer reads for more samples than vice versa.  With a single point read most modern computers can sustain sample rates of several kHz, however, if you read 125,000 samples each read you can easily support the full sample rate.

In you're code you will need to configure an analog input sample clock using this function:

DAQmxCfgSampClkTiming

int32 DAQmxCfgSampClkTiming (TaskHandle taskHandle, const char source[], float64 rate, int32 activeEdge, int32 sampleMode, uInt64 sampsPerChanToAcquire);

For more information look at the DAQmx C Reference Help, or open up some of the analog input examples here:  /usr/local/natinst/NI-DAQ/Examples/DAQmx ANSI C/Analog In/Measure Voltage/Acq-Int Clk

That example in particular will show you how to program a buffered acquisition with a sample clock.

I hope this helps and have a great day!

Cheers,

[Jonathan_Brumley]

Regarding the overhead for a single DAQmx read/write call:

The performance you are getting is pretty reasonable for Linux, which is not a real-time OS.  You said you are expecting a few microseconds per read.  You could certainly get that kind of performance if there were no software overhead or if you amortized the read overhead by using a buffered acquisition or generation.  However, Linux is a dual mode OS  - most of the read overhead you are seeing is due to the mode transition to the DAQmx driver in the Linux kernel.  Kernel transition time varies from system to system, but 10 to 15 microseconds of overhead due to the kernel transition would be pretty typical.  DAQmx adds some additional overhead because it needs to figure out what type of task you are using, what type of hardware you are using, and what state the task is in so that it can switch to the right code path.  In addition, DAQmx adds a little overhead to protect the task from multi-threaded access.

Regarding counter tasks - counter reads are more expensive than analog reads because accessing the hardware is more complicated.

BTW, as far as single point read/write performance, DAQmx performs best on LabVIEW ETS system.  ETS is a single-mode real-time OS, so there is no overhead due to the kernel transition.  Using LabVIEW ETS, I can consistently able to get between 3 and 10 microseconds per read/write using my old 8176 PXI system here at the lab.  (the variation depends on which data acquisition card and which I/O type).