cDAQ vs. cRIO vs. PXI: How to Choose NI Hardware

The short version: CompactDAQ (cDAQ) for benchtop and lab data acquisition where a PC is present, CompactRIO (cRIO) for rugged, standalone, deterministic control with FPGA timing on the factory floor, and PXI for high-channel-count, tightly synchronized, high-throughput production and validation test. Most wrong platform choices come from answering “what do I measure?” when the deciding questions are about determinism, environment, and what happens when the PC goes away.

The Platforms at a Glance

Cost tiers are order-of-magnitude guides based on published NI pricing; configure your specific system at ni.com for real numbers.

Determinism, Real-Time, and FPGA: What the Words Actually Mean

Determinism is not speed. It is a guarantee about timing: the loop runs every N microseconds, every time, with a bounded worst case. Windows is fast but not deterministic; it will happily pause your loop for 50 ms to think about an update. For logging temperatures that is irrelevant. For a control loop holding a hydraulic force, or a protection circuit that must react before hardware is damaged, the worst case is the only number that matters.

There are three timing tiers, and each platform maps onto them. Windows timing (cDAQ, PXI with a Windows controller): loops in the milliseconds, jitter in the tens of milliseconds when the OS gets busy. Perfectly fine for most measurement, logging, and operator-paced tests, especially since the DAQ hardware itself timestamps samples with hardware precision regardless. Real-time timing (cRIO’s processor, PXI with a real-time controller): a stripped-down OS runs your LabVIEW loop at rates up to a few kilohertz with jitter in the tens of microseconds, and keeps running headless forever. FPGA timing (cRIO’s FPGA, some PXI modules): your logic becomes actual digital hardware clocked at 40 MHz or faster, with nanosecond-class determinism and true parallelism, every loop literally runs simultaneously.

Two misconceptions cost people money here. First, engineers who need FPGA timing often avoid it because they assume it means writing VHDL. It does not: LabVIEW FPGA is programmed in the same graphical block-diagram language as everything else, and the toolchain handles the hardware compilation. What changes is the mindset (finite resources, parallel by default, slow compile-debug cycles), which is where the engineering premium comes from, not the language. Second, engineers who have never used an FPGA underestimate what it unlocks: custom triggering logic no off-the-shelf instrument offers, protection interlocks that trip in nanoseconds regardless of what the software is doing, protocol emulation, and inline signal processing at wire speed. Our cam phaser test system exists because engine-timing measurements needed exactly that class of precision.

The honest guidance: most test systems do not need FPGA timing, and paying the FPGA development premium for a data logger is waste. But when the requirement is real, nothing else substitutes, and the systems that try to fake it in Windows software become the intermittent-failure stories integrators tell each other.

Synchronization: One Chassis Is Easy, a Room Full Is a Platform Choice

Inside a single chassis, every platform synchronizes its own modules well. The platform decision shows up when the measurement spans chassis, racks, or rooms. PXI is the gold standard: the backplane distributes a common reference clock and hardware trigger lines to every slot, and timing and synchronization modules extend that across multiple chassis, aligning hundreds or thousands of channels to nanosecond class. This is the backbone of the big applications NI showcases: full-airframe structural and modal test with hundreds of accelerometers, phased-array and RF test, and EV battery cell and pack test where parallel synchronized channels are the whole economic argument.

Less known: cDAQ can synchronize across chassis too. NI’s TSN-enabled Ethernet cDAQ chassis use time-sensitive networking to align distributed chassis over standard Ethernet cable to roughly microsecond class, no dedicated timing cabling required. That pattern is a fit for physically spread measurements, think test cells down a hallway or sensors along a large structure, where PXI-class skew is not required but “same moment” still matters. And cRIO systems coordinate across the plant floor at millisecond class over the network, or tighter with hardware timing between co-located controllers, the pattern behind our distributed multi-cell cRIO data logging system. The design question to ask early: what is the worst-case time skew the analysis can tolerate between any two channels? The answer picks the synchronization tier, and the tier constrains the platform.

The Five Questions That Decide It

