int AOCount = 2763;
double AORate = 2763*2;
double COFrequency = 1, CODutyCycle = 0.5;
DAQmxCfgSampClkTiming(taskHandleParam.AO_0,"", AORate, DAQmx_Val_Rising, DAQmx_Val_ContSamps, AOCount);
DAQmxWriteAnalogF64(taskHandleParam.AO_0, AOCount, 0, 10.0, DAQmx_Val_GroupByChannel, setCamParam.AOBuffer, NULL, NULL);
DAQmxCreateCOPulseChanFreq(taskHandleParam.CO_0, CO0_Ch, "", DAQmx_Val_Hz, DAQmx_Val_Low, 0.0, COFrequency, CODutyCycle);
DAQmxCfgImplicitTiming(taskHandleParam.CO_0, DAQmx_Val_ContSamps, 1);
- NI PCI 6711
- Analog output : 1Hz sawtooth wave
- Counter : 1Hz pulse train
- Analog output and counter start at the same time using "ao/StartTrigger".
Question: Two continuous signals start at the same time. As time goes on, two signals have lag. Analog output goes faster than counter even though two signals have the same frequency of 1Hz. Please let me know how to sync two signals.
Solved! Go to Solution.
The problem here is that the AO sample rate you're requesting *cannot* be produced exactly by your board. Only integer divisors of 20 MHz can be produced exactly.
For you, 20 MHz / (2*2763 Hz) = 3619.25. The driver is going to pick a neighboring integer divisor, either 3619 or 3620. (It will be the same every time, I'm just not certain which way it'll round in this case.) So your *actual* AO sample rate will be either (20 MHz / 3619) = 5526.3885 Hz or (20 MHz / 3620) = 5524.8619 Hz instead of the nominal value 5526.0000 Hz that you wanted.
Meanwhile, the counter pulse train is able to exactly produce its target freq of 1.0000 Hz. *That's* why the two tasks' timing shows a little drift over an extended period of time. Since you observe AO getting ahead, it must be that the driver uses the 3619 divisor to produce a 5526.3885 Hz actual rate.
I'd bet that if you reworked your data with that actual sample rate in mind, you'd find that the tasks *do* in fact stay in sync, it's just that your previous assumptions about the AO rate weren't quite exactly right.