AI/AO sync: clock edges and expected behavior

[dmorris]

I am writing out data with an analog output channel on a USB-6216, and reading it back with an analog input.  I'm doing this to verify my control signal, and I'm using the read-back value as a definitive way to know what the control signal was as I'm reading other analog inputs that depend on this control signal.

I'm using the approach suggested in this example:

http://zone.ni.com/devzone/cda/epd/p/id/2352

Specifically:

1) Create the ai task (let's say it's 10kHz)

2) Configure the sample timing for the ai task using "" as the "source" parameter to DAQmxCfgSampClkTiming (i.e., the on-board clock), using DAQmx_Val_Rising as the active edge

3) Create the ao task

4) Configure the sample for the ao task using "ai/SampleClock" as the "source" parameter, and sample rate of 10kHz (same as ai), using DAQmx_Val_Rising as the active edge.  The sample rate, as per another thread I posted, is not particularly meaningful here, since it's going to be triggered at the ai/SampleClock rate anyway.

5) Start the ao task (which doesn't really start yet, because it's waiting for the ai sample clock to run)

6) Start the ai task (which actually starts both tasks)

I'm changing the output value quickly, and I care about sample-level timing.  Having ai and ao triggered on exactly the same clock is slightly confusing here... does this mean that the ai task will be reading *exactly* as the ao task is writing, such that it's unclear whether it will be reading the "previous" or "current" samples?  Should I be using opposite clock edges for this sort of task if I want deterministic behavior?

Thanks!

-Dan

[dmorris]

And a related question: is there an assumption that a task starts with all sample clocks at zero?  I.e., that for "ai/sampleClock", the sequence of edges will always be rising/falling/rising/falling, and if a task ends with the clock high, it will return to zero before the next task starts?

[dmorris]

Actually never mind... I haven't fixed everything yet, but I've found several other threads that clarify all of this for me.  In particular my mental model that the duty cycle of the clock was around 50% was not accurate; the active edge is not what I should be playing with for the problems I was having that led to this thread.

No-op.

-Dan

[John_P1 · Accepted solution]

You can call DAQmxSetDelayFromSampClkDelay (department of redundancy department anyone?) to configure your analog input task to introduce a delay between the sample clock edge and the convert clock (which starts the analog-to-digital conversion).  This will allow time for the analog output to settle before it is measured by the analog input.

Best Regards,

[dmorris]

Indeed, that's exactly where I ended up.  You managed to reverse-engineer my problem from my ambiguous question. 🙂

Thanks!

-Dan