Hi Giovanni,
Let me start by explaining the timing signals that I think you need to be concerned about, and how these will affect what you are attempting to do. Here are the relevant signals:
AI Sample Clock: For devices such as the USB-6251 which have 1 ADC, this clock will be used to start the clock which will actually acquire data from all of your channels. This clock occurs at the 'rate' you set in DAQmxCfgSampClkTiming.
AI Convert Clock: This clock controls when each individual channel is sampled. After a sample clock occurs, hardware will wait DelayFromSampClk time, then issue a clock pulse for each channel in your task at the rate specified by AIConvertRate (setting I'd mentioned in my previous post). The rate of this clock will dictate your inner-channel delay.
AI Start Trigger: When this signal asserts, you hardware will wait StartTrigDelay then issue your first sample clock. All subsequent sample clocks will follow at the rate you specified when you configured timing.
What you end up with is something that looks like this (hopefully the formatting of this ASCII art doesn't get too messy):
AI Start __n_______________________________________________________.....
AI Sample Clock: ___n__________________n__________________n________________.....
AI Convert Clock: ____n___n___n__________n___n___n___________n___n___n_______.....
ai0 ai1 ai2 ai0 ai1 ai2 ai0 ai1 ai2
The AO signals we need to concern ourselves with are as follows:
AO Start Trigger: Much like AI Start Trigger, this signal is used to start the clock which updates any of the channels in your AO task.
AO Sample Clock: The clock which actually updates the DACs on your AO channels. Note that each channel has it's own DAC, so all channels are updated simultaneously.
Now, since AO doesn't have this concept of a convert clock, if we synchronize sample clocks on AI and AO, AO will update it's value when the sample clock occurs. If we take noise/slew rate out of the picture, your AO channel would hold this value until the next sample clock. While this was being held, your AI task would then scan through it's channels (at rate specified by your convert clock rate). However, since AO is being held, all channels should read back the same value. In reality, things like the slew rate of your AO channel may dictate that your first AI channel reads the AO value before it has completed it's transition to its new value. Noise will dictate that its very unlikely that all three of your AI channels actually read back the exact same value, but the difference may not be due to inner-channel delay.
In my mind, the only way to measure the time between the conversion of two channels, you would have to measure a signal that changes between these conversions such that you could observe some phase difference. I think that sharing a start trigger between AI and AO, and perhaps using DAQmxSetStartTrigDelay to control the relationship of sample clocks used for AI and AO is a good idea. However, I still think that to measure inner-channel delay, you'll need for your AO channel to be updated at a higher rate than your AI Convert Clock Rate.
I hope that helps explain things. If I've misunderstood what you're attempting to do, please let me know.
Dan
