High speed non-continuous AO with cDAQ 9189 and cRIO 9049

[CaseyN21]

Hi There,

I am trying to run a control loop on a cRIO 9049 which is connected to multiple cDAQ 9189s through a TSN ethernet connection.

https://www.ni.com/en-us/innovations/white-papers/17/designing-distributed-tsn-ethernet-based-measur...

The cRIO has DAQmx 20 on it and is able to connect and read/write values to c modules connected to the cDAQs.

On the cRIO, I want to acquire a voltage value from a 9239 on the cDAQ and do some sort of control logic to control the AO on a 9265 current module also on the cDAQ. I want this to happen at a rate of 1kHz (faster would be better) and i think the only way to do this is with hardware timing on the cDAQ. I've attached my code which successfully acquires a voltage value at 1 kHz but I am having issues with the AO. My first approach was to use a continuous sample clock at 10 kHz and write 10 values to the buffer. This would appear to be 1 kHz analog out but I am constantly running into issues with the buffer - i.e. error 200018 (DAC conversion attempted before data to be converted was available). This makes sense because there's a point (maybe a few microseconds) where there are no values in the buffer and the cDAQ doesn't like that. However, if I write 100 values to the buffer and run it at 10 kHz, then more is going in than coming out and I eventually (after 20 seconds or so) get an error 200279, which is a buffer overflow. This also makes sense.

As an alternative, I tried to move to software-timed AO but that is much slower than 1 kHz (see Finite_Sample_Loop.vi) This takes about 65000 microseconds a loop - way too slow.

So does anyone have a suggestion for keeping values always in the AO buffer without overflowing it? There's a nifty property node that determines the behavior of the cDAQ with a buffer underflow or overflow but this property node is not allowed for the cDAQ I am using.

When using these, I get error 200452 - The different properties of DAQmx property nodes are device-specific. Not all properties are supported by all DAQ devices.

Any suggestions to get this to work? I know putting the AO modules in the cRIO would stop this issue but I would like to keep the modules in the cDAQ if possible.

I've attached the two VI's to the post.

Thanks!

[Kevin_Price]

This will not be an exhaustive answer as others are far better equipped than I to talk about specific aspects of cRIO, TSN, and even cDAQ.

That said, your "Finite_Samples_Loop.vi" that shows a 65 msec loop period is:

- far from optimally implemented

- still hw-timed and buffered, not sw-timed as you stated

SW-timed AO would never call DAQmx Timing (where a hw-clock and buffer are configured).  And you'd only write 1 sample at a time.  To optimize it, you'd start the task 1 time before the loop and stop it 1 time after the loop.  Inside the loop, you'd only write. 

Another technique that trades off loop speed for latency is to use pipelining.  Right now your AI Read and your AO Write are sequential due to dataflow.  Pipelining would send the AI value into a right-side shift register while AO would retrieve it from the left-side shift register.  This lets them execute in parallel, speeding up the loop, but it also means that AO is based on the previous iteration's AI.

Finally, generally, network-connected devices can't be relied upon for 1+ kHz bandwidth control loops.  The problem isn't bandwidth, it's *latency*.

   Both your AI and AO tasks contribute to the latency problem.  Any realistic chance at a 1+ kHz control loop is going to require you to put the critical AI and AO modules into the cRIO chassis.

-Kevin P

[JÞB]

---

@Kevin_Price wrote:

This will not be an exhaustive answer as others are far better equipped than I to talk about specific aspects of cRIO, TSN, and ....

-Kevin P

---

Not true!  Kevin probably has earned the T-shirt and worn it out.