Extremely slow sampling rates with DAQPad 6020E

[Matt Harding]

I'm using LabView to perform PID position control with the DAQPad 6020E interface. However, i can't sample any faster than 6 samples per second. I have put a function generator on an analogue input of the DAQPad and then wired that straight through to a DAC output in Labview and then observed the output of the DAQPad on a CRO and the sinewave input is only sampled at 6 samples per second - completely inadequate for my application! It should be capable of 100k samples per second! Running it on a faster system makes no difference. (i'm only using a P3 700MHz) Any idea's? Thanks

[Jamie Fraser]

You might be suffering from "first byte latency" that is a problem with USB. This means that the time before the first byte is transferred can be quite long, but once the USB channel is open the continuous data rate is as high as specified. If you are doing single point reads inside a software loop then you will suffer badly from this issue. You need to set the device up for a continuous acquisition.

I had to switch from the DAQPad 6020E myself because of this same problem. Whether it will work for you in your application depends on whether you can tolerate the FBL and/or sample data continuously. You could try having a continuous acquisition running at your desired sample rate, and just process the data as it comes in. Consider using multi-threading fo
r this.

Good luck.

Jamie

[AnujD]

During a single point operation, the DAQ device requires a complete set of configuration commands. This is done through serial communication (USB or FireWire), making the process slower than in a PCI-based board. The speed obtained for single point operation in a DAQPad is system dependent; this means that your computer processor, memory, bus speed, and other factors alter the speed at which you can do single-point operations with a DAQPad.

For example, on the DAQPad-6020E, timed non-buffered analog input operations are limited to about 50 Hz. At higher rates, the software may become unresponsive. I am assuming you are using a non-buffered acquisition.

You can find even more information about this at http://digital.ni.com/public.nsf/websearch/862567530005F09
C86256746006BDA82?OpenDocument.

To speed things up, I suggest looking in the LabVIEW shipping examples for a buffered analog input.

[jlamber9]

I have an experiment running at 10 hertz and am performing data acquisition with a 6020E(with BNC connections). After an external ttl trigger I acquire scans over two channels but I only need a single data point from each so i select one. I select the last point in the buffer for two channels channel.

This application is extremely slow. The code does not even keep up with the 10 hz trigger or for some reason it is missing triggers. My code is included.

The code is ran with labveiw  8.6.

The computer has a quad-core 3.0 Ghz processor, 3GB of ram, and usb 2.0 connections.