synchronized continuous AI and AO with DAQmx Base and E series card, LabVIEW 8.0 Mac OS X

[anant0716]

Is it possible to synchronize the following two continuous tasks with DAQmx Base and LabVIEW on an E series card? 

AO task: continuous periodic waveform

AI task: read several thousand samples per period of AO waveform

The two tasks are not operating at the same clock rates, the AI task is faster.  I just need each AI sampling operation to begin at the same point on the AO waveform.  The AI samples will be clocked in within one AO waveform period.  I started with the example code  daqmxbase_triggersync_ai_ao.zip but have not been able to modify it to make it work for continuous AI.

Thanks for the help.

[John_P1]

Hi anant,

It should be possible to synchronize your tasks using DAQmx Base.  It is ok that the tasks are not running at the same rate--since they are on the same device the clocks are derived from the same Master Timebase and you would only need to share a common trigger between them to ensure they start at the same time.

I have posted the following example on the Developer Zone Community that should provide a good starting point:  Synchronize Continuous Analog Input/Output with DAQmx Base.  Let me know if you have any questions about it or run into any issues getting it to work.  Thanks for posting and have a great day!

-John 

[anant0716]

John,

I tried the solution you provided, but unfortunately it did not work.  I believe the problem is the read operation inside the while loop.  It is not synchronized to anything, so each set of 1000 samples is being read at an arbitrary point in time with respect to the AO waveform.  Any ideas on how to deal with this?

Incidentally, the trigger VI didn't seem to like the syntax /Dev1/ao/StartTrigger as a trigger source, so I exported the AO start trigger to RTSI6 and that worked fine.

Thanks...

[JoeFriedchicken]

One clarification I'd like to make about programming in DAQmx Base is that, unlike DAQmx, DAQmx Base is not multithread safe [1]. That means a program will have race conditions if there are two parallel DAQmx Base tasks and as a result, the device may be configured improperly or incompletely. When programming in LabVIEW, chain all of the DAQmx Base VIs with a single error cluster wire. While parallel calls cannot be made to the driver, this does not prevent simultaneous tasks from running as intended on a DAQ device.

[1] DAQmx Base Readme::Known Issues

http://ftp.ni.com/support/softlib/multifunction_daq/nidaqmxbase/3.2/Windows%20Mobile-CE-XP-Vista/rea...

[John_P1]

Hi anant,

You are correct that the call to DAQmx Read is not synchronized to your hardware.  By definition, the DAQmx read is software-dependent.  However, the data you are reading from your DAQmx Read is based off of your hardware-timed sample clock.  The 1000 samples read is not arbitrary, it is simply the first 1000 samples acquired based on your hardware-timed sample clock.  The second time DAQmx Read is called, it will return samples #1001-2000.  Each subsequent call to DAQmx Read will return the next 1000 samples acquired.  The sample clock is what is synchronized between your tasks.

There is both an on-board FIFO and a buffer in your computer's memory that stores the data until it is retrieved by the DAQmx Read call.  Since this sample clock is started at the same time as your other task (the two tasks share the same trigger), and is based off of the same reference clock, the two tasks will be synchronized.

Joe's warning is still true, but I think the problem here is realizing that it takes time to transfer the data from your card to LabVIEW memory and thus there will be a delay between when you see the data change in LabVIEW and when you adjust your output.  However, all samples should be accounted for, and if you were to log the data to a file you would be able to make sure that the analog input and output are synchronized.

Sorry about the StartTrigger syntax, are you using multiple devices or just a single board?

-John 

[anant0716]

John, thanks for the clarification.  I was afraid that I was losing/skipping samples somehow because the reads weren't synced.  But now my problem is trying to figure out the correct sampling rate for the AI task and/or the number of samples per read so that the reads can be software synchronized to the AO waveform.  I can play with the # samples/read in real time but so far can't get my AI signal to stop "walking".  Any thoughts?

Both AO and AI tasks are on the same card.  But I do have a second E series card installed which isn't being used.  Could that explain the error with the StartTrigger syntax?

[John_P1]

Hi anant,

You should be able to set the number of samples to read to be equal to the number of samples in the period of your generated signal to eliminate the "walking".  If this is not the case, could you let me know the following parameters of your application:

1.  What is the Frequency of your output sine wave?  How many samples per period are you generating, and what is the output sample rate?
2.  What is the sample rate on your analog input?  Also, what is the number of samples parameter that you are reading per DAQmx Read call?

Also, could you attach the most recent version of your code that you are using?  I'd like to be able to take a look at the exact code that you are referencing.  We should be able to get this work for you once everything is configured correctly.  Thanks for the update, I look forward to hearing back from you soon!

-John