DAQmxCfgSampClkTiming sample rate for external sources

[dmorris]

I'm looking at the Synchronized_AIAO_Shared_Clock.c example at http://zone.ni.com/devzone/cda/epd/p/id/2352 .  This example creates an AI voltage channel that streams at 10kHz, then creates an AO voltage channel that's tied to the AI sample clock in order to synchronize the channels.  I'm using this example to understand the use of DAQmxCfgSampClkTiming here.  This is the relevant code (comments are mine):

// Create an AI voltage channel that will run continuously at 10kHz

DAQmxErrChk (DAQmxCreateTask("",&taskHandleRead));

DAQmxErrChk (DAQmxCreateAIVoltageChan(taskHandleRead,"Dev7/ai1","",DAQmx_Val_Cfg_Default,-10.0,10.0,DAQmx_Val_Volts,NULL));

DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandleRead,"",10000.0,DAQmx_Val_Rising,DAQmx_Val_ContSamps,1000));

// Create an AO voltage channel, then tie the AO voltage channel's clock to the AI sample clock
DAQmxErrChk (DAQmxCreateTask("",&taskHandleWrite));
DAQmxErrChk (DAQmxCreateAOVoltageChan(taskHandleWrite,"Dev7/ao0","",-10.0,10.0,DAQmx_Val_Volts,NULL));

DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandleWrite,"ai/SampleClock",1000.0,DAQmx_Val_Rising,DAQmx_Val_ContSamps,1000));

...so what I'm trying to understand here is how to interpret the sample rate argument (1000.0) in the second call to DAQmxCfgSampClkTiming, where the AO channel is tied to "ai/sampleClock".  It seems to me that this argument shoud be meaningless, other than maybe in determining the buffer size, since by definition this AO channel is going to clock out a sample whenever ai/SampleClock rises.  So maybe someone can help me understand how this argument is used...

But in any case, the docs say "If you use an external source for the Sample Clock, set this value to the maximum expected rate of that clock."  In this case, the clock is configured a few lines earlier to 10kHz, so isn't it "wrong" that in the second call to DAQmxCfgSampClkTiming, a sample rate of 1kHz is specified (clearly less than the maximum expected sample rate)?  What's the consequence of this?

Thanks!

-Dan

[Nathan-M · Accepted solution]

Hey Dan, some great questions you've got. 

You pretty much hit the nail on the head with your guesses. The buffer size is based on the resolution of the DAQ in combination with the sample rate you specify. Think of it like an implicit declaration of the buffer size (though there certainly is an explicit way of defining that, if you'd like).

As for your second question, it relates again back to the buffer size, except this time it's for using an external clock source. Since the hardware has no implicit way of knowing the clock rate of this external source, it asks you to specify the maximum frequency explicitly so it can create a buffer size of the right scale. 

[JÞB]

You could write a quick test to determine if the questionable call could cause an issue by reading the buffer size.  Although, in this case, you do not need too do so!!!  You have "Contineous sample" "sample mode" tasks.  When the sample mode is contineous samples the last parameter "Samples Per Channel" set the buffer size.  Both tasks have a 1000 sample buffer in your example- No problem!

[John_P1]

For output tasks the default buffer size is actually equal to the number of samples in the first call to DAQmx Write (see here).

Continuous input tasks use a number based on the rate (see the chart in my link above) OR the number of samples per channel to determine the default buffer size (whichever number is greater).

You may override the default buffer setting explicitly by calling DAQmxCfgInputBuffer or DAQmxCfgOutputBuffer.

So, the rate input doesn't really do anything with regards to buffering in the case that you posted.  There's no reason to not set it to the maximum expected rate of 10 kHz so I would just do that for consistency.  The author of the program you linked either didn't notice the rate was set to 1 kHz (since the program wouldn't behave differently) or didn't care (again, since the program wouldn't behave differently).

Best Regards,