DAQmx default sample clock timing

[colinhogben]

When joining a project using the NIDAQmx C library, I found that my colleague had implemented the acquisition with the following sequence:

DAQmxCreateTask
DAQmxCreateAIVoltageChan...
DAQmxStartTask
DAQmxReadAnalogF64...

but without any call to DAQmxCfgSampClkTiming

Surprisingly (to me), this all worked, with data seemingly arriving at 1kHz, which is what the application required. I'm guessing there is some default timing being applied, probably using an internal clock, but I didn't find this behaviour documented. Can anyone shed some light on this?

[santo_13]

If you don't configure DAQmx Timing, it means the device is operated at Software timed, in other words, the hardware does not handle timing between samples. The software must send the samples to the hardware at the right time interval.

[colinhogben]

In this case it's analogue input channels, i.e. samples being read from the hardware.  Our application is just waiting for samples to become available; something in the NI software must be clocking them out.

[santo_13]

Then it is the (ADC) conversion time you're looking for and not the sample clock. There is a DAQmx property that stores the conversion time.

For software timed tasks, an ADC conversion is initiated every time you request a sample.

A sample clock is used to define how often the ADC/DAC conversion is initiated.

[Kevin_Price · Accepted solution]

---

DAQmxCreateTask
DAQmxCreateAIVoltageChan...
DAQmxStartTask
DAQmxReadAnalogF64...

but without any call to DAQmxCfgSampClkTiming

---

With that sequence of calls, there is no clocking and no buffering.  The task is in "on-demand" mode where a call to DAQmx Read initiates capture of a single sample that is then returned.  Time between samples is entirely up to your software (plus the little bit of overhead time involved in the read call itself).

If your app depends on acquisition at a *consistent* 1 kHz sample rate, the task should indeed call DAQmxCfgSampClkTiming.  And then your call to DAQmx Read should retrieve multiple samples at a time -- a typical starting point is about 1/10 sec worth, so 100 samples per read.

-Kevin P

[colinhogben]

Just to tie up a loose end, it turned out that the application was sleeping for 90ms, reading out 100 samples, then hoping that other overhead (network etc.) would be sufficient to make up to 100ms cycle time.  (Sigh).