No definitive answers, just trying to focus on clues.
The CI task pretty much alternates iterations -- 1 slow, 1 fast, 1 slow, 1 fast. The only way to get a "fast" iteration of ~0 msec is if the previous iteration had DAQmx Read executing *after* the end of the 10 msec wait while the current iteration executes DAQmx Read immediately (as the 10 msec wait is just starting).
This implies that in the previous iteration, at least 10 msec passed before DAQmx Read was able to execute. Nothing in the code prevented it, so I start wondering about the driver and particularly about its attempts to negotiate access / priority to the USB bus while the AI task is also demanding access.
Not sure if you'll get useful information from this, but I'd do trials where the 10 msec wait is moved to each of the various sequence frames in turn. It's possible that other timing patterns will emerge that help you or someone else in the diagnosis.
The AI task has a more interesting pattern. The timing pattern cycles about every 4 iterations. I'm gonna guess that on average, in the long run, the loop is keeping up with the task. So the sum of every 4 iterations should keep being 40 msec.
It's clear you get long iterations that are typically about 32-33 msec, followed by 2 cycles of 0 msec. There must be another point along the rising slope to account for the remaining 7-8 msec. Roughly speaking, the pattern goes 32-0-0-8-32-0-0-8-32-0-0-8.
The 0 msec iterations happen when the task has built up a little backlog in its buffer. They're available *immediately* without waiting when DAQmx Read is called. The 8-ish msec cycle probably means that the previous iteration almost-but-not-quite emptied out the task backlog. So the call to DAQmx Read finds 2 msec worth of backlogged samples already present and waits 8 msec to receive the rest of the chunk it was asked for.
That *ought* to get the reading loop back in sync with the task, so that subsequent iterations could be expected to settle back in at 10 msec each. But it doesn't happen and I simply don't know what causes the next iteration to consistently take this extra time.
Have you tried connecting through a different USB port? Have you tried connecting to a different PC? Do you have a Windows update pending? Have you rebooted your system to give it a fresh start?
These are just shots in the dark, but they're among the things I'd have been experimenting with. I've seen some occasional odd behavior from drivers and peripherals. It has sometimes corresponded to Windows updates, sometimes cleared up after a reboot with no known root cause, and sometimes required some much more elaborate interventions.
-Kevin P
CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
