Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronizing two separate tasks sharing the same time base. ? DAQmxTaskControl ? Reserve

My question(s) are fully detailed at the following web page
 http://web.ujf-grenoble.fr/PHY/intra/perso/lpuech/MQt/NI-DAQ-PCI6259/synchro-AI-with-AO.php

Problem:
Synchronizing two different tasks (one for AOs, one for AI), or at least having a stable delay between the start of these two tasks.
The program below works fine but there is some unacceptable Jitter between the triggering of the tasks.

20|//These tow steps were taken to attempt to reduce the (random) delay between the starts: 

22|DAQmxTaskControl (taskIN, DAQmx_Val_Task_Reserve );//reserve needed ressources for a quickstart

24|DAQmxTaskControl (taskOUT, DAQmx_Val_Task_Reserve );//reserve needed ressources for a quickstart


27|//The calls have some delay ( about 1000 mu secs!), that induces jitter between taskOUT and taskIN.

29| DAQmxStartTask(taskIN);

32| DAQmxStartTask(taskOUT);

There are two other questions concerning
    -DAC synchronization in a single task.
    -RegisterDoneEvent int DAQmxBase




0 Kudos
Message 1 of 4
(3,405 Views)

I really only program in LabVIEW, but *think* I was able to follow your C-code calls.  I'm pretty sure your problem should be a fairly simple one to resolve.  The jitter is simply because the clocks for your tasks each start based on the timing of the software calls.  There are better ways to sync the tasks.

1. Share a sample clock.  In your calls to configure DAQmx Timing, tell the AI task to use the AO sample clock.  Then start the AI task before the AO task so that the AI will react to the very first AO clock.    This example should help to illustrate.  This is usually the best method.

2. Share a trigger.  Here's an example.  This method should be fine when using the same board for AI and AO since both tasks will derive their internal sample clocks from the same board timebase.  It can give timing problems when the AI and AO are on different boards due to timebase tolerances, especially for long-lasting tasks.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 4
(3,397 Views)
Thank you Kevin.

DAQmxCfgSampClkTiming (taskIN, "Dev1/ao/SampleClock", 1000.0/time_step, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, steps_inperiod*period_number);

effectively solves my problem of Jitter, and I am quite confident that the two (alias three!) sampling rates are exactly the same : 2 Aos, 1 AI.

I do not really understand how it can work because  I do not specify which /ao/SampleClock to use.
What would happen if I had two processes with Aos,  running with the same board ?


Kevin Price a écrit:

I really only program in LabVIEW, but *think* I was able to follow your C-code calls.  I'm pretty sure your problem should be a fairly simple one to resolve.  The jitter is simply because the clocks for your tasks each start based on the timing of the software calls.  There are better ways to sync the tasks.

1. Share a sample clock.  In your calls to configure DAQmx Timing, tell the AI task to use the AO sample clock.  Then start the AI task before the AO task so that the AI will react to the very first AO clock.    This example should help to illustrate.  This is usually the best method.






0 Kudos
Message 3 of 4
(3,382 Views)


I do not really understand how it can work because  I do not specify which /ao/SampleClock to use.
What would happen if I had two processes with AOs,  running with the same board ?

In short, the board wouldn't let you run two AO tasks that use sample clocks.  If you use a sample clock for your AO, all your AO channels must belong to one AO task (just as you already did).   Same is true for AI.

For AO, the multiple channels are converted simultaneously with independent D->A converters.  For AI, most common NI boards multiplex the channels sequentially to a shared A->D converter, including all M-series boards like the one you have.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 4
(3,378 Views)