DAQmx write is slow. How to optimize speed?

[RezaRazavian]

Hi folk,

I have a cDAQ 9178 (via USB) and a NI 9264 on it.

In my code, I want to write 0-5V analog output signals on multiple channels (as commands to a set of motors). Please see the snippet attached.

The problem is that the loop execution time is relatively long (at least 4ms with my simple measurement). See the results. In my actual code, it reaches up to 10ms.

For my application (feedback force controller), I need much faster cycles, ideally below 1ms.

Any suggestion how I might optimize speed?

Thanks

[GerdW]

Hi Reza,

For my application (feedback force controller), I need much faster cycles, ideally below 1ms.

Place the NI9264 module in a cRIO and use the FPGA of the cRIO to apply your algorithm…

[RezaRazavian]

Thanks GerdW.

Do you know of any "cheaper" solution?

Like software optimization?

[GerdW]

Hi Reza,

- using DAQmxWrite in "1 sample" mode is slow. You cannot improve the speed of that function call…

- using an external DAQ device connected by USB can be slow: the USB connection needs some time for communication in the order of ~1ms.

Do you know of any "cheaper" solution?

You need to compare the price tag with your requirements: when the cheap solution doesn't fit to your requirements the money for that cheap device is wasted.

The somewhat more expensive device will fulfill your requirements…

What is more important (to you): fulfilling requirements or using cheap hardware?

[RezaRazavian]

Thanks for the info.

Unfortunately I'm stuck with this hardware. I'm wishing to get my requirements done, with this constraint 

[Yamaeda]

1. You're writing 12 samples at once, how does the number affect the time?

2. What's the time used for the tone generation?

/Y

[RezaRazavian]

Yamaeda,

Writing only one sample takes less time (around 840 microsecond).

With two samples: 1 ms,

with four: 1.5 ms,

with eight: 2.5 ms, 

with 12: 3.3 ms

with 16: 4.2 ms.

It seems like there is a (somewhat) linear relation between number of samples and cycle time.

Removing the DAQmx write VI brings the cycle time down to 1e-7 s.

[GerdW]

Hi Reza,

so DAQmxWrite takes ~0.6ms per call and each sample adds another 0.23ms:

Add another DAQmxRead call to read your input value(s) and you are able to calculate your possible loop rates…

[tedjenson90]

hey Gredw

thanks for your solution.

[Kevin_Price]

The best solution is GerdW's:

---

For my application (feedback force controller), I need much faster cycles, ideally below 1ms.

Place the NI9264 module in a cRIO and use the FPGA of the cRIO to apply your algorithm…

---

But I recognize that this has significant cost in both $ and time (learning curve).  I'll give you an alternate "middle ground" that will still cost some $, but not so much learning curve.  It should perform better than what you have now, but not as well as using FPGA or Real Time.

You've got 2 time battles to fight.  Thus far we've focused on *latency*.  You'd like a faster update rate so you can send the desired output to the motor drive before the control effort calculated by your control algorithm becomes "stale."

   You've probably already reached your max capability with your USB-connected cDAQ.  A desktop PCIe card can have much lower latency due to faster execution of DAQmx Write.vi   I'd suggest you consider something like a desktop PCIe-6738.

The other time battle is *consistency*, often referred to as *determinism* in the LabVIEW Real-Time literature.  Using a desktop board won't significantly change this timing battle as long as you use on-demand software timing.   You'll still be mostly at the mercy of Windows, just as you are now.  Your typical loop rate can increase with a desktop board, but you'll still see some iterations that are much slower.

If you're ready for a deep dive, a little while back I was in a thread where a special DAQmx function ("DAQmx Wait For Next Sample Clock") was found to help provide both fast (5kHz) *and* quite consistent loop timing under Windows using a desktop DAQ device.   It'll take some work to digest that thread and I'm not sure if you can usefully act on any of the findings therein.  But even if *you* can't, someone else stumbling on this thread may benefit from that one.

-Kevin P