Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the timing relationship between the input MUX and the convert clock in DAQmx

Solved!
Go to solution

Hi Aaron,

 

I have a simple test VI which enables me to view various clocks

 

test_timing_signalsd.jpg

 

I have four channels in the input scan list.  I am measuring four DC voltages with 1 megohm output impedance.  The high output impedance enables me to see when the input MUX is switching by observing the spike which occurs when the MUX switches from one voltage to another.  The discharge time for these spikes is consistent with the 100 pF input capacitance of the USB-6210.

 

The MUX switching does indeed occur when the hold complete signal occurs.  The hold complete for ai0 causes the MUX to switch to ai1.  The hold complete signal for ai3 causes the MUX to switch to ai0 and then waits for the next sample clock to occur.  Therefore the settling time for ai0 is the time from the hold complete signal for ai3 until the next sample clock.

 

The very first time this VI is run, the input MUX seems to switch to ai0 about 12 ms before the first sample clock occurs.

 

It seems that the DAQmx functions switch the MUX to the first channel before the first sample clock occurs.  Indeed, if I do a simple single channel on demand read (different VI) I observe, on the very first run, that the MUX switches to the channel about 12 ms before sample clock.  The MUX then seems to stay switched to the channel for subsequent runs.

 

Any comments would be interesting.

 

Thanks for your patience with me through all of this.

Cheers,

Neville

0 Kudos
Message 11 of 12
(916 Views)

Hi Neville,

 

You're correct, the MUX does switch to the first channel in the scan list before the first sample clock.  I believe this initialization occurs when the task is "committed".  If you are not explicitly committing your task, the task is implicitly committed as part of DAQmx Start.  If you'd like to explicitly commit your task, you may do so by calling DAQmx Control Task.vi.

 

The delay between committing the task and the first sample clock depends on software and is thus non-deterministic.  It is part of the DAQmx Task State Model which you can read more about in the DAQmx Help installed on your local system.  12 ms doesn't seem unreasonable, but this is completely system dependant.

 

 

2011-06-24_091951.png

 

 

Best Regards,

John Passiak
Message 12 of 12
(908 Views)