Multifunction DAQ

Showing results for 
Search instead for 
Did you mean: 

usb port causes slow analog input

I have a system that has seven PXI-6120 Analog Input modules.  I am simultaneously sampling 27 channels of analog data.
I am using Visual Studio Net and DAQmx.
The system runs fine until I add a separate instrument that communicates through the USB port.  I access the data from the USB port through a third party virtual USB driver that presents the data to a com port (com3 for example).
The problem is that when any data is arriving at the usb port, it substantially slows the performance of daqmx to handle the data arriving from the ADC's.  I have made several tests but the following one describes the most demonstrative test.
The external instrument (a Novatel GPS receiver) is connected to the usb port.  The third party software connects the communications from this instrument to com3. 
In the first test, my program opens the com port (com3) and that is all.  The rest of the system runs fine.  It takes on the order of 25 ms to transfer data from the ADC's to my application (why it takes 25 ms is a separate frustrating issue because it should just be passing an address to a buffer).  Then it takes about 6 or 8 ms to stop and re-start the DAQmx tasks that drive the ADC's.  That amount of time is acceptable and all is fine.
In the second test, my application executes exactly the same as in the first test with one difference.  After opening the com port, it sends a command to the instrument that causes the instrument to begin sending data to the usb port (which appears at the virtual com3 port).  The rate of data at the port is about 72 bytes every 0.2 seconds.  When this data is appearing at the usb port, DAQmx taxes on the order of 750 ms to read the data from the ADC's.  In addition it takes about 700 ms to stop seven DAQmx tasks and about 700 ms to start seven DAQmx tasks.  Note that my application is doing nothing with the data that arrives at the virtual com port, although separate tests have shown me that I am able to process that data OK.
In the third test, my program does not open the com port.  Instead I start my application and then I start Hyperterminal to listen to the virtual com port.  I can send a command to the instrument and data arrives at the virtual com port and appears within Hyperterminal.  I this case, my application runs at normal (fast) speed and data arrives and displays normally within Hyperterminal.
In a fourth test, I can connect the instrument directly to a serial port instead of a virtual serial port (through the usb port).  In that case everything runs normally.
Finally, in a fifth test, I can connect the instrument to a 'fourth-party' serial-to-usb adapter.  In this case, the fourth party supplies the usb port driver and therefore the virtual com port.  Note that in this case DAQmx sees a virtual com port and not a regular com port.  In this case, all again runs normally.
In summary, the problem only appears when data is arriving at the virtual com port through the usb port.  It appears as some interrupt service routine is monopolizing processor time -- particularly within DAQmx servicing the ADC's.  If someone has some insight I would appreciate a response.
I have had several communications with the instrument manufacturer and with the developer who supplies their usb virtual-com-port driver.  The first logical conclusion is that that manufacturer's usb port driver is stealing cpu time away from the whole processor and therefore slowing down data acquisition.  But the manufacturer has not experienced this problem before and the fact that a hyperterminal task (that 'talks' to a virtual com port) implies that it might be a problem within DAQmx.
So this posting is to ask for others' experiences and insights into this problem.  Given no solution I can use a separate Serial-USB adapter or perhaps a separate serial port (although I am one short of enough serial ports for this application). 
I conclude that something within DAQmx is sensitive to data arriving at a c
0 Kudos
Message 1 of 4
Hello Dave.  It certainly sounds like you have done a lot of testing on this issue.  Your comments have generated a few questions in my mind.  First, what version of the DAQmx driver are you using?  Secondly, are you plugging your usb GPS device into a PXI controller or into a PC that your PXI chassis is also communicating with via MXI?  Also, how fast are you sampling on each of the 6120's and how many samples are you taking on each channel before switching to the next channel? 
Looking at your setup, a good way to increase your performance immediately is to utilize the advantages the 6120 gives you.  Since it is an S series device, you can configure multiple devices in the same DAQmx task which will allow you to only start one task instead of seven tasks.  You will be able to get the same amount of data with a significantly less amount of configuration overhead.  Information on how to accomplish this can be seen at:
Multidevice Task Support For DSA and SMIO Devices
It is certainly possible that the slowdown is a result of a competition between the PXI devices and the USB device over the bus.  However, it seems like your solution of a Serial-USB adapter could get around this conflict.  It seems like this is certainly a valid solution.  Good luck with your application and if you have any further questions or comments, please feel free to post here! 
Brian F
Applications Engineer
National Instruments
0 Kudos
Message 2 of 4

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  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



0 Kudos
Message 3 of 4

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

0 Kudos
Message 4 of 4