Speeding up analog output from a CDAQ-9263 card

[PaulOfElora]

Hi folks - I'm using a 9263 in a CDAQ-9174 USB-connected chassis.  I'm generating 1 output DBL sample at a time in a control loop.  I'm not having any trouble getting to a millisecond or less with the analog input and my calculations, but my 9263 is taking between 1 and 4 milliseconds per each call.  I realize that I'm not going to come anywhere the maximum speed of the card, especially with a USB chassis, but I really would like to get the 9263 calls down to a millisecond or a little less.  I read that I need to prevent regeneration, did that.  No DMA available for USB chasses.  Played with the Data Transfer Request Condition, no joy there.  Any ideas on how to speed up my DAQMX calls or the card?

thanks in advance, paul

[side note - what's the best way to measure the loop speed?  I tried the profiler but it doesn't show the DAQ Write calls.  I've read that disabling debugging will speed up a vi, but I'm not sure that matters for > milliseconds timing - expert thoughts on best practice?]

[Kevin_Price · Accepted solution]

Lesson 1: USB-connected devices aren't the best choice for low-latency control loops.  There are inherent limitations, and it's quite possible you're already up against one.

Things to look into:

- every AO update appears to include the firing of an error checking event which will in turn call some other vi which wasn't included.  This adds to the time between successive AO updates.  (Note: the event typedef wasn't included either, so I only see a greyed out hint that it's the error checking event getting fired).

- I'm not certain how the "auto start" option on DAQmx Write interacts with the DAQmx Task State Model in a software-timed task.  I *do* know that in some other situations involving buffered tasks, it's better to call DAQmx Start explicitly.  Not sure this will help your situation, but you can try having your "Start" event call DAQmx Start explicitly just before the initial call to DAQmx Write.

- There are some odd and unnecessary things in your task config.  Again, dunno if fixing them will speed anything up, but it won't hurt to try.

    Because you don't set up a sample clock with DAQmx Timing, you have an on-demand software-timed task.  There's no buffer, thus no need to disable regeneration or to explicitly set a buffer size of 0.   (And setting the buffer size runs in parallel to starting the task?).  Even the Data Transfer Request Condition is probably irrelevant, though you might fiddle a bit with the nearby USB-specific transfer-related properties.   (I don't have any experience with them so I can't tell you much more. If I were in a similar bind, I'd have the option to switch over to a desktop-based solution which you might not have.)

    I do notice now that your config code does do the explicit start the way I suggested.  Do your event-based start the same way, it may possibly help.

My suspicion is that none of these things (except possibly the USB transfer properties?) will prove to be a major impact.  It won't hurt to try, but I don't expect there'll any way to get down to sub-msec timing.  (And under Windows, it certainly won't be consistent.  You can expect "hiccups" where some iteration intervals take 10's of msec or more.)

-Kevin P

---

[PaulOfElora]

Thanks Kevin. Yeah I kinda figured the USB might be the bottleneck - had to buy it cause the project didn't have the $$$ for anything fancier.  Monday I'll fiddle with USB settings a bit.

I'm wondering if ethernet-connected cDAQ would give lower latency.  Guess the next step up would be real-time.  Not really that much of a price jump for hardware, but gawd I'd have to learn a bunch of new stuff!

RE profiling - anybody know of a good way to characterize latency for USB or ethernet busses?