DAQmx's DAQmxReadAnalogScalarF64 takes way too long to execute with USB-6221

[Joe Schmoe]

THE PROBLEM:

The DAQmxReadAnalogScalarF64 takes way too long to execute when used with the NI USB-6221 M Series.  I measured the clock time using two brand new laptops.  Each computer took 0.023 seconds to execute in each.  I have 14 instruments to scan.  My system’s software clock needs to run at 0.10 seconds per cycle.  We need to acquire individual AI channel voltage values in about a maximum of 0.0015 seconds in order to properly run our system.  This was easily achieved using both our PCI E-Series, as well as the IO Tech USB 3001 Personal DAQ.

BACKGROUND:

My company is in the last stages of a multi-million dollar control and automation project for the US Military.  We will be producing up to 100 portable units deployed to the field and used by military personnel.  The units are controlled by a PC using windows XP.  We have purchased the NI USB-6221 M Series.  Additionally, we have invested several man years developing a Visual Basic 6.0 software program to operate the equipment.  Our software is in communication with the M Series drivers.

The software operates using a software clock, to ‘ping’ various M-series drivers.  The system can be considered strictly single point acquisition and control.  The system consists of 14 instruments, 14 switches, 5 actuators, and 12 PIDs.  

We have successfully utilized our VB6 software to control PCI-E Series boards for similar automation applications.  Furthermore, we have successfully utilized the IO Tech 3001 Personal DAQ for this equipment, but are planning to switch to NI instead.

VB6 CODE:

Public Function AIChanVoltsGet(ByRef Index As Integer) As Double

Dim Data As Double

Dim timer2 As Single

timer2 = Timer

    DAQmxErrChk = DAQmxReadAnalogScalarF64(AiTaskHandle(Index - 1), 10#, Data, ByVal 0&)

    AIChanVoltsGet = Data

Debug.Print Timer - timer2

End Function

QUESTIONS:

1.)    Is the DAQmxReadAnalogScalarF64 function much slower using the M-Series than the equivalent function using the E-Series hardware or driver?

2.)     Would a PCI M-Series drastically speed up the DAQmxReadAnalogScalarF64 function to less than 0.0015 seconds?

3.)    Are there software driver / method alternatives that could speed up the single point acquisition?  I am not so keen on acquiring all channels and then picking through an array, but will if no other alternative exists.  The function would need to be really fast to justify this.

[snowpunter]

You may want to look at this thread.

[stilly32]

1. So USB certainly adds a lot of latency and jitter to a bus measurement so comparing single point performance on PCI vs USB your PCI is going to win, regardless of driver or E-series vs M-series.

2. A PCI M-series would be much faster on single point and on a reasonable system you can get less than .0015 seconds per read. I don't have the exact numbers on me but I know I've benchmarked loop rates over 50k on XP. 

3. If you're not already, make sure to start the task before you start reading. I put together a quick test in LabVIEW (performance will be close) and got around  20ms per read if I didn't start the task before reading in a loop, ~1.1 ms if I did. DAQmx has a task state model: when you don't call the DAQmx start the read starts the task, takes the reading and stops it for you and each time you call read it goes through all those steps. If you start it first it doesn't need to start and does not stop the task, it just has to go out and read.

Hope this helps,

Andrew S

[Joe Schmoe]

Andrew,

Thank you for your informative feedback.

In item #3, you say to "make sure to start the task before you start reading."  I added the below listed code (blue line) when the form opens, but it produced no performance improvement.

    For idx = 0 To constNumOfAiChans - 1

        DAQmxErrChk = DAQmxCreateTask("", AiTaskHandle(idx))

        DAQmxErrChk = DAQmxStartTask(AiTaskHandle(idx))

    Next idx

QUESTION:  When you performed your test, were you using a USB or a PCI board?  (I am using a USB-6221)

PS: If this is the true AI single point execution time for the USB boards, then it is just about useless to use this board for closed loop control applications such as test stands that use PIDs.  If so, I am surprised that this is not more of an issue.

Schmoe

[stilly32]

Hey Schmoe,

I used a USB-6221. Looking at your code - are you using multiple tasks? It looks like you have  "constNumOfAiChans" number of tasks that you are iterating through. Also, where are your create channels? - you'd want to start after you create the channels. If you can, try using 1 task and in the create channel use mulitple lines "Dev1/ai0:4" or use the create channel multiple times on the same task (if you need to use different gain settings. If you are using different tasks each read then you won't be able to take advantage of the start because the resource will be reserved. 

As for USB for control applications, depending on the loop rate you need you are correct - USB is not the best choice. The bus by it's nature is not deterministic and is host driven - the data is transferred when Windows asks for it. If you needed something along the order of 100 hz then USB would be a good solution, but if you need anything above 1kHz, I would go with a PCI/PXI or PCIe/PXIe solution. USB is much better for buffered data - you can acquire at full rates on all subsystems without an issue on most systems. Latency and jitter don't affect the throughput much when you can use the FIFOs. 

Hope this helps, 

Andrew S

[Joe Schmoe]

Andrew,

Thanks so much for getting back to me.

I attached to this post the National Instruments example for single point analog input.  I modified the program to record the time before and after execution of the "DAQmxReadAnalogScalarF64" command.  I am wondering if you could try it and see if you get similar results?  I get either 0.0156 or 0.03125 seconds lag time for each run.

Just to be clear; were you in fact able to some how acquire analog channel readings from a USB-6221 in less than 0.001 seconds???  If so, maybe you could test the attached program and then provide a few tips, if you would be so kind.

J. Schmoe 

[stilly32]

When I run the exe, I get similar results when I get anything at all - it usually returns 0. The benchmarks I did before in LabVIEWwent like this:

Create task

Create channel

Start task

start timer

while(i=0, i<1000, i++){

read analog 64

}

stop timer

avg read = time/1000

clear task

when I do this in LV, I get ~1.1ms. 

I'm sorry, I don't have VB6 on this machine but can probably track one down. 

Looking at the code you just sent, I would just add a DAQmxStartTask(taskHandle) right after the DAQmxCreateAIVoltageChan(). This should help singe point reads out... if it doesn't I need to track down a machine and do some debugging.

'  Add an analog input channel to the task.
    DAQmxErrChk DAQmxCreateAIVoltageChan(taskHandle, physicalChannelTextBox.Text, "", _
                    DAQmx_Val_Cfg_Default, minValueTextBox.Text, maxValueTextBox.Text, _
                    DAQmx_Val_VoltageUnits1_Volts, "")
    DAQmxErrChk DAQmxStartTask(taskHandle)               
    '  Read in one sample from the analog input channel.
    DAQmxErrChk DAQmxReadAnalogScalarF64(taskHandle, 10#, data, ByVal 0&)

Thanks, 

Andrew S

[Joe Schmoe]

Thank you very much for the testing.  I got similar results when only testing a single channel, after inserting the call DAQmxStartTask as yourecommended.  However, I do not know away to run multiple channels using single point, using separate tasks, becauseit seems that the task is reserved after it is started. 

Could the cause of the delay be that a task is re-startedafter every execution of the DAQmxReadAnalogScalarF64?

[stilly32]

By similar results, do you mean ~1.1 ms read time of 20ms read time?

As for multiple tasks, if you need to use multiple tasks you will have to start/stop each one because each task will reserve the AI resource after it is started. Do you need to use multiple tasks and if so, why?

Thanks, 

Andrew