USB6363 DAQmx write (and read) timing appears slower than other similar USB DAQ devices

[plyons.gks]

Hey folks,

I currently have a pending service number with NI about this but I thought I'd post up incase anyone has ever dealt with a similar issue pertaining to USB DAQ devices.

Trying to figure out why this difference in timing exists between the USB 6363 and some of the other cheaper USB devices like the 6525 or 6501.

This is a watered down version of the actual code that my team noticed this difference in.  The actual code is an daqmx analog read (it's hw triggered, so we start the analog read task, trigger it, wait the amount of time we're acquiring for, then execute the daqmx read. which takes 6 ms to read a mere 50 values from the buffer).

Thanks 

-Pat

[CoffeeBreak]

Hi PatLyons,

I looked into your service request, and I found that the service request actually listed that the USB-6501 was taking more time during the benchmark than the USB-6363; however, in your post it seems that the USB-6363 is taking a longer time. Just for clarification, which DAQmx Read.vi benchmarked takes longer?

I also wanted to point out that the DAQmx Read.vi is pulling the data from the PC buffer and placing it into the application development memory. I provided this information because I want to assure you that the samples in the hardware timed USB-6363 task are acquired at the hardware clock rate. This information is documented in the X-Series User Manual.

One of the main differences between the two set of cards that you have listed is that the USB-6363 has the capability to have a hardware timed acquisition, while the USB 6251 and the USB 6501can only run software timed acquisitions.

[plyons.gks]

Sam- thanks for the response!

Ok- well it sound like I did a poor job explaining myself on the phone then- the 6363 takes longer.

I also wanted to point out that the DAQmx Read.vi is pulling the data from the PC buffer and placing it into the application development memory. 

I don't understand the 6ms wait to access a small amount of data from another process/app... I should explain more probably... 

In the software where this issue was discovered, there are several tasks involved.

tasks:

testDO

testTRG  <---note: typing this explanation out here makes me think this task isnt even necessary, but I'm at home without the code to experiment 

AI0

Test DO is a digital output on the same 6363 pin as testTRG (I think it's PFI8, because that pin (81) is PFI8, P2.0, and CTR0).

I set PFI8 to be a trigger input to start AI0 acquisition of N samples.

I setup testDO on the same pin (81) as PFI8, so then testDO output then triggers the acquisition (along with another instrument's signal sweep, which has its trigger line wired to pin 81).

I start the tasks AI0 and test testTRG, right before I set test DO high.

I then wait the amount of time required to sample N values @ some sample rate.

I then execute the daqmx analog read of N values- this read alone takes 6ms.  My team was expecting this value to be down near 1ms.

Thanks

-pat

[John_P1 · Accepted solution]

Hi Pat,

Try benchmarking the AI read this way (with the software-timed wait, it seems to me that the task is probably not yet done by the time you wish to read from it--I guess the question is the relative time between the Task Done event and all of the data being available in the DAQmx buffer, I don't have a USB X Series to find out):

Try benchmarking your software-timed DO write this way (there's no reason to include the verify/reserve/commit/start sequence in your write benchmark when the task can easily be started during the initialization of your program):

On my PCIe X Series both cases take < 1 ms.

Best Regards,