2. If the mic signal on the 9234 is only going to be "averaged" anyway, I would agree that hyper attention to perfect sync probably isn't necessary. You could have the 9234 task be triggered by your master AI task (set trigger source for the 9234 task to a DAQmx terminal named something like "cDAQchassis/ai/StartTrigger"). Then also specify the # samples to read from your master, but use the default (-1) "all available samples" when reading from the 9234. This prevents that issue of 3 msec per minute timing skew from accumulating. The skew still exists, but it will manifest itself as either more or fewer samples than nominally expected. Up to 3 msec worth so up to 150 samples per minute. But if you're just averaging, it won't really matter.
As long as you aren't building up a backlog with your main sync'ed tasks, this approach should keep the mic data in "fairly decent" sync with the others.
5. Writing a waveform channel to TDMS will only write the extra info (t0, dt, channel name & other metadata carried as a waveform attribute in a varant) one time in a header-like fashion. After that it'll only store the array of acquisition data it carries. The overhead is very minimal compared to the advantage of having a little automatic documentation of sample rate and channel name.
As to the typedef'ed cluster and use of only a single queue -- well, that's probably more a matter of style than actual improvement in functionality. Having lots and lots of wires stretching too far to see both endpoints at once makes it harder to follow when debugging and troubleshooting. And definitely makes it easier to wiring mistakes during development. Overall though, it's not really a necessity, just a general good practice to reduce clutter because clutter can hide bugs.
-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.
