Which NI platform best fits my automated test needs?
cRIO, PXI, cDAQ?

So you’re thinking about investing in an NI (National Instruments) platform for your automated test system. That’s great, but you’re asking, “How do I navigate the alphabet soup that is the NI product line?” It’s actually not all that daunting. In general this is roughly how the systems relate to each other.

NI cRIO (compact rio) which platform is right

Of course we’re generalizing here with broad brush strokes; there are lots of details and several variants of each platform. We’re painting a basic picture before we dive into more details. The intent here is to help you understand the right platform for you, not just the highest performing or cheapest.

Something to point out is that one of these is not like the others (cue Sesame Street music). PXI and cRIO contain CPUs and are capable of running applications independently. CompactDAQ comes in two flavors: one that has an integrated controller and one that does not and is instead meant to be an extension of other processor-based systems. If after reading this article, you have more detailed questions specific to your needs, feel free to reach out to ask a question.

Now let’s talk specifics.

PXI – The Workhorse

PXI is so flexible and extensible that it can be used for so many different test applications. We’ve used it for things like:

End of line test for aerospace products
Streaming several GB/s of LVDS digital data to 24 TB RAID arrays
High volume test of vehicle key fobs and ECUs
Testing Gatling guns for military aircraft
and even to prototype medical devices with lots of analog IO.

PXI is the workhorse of the NI family. It is capable of handling 1000s of digital and analog IO. It can process massive amounts of data with the latest CPUs or with some of the largest Xilinx FPGAs. It is also extensible through the use of MXI-Express to other PXI chassis or through Ethernet/USB to cDAQ (more on that shortly).

PXI is best suited for systems that require the wide range of test instruments that PXI supports, or that need the processing power of a PXI controller. Applications that have space for a PC-sized chassis will be able to benefit from a graphical user interface (GUI) without having to connect a separate host PC.

PXI has the broadest range of off-the-shelf expansion cards. Everything from DIO and AIO to RF signal generators and analyzers to industrial comms to FPGAs with COTS interfaces for DIO, AIO, and RF. In addition, PXI has the widest range of 3^rd party cards for things like GigE camera interfaces and the ability to create custom cards and interface modules for FPGA cards. This might sound like a sales brochure, but it’s really just trying to point out that there is a LOT you can do with PXI.

PXI can run Windows for most general applications or a real-time operating system (RTOS) for when more determinism is needed, but cRIO will not work for some other reason. We’ve used PXI quite a bit (see here for more details).

If you need even more cutting-edge signal interfacing and processing horsepower, check out FlexRIO. There’s quite a few off-the-shelf modules available, and several adapter modules. Custom adapter modules can be developed as well.

CompactRIO – Lean & Mean

CompactRIO is the lean, mean cousin of PXI. It’s lower powered, but designed for applications that require a much smaller physical profile. In addition to test, cRIO is well suited for applications such as embedded industrial control or condition monitoring, among others.

This platform has many IO options, but RF is not one of them. CompactRIO is better suited for industrial applications where a PXI chassis may not be able to handle the environment or applications where space is at a premium (like inside a small enclosure).

Custom modules can be created, but can require more LabVIEW software development to complete (and might possibly include ‘C’ development depending on the module needs). Most solutions can be accomplished with COTS modules and some form of signal conditioning when needed.

cRIO has a built-in FPGA and RT operating system for more deterministic applications than PXI. It is ideal for headless operations that need to run unattended for long periods of time, but some controllers have embedded UI capabilities that allow an HMI to be included. Because of its headless nature, cRIO generally requires more development effort. Of course this is very application dependent, but knowledge of LabVIEW RT and FPGA and usually network communications is essential.

It’s important to note that many cRIO controllers can utilize DAQmx to acquire and output data, reducing or eliminating the need for FPGA knowledge to deal with I/O on a cRIO.

cRIO can also utilize Time Sensitive Networking (TSN) to synchronize hundreds of channels across multiple cDAQ chassis using a cRIO controller as a master.

We’ve used the cRIO quite a bit (see here for more details). Some good examples of cRIO based test applications are:

Replacing custom electronics in high power capacitor testing
Closed-loop control (another good one: ECU simulation) in large hydraulic actuator testing
Data acquisition in industrial UPS testing

A few non-test applications for cRIO include:

CompactDAQ – Dual Personality

cDAQ comes in two main flavors: with a controller, and without a controller. In its most basic form cDAQ is an IO extension for harsher environments than you would want a PC or PXI chassis. Other cDAQ models feature a built-in controller that can run either Windows Embedded Standard 7 (WES7) or NI Linux RT. It has the downside of not having a programmable FPGA, but has the advantage of simpler programming through the use of NI’s DAQmx API.

cDAQ has several connectivity options including USB, Ethernet, and 802.11 WiFi. It can accept most of the C series modules that cRIO uses.

cDAQ with a controller has many of the same applications as a cRIO, but could also be used where a PXI chassis is overkill and a GUI is desired or when the determinism of a programmable FPGA is not necessary.

Without a controller cDAQ is best used in situations where IO needs to be placed close to sensors or controls, but away from the controlling PC, such as for engine cam testing where the RTDs are placed inside a protected test bay and the controlling PC and UI are outside.