Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Slow DAQmx Read

DAQmx Read is being "slow" for me and I don't see why.

 

I've put a DAQmx Read into a timed loop where the frequency of the loop and the sample rate of the DAQmx Input task are equal at 5kHz. When I check the duration of the DAQmx Read VI, I find that it is consistently close to the period of the timed loop. I'd like to perform some processing and control off inputs but I can't do that if the Read VI's take up 3/4+ of the loop period.

 

I've looked everywhere and I haven't noticed anything that would cause this behavior. If it's "a feature, not a bug" to not retrieve data as quickly as possible, I haven't found a way to tell it not do that. My DAQmx Write VI's had durations of about 5 µs, which is about where I had expected the DAQmx Reads to clock in at.

 

Here's an example of the behavior I'm referring to:

ABrooksKGC_0-1579544005752.png

 

The above example was timed with this setup:

ABrooksKGC_1-1579544039597.png

 

The input task is configured to use a PXIe 6612 (Slot4) and the timing stuff (pulse train generator and timed loop source) are on a PXIe 6356 (Slot2). The whole thing is running on PharLap ETS 13.1 with a PXIe 8135 as the controller.

 

- A. Brooks

 

0 Kudos
Message 1 of 2
(2,238 Views)

I've gotten the DAQmx Read duration back to where I had expected it to be, but I don't understand why the code would be operationally different.

 

I changed:

ABrooksKGC_1-1579548073208.png

 

to:

ABrooksKGC_2-1579548126328.png

After the change, the DAQmx Read duration is about where I expected it to be between 2µs and 4µs. I don't understand why the change would have a significant impact though. If someone could explain for documentation purposes, I'd greatly appreciate it.

 

-A. Brooks

 

 

0 Kudos
Message 2 of 2
(2,219 Views)