Why is the DAQmx Read VI so slow?

[PTobias]

@Mcdan

Thanks for your help with DAQmx Control Task.vi, improved the perfomance a lot.

I also placed the start/stop task outside the loop which furthermore improved the perfomance a lot. Any problems that could occur with that?

[Mcdan]

PTobias,

How is your task set up ?  Putting start/stop outside the loop is appropriate (and desirable) if your task does one of the following:

1) Does not configure timing at all. 

2) Configures timing, and sets 'Sample Mode' to continuous

3) Configures sample mode to finite, but uses a start trigger with 'Retriggerable' set to true.

The case I can think of where it would not be desirable would be if you configured timing, and set 'Sample Mode' to 'finite' (not retriggerable).  In this case, I believe read would error after it read all the samples in the finite acquisition.

Hope that helps,

Dan

[PTobias]

I just read one sample per loop and I read data from VISA devices at the same time.

One loop is timed to 0.5s by Wait(ms).

Hope you understand what I mean.

[Mcdan]

PTobias,

Yes, for this configuration, you should start and stop your task outside of the loop you're calling read from.  It should work just fine.

Dan

[Nisarg]

Hi

I  was  facing same problem as i need to start and stop daqmx frequently  in my application for multiple UUT Testing

After using commit function performance improved.

but still I am getting  some time to read digital pin as well as counter pin

for reading digital pin it take 8~9 msec and for reading counter channel it take 5~6 msec delay.

Pulse frequency is 500 hz

Using digital pin i am sensing Slot Sensor status.

I am using x series daq card

Thanks In advance

Regards,

Nisarg Shah

[Kevin_Price]

Looking briefly at the code, I see no good reason for the "Data" case to take as long as you described.  I'm suspicious of an error in your benchmarking method.

Both tasks are in the same case so it's unclear how you'd get distinct timing info for each.  Both tasks are in software-timed on-demand mode.  The counter task is set to count edges so there's nothing it needs to wait for (such as it might if measuring a time period).  I've seen tight loops of those kinds of DAQmx Read calls run at 10's of kHz on Windows, meaning < 0.1 msec per iteration.  The timing isn't consistent and reliable, but it *can* be quite fast.

I suspect your benchmark is measuring some additional things.

-Kevin P

[Nisarg]

i have tried same thing with express vi single digital input channel and one sample on demand setting

photo and vi attached herewith.

[Nisarg]

Kevin you are right that Both tasks are in the same case.

 if you see  FBHW_DATA case. i have put flat sequence to measure timing  of any  individual task.

initially output of digital  read task is passed  through the flat sequence structure. and i  got timing of 9~10 msec.

then  tried with counter task output to pass from flat sequence structure to get timing required by counter task. and it took 5~6 msec

see attachment  to see how i could find individual task timing.

[Kevin_Price]

Technically, that's not quite the right way to benchmark either one of the DAQmx Read calls individually.  You're setting up dataflow sequencing for only one task at a time, the other task is free to make its DAQmx Read call in parallel.

But this isn't the main issue.  Just reviewed the thread and now note that you haven't identified your DAQ device.  The original poster did up at the top, and I've been thinking in terms of PXI M-series boards.

I'll bet your device connects via USB, right?  *That's* the main issue.  USB isn't good for low latency operations.  Those several msec are likely pretty much what you're stuck with.  My remarks about 10's of kHz loop rates while calling DAQmx Read were from observations with PCI or PCIe boards.

-Kevin P

[Nisarg]

Hi kevin,

I think You correctly found the root of my problem. 

I am using  USB 6353  X series Daq card.