Make DAQmx calls capable of running more than 4 multithreaded tasks

[kr74i0au]

The NI DAQmx read is currently limited to 4 multithreaded tasks due to the fact that it is merely a wrapper for an underlying DLL call.  Significant jitter and performance degredation is experienced (#7339294) as the number of parallel reads is increaced beyond 4. As NI transitions to the PXI platform and away from SCXI and users begin acquiring data from large numbers of PXI devices, this thread limitation limits the flexibility and ultimately performance that can be had with such a versatile platform.

NI marketing pictures frequently show PXI chassis fully outfitted with various DAQ input cards, but this limitation limits the practical usability of running large numbers of PXI DAQ devices much more so than the bandwidth limitation of the bus. Also, this limitation is referenced nowhere in any documentation pertaining to PXI DSA, DAQ, or SC series hardware. 

DAQmx read should be fully thread safe.

[John_P1]

The 4 thread limit is actually a LabVIEW default (4 threads per execution system per priority)--you can increase the limit by running threadconfig.vi as mentioned in the KB How Many Threads Does LabVIEW Allocate?

Of course, simply increasing the number of threads allowed ad infinitum is probably not the best solution either.  Most newer DAQ hardware supports multi-device tasks for analog input, such that multiple separate devices may be combined into a single task and the synchronization is performed behind-the-scenes.  So, those PXI chassis fully outfitted with DAQ cards can sometimes be consolidated into a single thread quite easily.

For cases where multiple tasks are required, I generally try to avoid calling into DAQmx Read unless the data that I'm looking for is already present (especially if I'm using external timing or triggering such that the requested data might never be available).  You can accomplish this by using DAQmx Events (Every N Samples acquired) or by polling available samples per channel.  I'll agree it might not be the most intuitive, but doing this solves the problems that one might encounter when calling into DAQmx Read when it is uncertain how long it will take before data is available.

[kr74i0au]

One of the guys here found a neat solution that has fixed the issue quite nicely. Simply call a wait prior to the DAQmx read for slightly under the anticipated time to acquire the requested number of samples. This offloads the DAQmx read call that is simply waiting most of the time anyway and ensures the reads don't fall behind.