12-03-2006 07:59 PM
12-04-2006 04:51 PM
12-05-2006 03:28 PM
I am using a PXI 8186 controller. The usb port plugs directly to the front panel. I am using Visual Studio.Net 2005 and DAQmx 8.3.
I sample 28 channels simultaneously at a rate of 800 kS/s for 100 ms, getting 80x28 kB per data block. It takes ~25 ms to read in this data from DAQmx to VS.net. Then the process is repeated. The time between data blocks is dead time and should be as short as possible. Data from the previous block is processed and stored while the next block is being acquired.
I have been completely aware of the option in DAQmx to use a single task with multiple S series modules. I have spent quite a bit of time trying to make the single-task/multiple-module task work adquately, but I eventually gave up. That option was slow. It was MUCH faster to establish separate tasks for each module. Perhaps the slowness of the tasks had to do with synchronization between AnalogInput and Digital Output because I am using timers and digital outputs to generate the signal that is synchronously sampled by the AnalogIn. Or perhaps it is a problem with DAQmx and the 6120 modules.
I note here also that I was able to obtain better performance when I used Traditional NIDaq compared to DAQmx.
The reference you listed was for LabView programmers. Please note that I am NOT, and will never be, a LabView programmer. I will suffer with the lower level of support that NI provides for languages outside of LabView.
I have been a bit frustrated in this task because, at first, the 6120 modules were not supported by DAQmx so I developed all my code in Traditional NIDaq. Then I purchased a second system containing PXI 6123 modules -- these modules were supported in DAQmx but not in Traditional DAQ. So rather than maintaining two sets of software, I converted all my original code for the 6120 modules from Tradional NIDaq to DAQmx because by that time, two years later, the 6120 modules were supported by DAQmx. Now the performance of the system with the 6120 modules is somewhat worse than it was with Traditional NIDaq.
In Traditional NIDaq I was able to use alternate buffers for successive data blocks and thus avoided moving data from one block to another in between blocks. If there is a way to do that in DAQmx I would appreciate the link. I am aware that eventually I may be able to use double buffers and to do continuous acquisition. But with my need to synchronize DigitalOut with AnalogIn and to obtain data blocks that are synchronized to a specific pattern of the DO has led me to defer that task. Furthermore, I know that occasionally with double buffering and continuous acquisition, I will occasionally miss a whole of data when the processor is not keeping up.
Thanks for your efforts,
Dave George
970 263 9714
12-06-2006 11:57 PM
Hello Dave. All double buffering is automatically handled by the DAQmx driver while the user had to handle the double buffering in Traditional DAQ. Also, there is no way to not move data from an acquisition buffer to an application buffer without eventually overwriting the data so some data duplication is necessary no matter what driver you are using. I would suggest restructuring your application to use continuous acquisition as it will significantly reduce the number of interactions between your application and the driver. As far as your concern about losing blocks of data, as long as you don't tell the DAQmx driver to overwrite unread samples, DAQmx will throw an error before you lose any of your data. This is definitely an enhancement over Traditional DAQ where the data would simply be overwritten without any error message. I hope this information helps you in your application. Have a great day!
Brian F
Applications Engineer
National Instruments