Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx default sample clock timing

Solved!
Go to solution

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?

0 Kudos
Message 1 of 6
(1,721 Views)

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.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 6
(1,709 Views)

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.

0 Kudos
Message 3 of 6
(1,704 Views)

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.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 4 of 6
(1,695 Views)
Solution
Accepted by topic author colinhogben

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

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 5 of 6
(1,684 Views)

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).

0 Kudos
Message 6 of 6
(1,577 Views)