You're actually *really* close. You did a good job at sequencing the task starts to make sure both the analog and period tasks were started *before* the retriggerable pulse task (which filters high freq bursts). Thus, your data acq tasks truly *are* in sync.
The place where you can be off by 1 (or maybe more, depending on sample rate and system speed) is in your calls to DAQmx Read. Without dataflow dependency, there's no predicting exactly when the two calls happen relative to one another. In real life, one will be called slightly before the other. Both calls have the implied request to read all fresh samples because the quantity to read was left unwired. Whichever Read happens to occur later *may* find an extra sample or two there.
The fix is simple. Go ahead and continue reading all fresh samples on *ONE* of the tasks. Then do an array size on the output data and request *that* number of samples from the other task. This guarantees that you always request the same amount of data from each task on each cycle of the loop. Your earlier config work already did the hard part of sync'ing up the sample clocks for the tasks, guaranteeing that common index #'s into the arrays represent measurements that are truly simultaneous in real time.
(Alternately, you could simply specify a desired # of samples to read from both tasks. The downside is that you can no longer control you loop timing this way. I prefer your way with specified loop timing. My small tweak will then keep your data lined up.)
I would also specifically advise that you *don't* do Waveform reads. Since you apparently expect a variable-rate external clock, the "dt" part of a waveform is at best meaningless and at worst very misleading. Stick with array reads, as you have been doing.
-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.