1. What happens if the PC dies mid-test? Walk the scenario honestly: Windows blue-screens, IT pushes a reboot, or an operator closes the wrong window, all mid-test. If the answer is “we sigh and restart the test,” cDAQ or PXI are fine and you should not pay for more. If the answer involves a damaged DUT, a ruined multi-day soak, a runaway actuator, or a person near moving hardware, the control and safety logic cannot live on the PC. That is cRIO: the loop runs headless on the controller, and the PC becomes a viewer that can crash without consequence. A useful test of the requirement: would you be comfortable unplugging the monitor and keyboard for a month? If the system must say yes, it is a cRIO system.

2. How fast and how deterministic is the control loop? Separate measuring from controlling. Sampling at 100 kS/s is easy on any platform, because the DAQ hardware paces the sampling. Closing the loop, where a reading changes an output on this iteration, is where the tiers from the determinism section apply: operator-paced sequencing lives happily on Windows, kilohertz control loops belong on the real-time processor, and microsecond reactions or precisely-timed stimulus belong on the FPGA. Our closed-loop vibration shaker controller is the canonical example: Windows could not hold the loop rate, so the loop moved to cRIO and the problem disappeared.

3. How many channels, how tightly synchronized? Count both numbers, then apply the synchronization section above. A few dozen channels with millisecond alignment: any platform. Hundreds of channels that must be sampled on the same clock edge, or instrument-to-instrument skew measured in nanoseconds: PXI’s backplane is the answer, and pretending otherwise with software timestamps produces data that looks aligned until the analysis matters. Distributed-but-synchronized (chassis spread across a cell or building) is the TSN cDAQ sweet spot.

4. Where does it live? Environment eliminates options faster than any spec sheet. A climate-controlled lab tolerates anything, so choose on other axes. Mounted inside a machine with vibration, temperature swings, conductive dust, and nobody nearby: cRIO is designed for exactly that, with no moving parts, wide temperature ratings, and no dependence on a PC surviving the same abuse. A production floor test rack with operators, a maintenance department, and uptime targets: PXI in a locked-down rack with a disciplined software image. The question to ask is not “where is it installed?” but “who touches it, and what else lives in that cabinet?”

5. What is the throughput target? At production volume, cycle time is money you can compute: seconds saved per unit, times units per year. PXI wins here through parallelism and speed, measuring many DUTs or many channels simultaneously with instrument-grade hardware. Our multi-up parallel test application cut device test time from more than three days to hours, and almost all of that came from architecture and parallelism the platform had to support. If your volume is ten units a week, throughput should not drive the platform at all; buy for the measurement instead.

When the Right Answer Is a Mix

The platform question is usually framed as either/or, but mature test systems frequently combine platforms, assigning each one the role it is best at. Three patterns cover most of what we build:

cRIO guards, PXI measures. A test cell exercising something energetic (an engine component, a high-power actuator, a battery pack) puts the safety interlocks and deterministic control on cRIO, where they survive a PC crash, while a PXI chassis makes the precision, high-channel measurements. Each platform does what the other cannot, and the interface between them is a small, defined command/status exchange, the same contract discipline as our PLC integration guide describes.

PXI core, cDAQ periphery. A production tester built on PXI needs forty more thermocouples and a few strain channels that do not justify PXI module prices. A cDAQ chassis on the same network adds those channels for a fraction of the cost, timestamped well enough for thermal data, while the PXI backbone keeps the tightly-synchronized measurements.

Bench cDAQ that grows up. R&D proves the measurement on a benchtop cDAQ system; production later needs the same test at volume on PXI, or deployed into the machine on cRIO. Whether that transition is a two-week port or a rewrite is decided entirely by the software architecture on day one.

All three patterns work because every platform programs in LabVIEW, so mixing is a software-architecture problem, not a compatibility problem. The discipline that makes it cheap is a hardware-abstraction layer: measurement logic asks for “channel: inlet_pressure” and does not care which chassis answers. That abstraction is also what lets one system scale from a bench prototype to a fleet of stations without a rewrite, the scalable test system architecture we build into every project.

One more honest note: the hardware invoice is usually the smaller half of a test system budget. Software and integration dominate, which is why the platform decision should minimize total engineering cost rather than the purchase order. Our production test system cost guide breaks down where the money actually goes.