align AI with continuous AO driver by counter

[afmstm]

I am using VB6 with the C API for NIDAQmx.  Hardware is a USB-6212 but will be running on PCI hardware too.

I have a continuous AO task running.  It uses Ctr0 as the clock.  It generates a sine wave of about 150 Hz.

I have a continuous AI task that runs occasionally.  (Most of the time actually).  It is also clocked off Ctr0.

I need to align (synchronize) the AI with the AO.  This is equivalent to adjusting the phase between them.   I can do this at startup by starting AO first, then AI, and then last of all starting the Ctr0 task. Works great.  However, if I ever stop AI (which I have to do from time to time to adjust the number of points per AI read), then they become out of synch and I am never able to get them back in synch.

I tried stopping the AI task, then reading the current write position in a fast loop using DAQmxGetWriteTotalSampPerChanGenerated or DAQmxGetCOCount.  I can wait until the value of either one is zero (modulo the number of points per cycle) and then restart the AI task.  Of course, it seems to be too slow so the results are random.

Any advice appreciated!

Van

[Starla_T.]

Hi afmstm,

Have you taken a look at the shipping example in VB?  You can find the shipping examples on your computer by going to Start>>All Programs>>Nationa Instruments>>NI-DAQ>>Text-Based Code Support.   There are some very handy examples in the folder that should help you achieve what you are looking to do. 

Best Regards!

Starla T. 

[afmstm]

Yes, I have looked and not found anything that tells me how to make this alignment.  As I said, I tried what seemed like the right approach, of monitoring the current write position and then waiting until it reaches the correct point before starting the AI, but this did not work.  Too much randomness in the execution time and the time taken to communicate across the USB.

Any pointers would be helpful. 

Van

[Jake_H]

Would a retriggerable AI acquisition work for your application? There were some synchronization examples in the above folder that you may have to modify to become retriggerable. The link below discusses how this process works. 

http://digital.ni.com/public.nsf/allkb/82DAECADE90CC56F8625659200675B2A?OpenDocument

[afmstm]

Hi,

I've reviewed the example code and have not found a solution to my problem.  I also don't see how a retriggerable method would help - most of the time I want to collect all data. 

It would seem some kind of "hardware trigger" is needed to restart the AI at the exact moment the AO reaches the start of its output buffer.  Is this what you are suggesting with a retriggerable AI?  What is the trigger I could use?

Any suggestions would be greatly appreciated.  This is driving me nuts :-)....

Van

[Jake_H]

Hello Van,

The specifications for the USB-6212 show that the device only supports software triggering, so setting up a hardware trigger will not be possible on that device. Some software triggering options are available but you will probably see the randomness in execution time that you were referring to in your earlier post.  

[afmstm]

Hi Jake,

Can you tell me if you think this approach is feasible:

1. Set up the AO task to generate a continuous waveform output of size N samps per channel.  Use the /dev/AO/SampleClock as the timebase.
2. Set up the Ctr0 task to generate a continuous waveform output consisting of a high pulse of width two clock counts with N-2 low clock counts.  Use the /dev/AO/SampleClock as the timebase.
3. Set up the AI channel to read N samples each time a trigger signal is received, using the /dev/AO/SampleClock as its timebase, and setting the start trig to retriggerable.  Then, route the output of Ctr0 to the trigger of the AI task. 
4.  Handle the data in the EveryNSamples callback.

I am assuming that if I stop the AO task, that the counter will be reset when the AO is started again.  That means the counter and AO should always be in synch.

Thanks

Van

[Jake_H]

Hi Van,

The logic sounds solid but I would be concerned about some of the hardware limitations of the 6212. In step 3, you may have trouble setting the "retriggerable" property on that board. I would make sure that was working first and then work on the rest of your application.