cDAQ vs cRIO for control applications in millisecond range

[Garord]

Hey All,

I am implementing a small control algorithm into a fairly large project (mainly consisting of data acquisition) and am wondering which chassis, cDAQ or cRIO, would be the most applicable. The control loop would essentially act as a PID that involves sampling a process variable at the millisecond scale (1 kHZ+) and then outputting the control variable at the same rate (this entire process would last only 1-2 seconds at a time). I am leaning towards the cDAQ since the rest of the program only involves data acquisition but I want to make sure I am not overlooking any details that could become problematic. Is there a standard jitter expected with using a Windows PC + cDAQ combo as opposed to cRIO? Any help would be greatly appreciated!

[rolfk]

---

@Garord wrote:

Hey All,

I am implementing a small control algorithm into a fairly large project (mainly consisting of data acquisition) and am wondering which chassis, cDAQ or cRIO, would be the most applicable. The control loop would essentially act as a PID that involves sampling a process variable at the millisecond scale (1 kHZ+) and then outputting the control variable at the same rate (this entire process would last only 1-2 seconds at a time). I am leaning towards the cDAQ since the rest of the program only involves data acquisition but I want to make sure I am not overlooking any details that could become problematic. Is there a standard jitter expected with using a Windows PC + cDAQ combo as opposed to cRIO? Any help would be greatly appreciated!

---

Very much so! Unless you have one of the discontinued 913x cDAQ chassis, your software always runs on your PC and every sample has to travel from the cDAQ to the PC, then your software has to do some calculation and send back the calculated control value to the cDAQ to be output. That has a high latency definitely above 1ms due to the network traffic back and forth (or the USB traffic which is not better). With a 913x chassis you have the ability to run your control loop directly on the chassis but NI does not sell them anymore. So if your ms control loop is an important requirement for your system, the only chance is to use CompactRIO and program in LabVIEW Realtime on that controller, or possibly even do the control loop in LabVIEW FPGA.

[crossrulz]

When control is involved, I do not trust Windows.  I would highly encourage the use of the cRIO in this situation.  I am also of the opinion the the FPGA should be used for reliability reasons.  I know plenty of people who say I take the FPGA use to far, and I am fine with that.

[Garord]

Rolf, crossrulz,

Thanks for the quick responses and for providing great feedback and clarification. For clarity, I am less worried about continuous deterministic sampling and control (i.e. the control loop must iterate at 1 ms) than I am being able to output a response curve to a change detected in the system within the millisecond range (few milliseconds will suffice). If jitter is in the microsecond range, I can afford it. Everything else about the project points toward a cDAQ (mostly data acquisition, multiple different project configurations that will be using same controller) so I would prefer to stick with a cDAQ if possible at all but completely understand if this necessitates a cRIO. Let me know your thoughts here ...

I'd also love to hear your recommendations on a cRIO chassis if you have any ... budget is the big concern here (as always right?)

[rolfk · Accepted solution]

You won't be able to even remotely guarantee even 10ms reaction time with cDAQ. First you have to read the data most likely with hardware timed sampling but in small enough chunks to get a fast reaction time but not to small since each transfer costs a significant amount of time almost independent if you transfer 1 sample per read or 100 samples. This transfer is easily in the ms range at least. Then you have to process that data in your program running under Windows. Windows not being a real-time system can decide to go off and take a nap or service that hyper important telemetry app to phone home to Microsoft at any time (in all honesty though, it is more likely to simply be interrupted by network traffic that needs to be serviced right now to avoid loosing any data) and that can mean that your application simply gets no CPU time for several ms, but even 100ms or a second is a possibility. Then you need to write the data back to the device through the driver which goes again through several layers of driver software and finally to the network or USB bus to eventually arrive back in the device. All in all there is no way to achieve even close to ms reaction time with all those delays and no guarantee to be able to react within 10 or even 100ms, and theoretically it could take even longer every once in a while.

So if your process is uncritical and there is no real problem when the control reaction happens within 1 second, then you can consider a cDAQ. If you expect 10ms or better or even one delayed reaction beyond your expected reaction time could mean to damage your system, or much worse harm a human, then it is simply not an option.

[ZYOng]

cRIO-9056 is the cheapest 8-slot cRIO that supports DAQmx. You can use it like a cDAQ with low latency. You would need the LabVIEW Real-Time module to program it though.