Synchronizing Two AI or Two AO on the same device using NIDAQmx

[lkorbel]

I am using the NIDAQmx C API and I would like to synchronize two AI reads as well as two AO writes in an attempt to speed things up, rather than do two concurrent reads on “Dev1/ai0” and “Dev1/ai1” and then two concurrent writes on “Dev1/ao0” and Dev1/ao1.” Similar to threading, I would hope that this would halve the time it takes to do these operations when they are synchronized. There are two example synchronization programs that are included with the NIDAQmx driver. One of them synchronizes an analog input with a digital input (ContAI-ReadDigChan.c), and the other synchronizes an analog input with an analog output (SynchAI-AO.c). In the case of the former, the “ai/SampleClock” is used as the source terminal, and in the case of the latter, the “ai/StartTrigger” is used. The choice here seems to be the issue that I am having. I am attempting to use the ContAI-ReadDigChan.c program as my template to show a proof of concept. When I change the digital input to another analog input, the program fails with the following error:

DAQmx Error: An attempt has been made to perform a route when the source and the destination are the same terminal.

In many cases, such as when configuring an external clock or a counter source, you must select a PFI, PXI Trigger, or RTSI line as the source terminal.

Property: DAQmx_SampClk_Src

Property: DAQmx_SampClk_ActiveEdge

Source Device: Dev1

Source Terminal: ai/SampleClock

The function GetTerminalNameWithDevPrefix() does not appear at all in the NIDAQmx.h header file, so I am not sure what the available options are? Do I use another internal or onboard clock? Do I use an external clock? If either of those are the case, how exactly is that implemented using the NIDAQmx C API?

Several attempts at using something else resulted in different errors. One was:

DAQmx Error: Specified route cannot be satisfied, because the hardware does not support it.

And another was:

DAQmx Error: Source terminal to be routed could not be found on the device.

Make sure the terminal name is valid for the specified device. Refer to Measurement & Automation Explorer for valid terminal names.

What is the Measurement & Automation Explorer and where do I find it?

I also tried to find example programs online to no avail. I am not exactly a master of understanding all of the nuances of how these DAQ cards work, so any pointers in how to implement this would be greatly appreciated. If a different terminal needs to be used to synchronize two AO together than is needed to synchronize two AI, knowing what to use in that case would also be extremely helpful. Thank you for your time.

[ZYOng]

To access NI Measurement and Automation Explorer, search for NI MAX.

What's the model of your hardware?

You can synchronize two AI channels with Channel Expansion. To synchronize AI and AO, you would need to share the timing. C:\Users\Public\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Synchronization\Multi-Function\Synch AI-AO is a good starting point.

[Kevin_Price]

A couple very general things about the DAQmx driver and NI hardware (because I don't know the C syntax enough to be any particular help).

For most of NI's common DAQ devices, you should plan to have just 1 AI task that includes all AI channels of interest and 1 AO task that includes all AO channels in use.  It sounded like you tried to put 1 AI channel each into 2 distinct tasks and then have 1 task drive the other.   All you would need to do is put both AI channels into the first task.

As to sync between AI and AO -- I personally like to use the shared sample clock method ("/Dev1/ai/SampleClock") if you want to run both tasks at the same sample rate anyway.  The sample clock method even works across different devices.

If you're using devices that support the channel expansion feature that ZYOng brought up, that's an even easier way to accomplish sync of multiple devices dealing with the same kind of I/O.  (Meaning, this could help you sync AI on 3 different devices, but not a combo of AI and AO).

A trigger is sufficient for syncing tasks on the same device, and many times also across different modules in the same cDAQ chassis.  It's especially useful for tasks running at different sample rates.  The downside is that sync is only established at one point in time.  Different devices can slowly drift out of sync when they have independent sample clocks.  A common point of reference I keep in mind is that many NI DAQ boards are spec'ed to allow as much drift as 3 msec per minute of acquisition time.

-Kevin P

[lkorbel]

The hardware that I am using is the PCIe-6259 DAQ. For now I am only trying to sync AI and AO on the same device, but could be interested in syncing multiple devices further down the road.

[lkorbel]

If both of the AI and AO are each in a single tasks, will the board read from and write to each of those concurrently or sequentially? The goal is the former here, and I would have suspected that each of the reads (In the case of AI) would not be performed concurrently when they are both in the same task?

[Kevin_Price]

On your device:

• Two AO channels in the same task will output their new samples simultaneously.
• Two AI channels in the same task will sample their new input values *almost* simultaneously.  For example, if you sample at 10 kHz, you'd have a sample interval of 100 usec.  Both channels would be sampled within each 100 usec interval.  They'd be no more than 50 usec apart.  That's pretty close to simultaneous for an awful lot of common use cases.

Also of note: this time separation can be controlled through DAQmx properties for the "convert clock", which controls the rate of multiplexing across channels in a task to get all the conversions done within 1 sample interval.  The default behavior is to use the slowest rate that gets through all the channels in time.  This also minimizes the influence of one channel's voltage on the next channel, a phenomenon often referred to as "ghosting".

    You *can* set the convert clock to a much higher rate to make the channels get converted more nearly simultaneously.  But you risk seeing more influence of the 1st channel onto the 2nd, especially if your signal sources are of relatively high impedance.   Here's some more info on ghosting. 

-Kevin P