Speed of Reading Data from USB cDAQ 9174 with NI 9239 BNC

[dienosong]

Dear experts,

I was building an IV sweep program and noticed a speed difference between two different DAQ cards. I have 1 analog output to change the bias, and 4 analog input to measure the currents, and a pre-generated waveform for the bias data as you can see in the attached picture. The loop outputs the bias data and collect 60 current points and do an average, then show them on the XY graph. 

What I found is that, if I use the 4 channels on NI 9239 BNC connected to USB cDAQ 9174, the loop rate is pretty slow, sooo much slower than if I use the 4 channels on a BNC 2110 connected to PCI 6281 (which I use to output the bias data). Is it the intrinsic problem of the USB system? Or did I do anything wrong?

Thank you all very much for the help!

[Ben]

You output one value then take bunch of readings that you average and then you output another value and repeat.

So it only goes as fast as the out put is changed.

If you want go faster do a continuous AO and use a clock from the output to clock the input.

Ben

[dienosong]

But the output is the same in both situation.

The inputs are changed from the same card PCI 6281 as the output to a cDAQ, then the speed reduced dramatically. 

The thing is the cDAQ module 9239 only has 4 inputs and we want to use all of them since we have 4 channels of data...

[bseguin]

First, remove the flat sequence frame so your code will be more clear.

With the current design, you cut the max speed in 2 since you have 2 item from the same task in series.

Benoit

[dienosong]

But it is still the same after removing the flat sequence... ?

[bseguin]

and what about the task executed in series?

Think parallel and then if you need in series, you can do in the next loop. so your loop time remain fast.

Benoit

[Kevin_Price]

Certain things about USB devices are inherently slower, with more latency, than desktop (PCI, PCIe) or PXI devices.

What I'd try is to move DAQmx Timing outside the loop and I'd probably also try adding an explicit start and stop for the AI inside the loop.  My theory is that perhaps the config stuff going on in a call to DAQmx Timing is significantly slower over USB than PCI.  Since you always configure the same parameters, there's no need to do it in the loop.

It's also possible that the USB slowdown is happening mostly at AI Read.  I don't know of a simple fix for that.  You'd probably need to change your tasks to be hw-synced, and give AI a big enough buffer size to acqure the entire data set all at once.

-Kevin P

[dienosong]

So I tried to move the Timing VI outside of the loop and a Start and Stop VI in the loop, however the speed from cDAQ is still much much slower than the BNC2110+PCI6281. I feel maybe the slowdown really is happening at AI Read?

Here's a image of the modified loop:

[dienosong]

If I do something simpler like this, I found the reading (t0 2 and x-y) sometimes turn grey during the process, so the indicators flash instead of be constantly giving a number......

The Buffer Size was set at 10000 and Sampling Rate at 50KHz.

[Kevin_Price]

Some explanation about "Problem 2".  No, wait, first a simple fix.  The call to DAQmx Read has an input available for "# samples per channel".  Wire up the 10000 buffer size value to it and run again.

Now the explanation.  When unwired, the default value is -1, a special value that has a special meaning.  More to the point, it has a *different* special meaning now that you've configured DAQmx Timing for "Continuous Samples" mode instead of the previous "Finite Samples".   Yeah, I know, not exactly intuitive.  The info's there when you dig into the help, but first you need to know that it's *important* to dig into the help, right?

Anyway, in "Finite" mode, the default -1 value means "read the entire finite buffer size worth of samples.  If they haven't all been acquired yet, wait for them (or until the timeout is reached)."

In "Continuous mode, the default -1 value means "give me all the new samples that have become available since the most recent time I asked".  If you make such requests faster than new samples arrive in the task buffer, DAQmx Read will happily return the nothing that's arrived.  And that's correct, defined behavior for the DAQmx Read function, even if you aren't expecting it.  And it's why your indicators seemed to flash -- some iterations you were feeding them nothing instead of actual data.

-Kevin P