Hi Mark,
Sorry for not mentioning this, the 6602 only has 3 DMA channels so (as you have reported) you will need to configure the transfer mechanism to interrupts on at least one of the four channels. This is a new requirement since configuring implicit timing on your counter input task sets the default transfer mechanism to DMA. Again, the purpose for doing this is to postpone calling into DAQmx Read which blocks a thread while waiting for data to be available (setting implicit timing allows the acquired data to be buffered so it is there when Read is called some time later--I think I've mentioned previously that I'm not the biggest fan of this behavior but changing it would break existing applications). For streaming data Interrupts are far less efficient than DMA but since you are only acquiring a single sample at a time there shouldn't be any problems.
I was probably not thorough enough when I said earlier that LabVIEW allocates 4 threads per execution system per priority by default. The 4 threads is per core on a multicore system, so if your PXI controller is multi-core than you wouldn't have seen the same problem as you would on your (presumably) single-core PC. Again, the problem is that calling into 4 DAQmx Reads in parallel will consume all 4 allocated threads and prevent your DO task from executing. You can allocate more threads if you wanted by running the configuration VI I mentioned earlier, but I think it's usually preferable to only call read when you know data is going to be available (when possible).
Regarding DMA channels, the original method did not require them as the default timing mode for on-demand timing is "Programmed I/O".
I'll agree that none of this is very intuitive--at least on newer hardware (like X Series) there are enough DMA channels so that it is impossible to run out. The DAQmx Read calls blocking LV threads is an unfortunate artifact of the way that LV manages threads when calling into external .dlls (like the one found inside DAQmx Read).
Best Regards,
John Passiak
