Hi guys,
I hope this isn't too late, but I beleive the problem is that LabVIEW only allocates up to 4 threads per execution system per priority (by default). Calling into a .dll (such as nilvaiu.dll which is called within DAQmx functions) will reserve one of those threads. I can see from your screenshot that 4 calls to DAQmx read are executing in parallel--with a timeout of -1 they will never return until you receive the desired amount of data. During this time, all four of your available threads are occupied by these calls and your VI will appear unresponsive until the DAQmx calls return (in your case, only after 1000 samples become available).
If this is inded the problem, a quick fix is to increase the number of threads allowed per execution system per priority. You can do this by running vi.lib\Utility\sysinfo.llb\threadconfig.vi. The VI is a bit dated but should be able to get the job done, a restart of LV is required for the settings to take effect.
When you call into DAQmx Read, it will block until the timeout has been reached (-1 in your case) or the desired amount of data has been acquired (1000 samples in your case). My personal preference is to avoid calling into DAQmx Read in situations when the data might not be immediately available (within 100 ms or so). You can use DAQmx Events (Every N Samples Acquired) to trigger an event case which calls the read, or you could simply poll for Available Samples per Channel before reading. I think modifying your code in this manner is a better long term solution to increasing the thread count, as you can guarantee that your interface remains responsive even while waiting for the acquired data.
Best Regards,
John Passiak
