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.

CompactDAQ vs. CompactRIO: The Head-to-Head

PXI is a different budget and a different job, so most real decisions come down to two platforms, not three. If you are weighing CompactDAQ against CompactRIO (or searching it as cDAQ vs. cRIO, or just DAQ vs. cRIO), the deciding question is not what you are measuring. Both platforms accept the same C Series modules, so the sensor list rarely picks a winner. The question is what the system has to do with those measurements, and whether it has to do it alone.

The blunt version: cDAQ is a measurement front end for a computer. cRIO is a computer that happens to measure. If a person is standing there with a laptop when the test runs, cDAQ is almost always the right call, and choosing cRIO instead buys you a real-time OS and an FPGA that you will pay engineers to program and then never need. If the box has to sit inside a machine, hold a control loop, and keep its promises when Windows decides to install an update, no amount of cDAQ saves you.

The mistake we get called in to fix runs in both directions. We have replaced cRIO systems that never used the FPGA, where the customer paid the real-time premium for what was structurally a logging application. We have also rescued cDAQ benchtop rigs that got promoted onto a production floor, where the Windows host quietly became the single point of failure for a line running three shifts. Both are expensive, and both were decided before anyone asked whether the PC was going to be there.

Why Not a Raspberry Pi or an Industrial PC?

It is a fair question, and it comes up in almost every budget conversation. A Raspberry Pi costs less than a single C Series module. A rugged industrial PC costs a fraction of a cRIO controller. If the job is reading sensors and writing files, both can genuinely do it, and we would not pretend otherwise.

What you give up is the part that is hard to see on a spec sheet. Signal conditioning is the first: a C Series module gives you isolation, excitation, cold-junction compensation, and calibrated ranges inside the module. On a Pi you are building that yourself, in analog, and the measurement is only as good as the board you soldered. Determinism is the second: standard Linux on a Pi offers no timing guarantee, so a control loop is best-effort, and the FPGA layer that gives cRIO microsecond-class certainty has no equivalent. Calibration and traceability is the third, and it is usually the one that ends the discussion: NI modules ship with calibration certificates and a documented recalibration path, which is exactly what an auditor, a customer quality group, or an ISO process will ask you to produce.

So the honest rule: a Pi or an industrial PC is reasonable for internal monitoring, prototypes, and anything where a wrong number costs you an afternoon. Once a wrong number ships a bad part, fails an audit, or damages a machine, the platform has to be defensible, and that is what you are actually buying with cRIO. The hardware difference is a few thousand dollars. The engineering time to rebuild conditioning, timing, and traceable calibration yourself is usually more than that on its own.

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.

Starting on cDAQ and Moving to cRIO Later

This is a common and sensible path: prove the measurement on a bench with cDAQ, then move to cRIO once the application earns it. It works well, but only if you plan for it on day one, because the cost of the move is almost entirely in software.

The hardware side is the easy half. C Series modules carry straight across, so your sensor wiring, conditioning, and calibration survive the transition intact. What does not carry across is code written the way benchtop code usually gets written: measurement logic tangled into the user interface, timing that assumes a Windows host, and file I/O that assumes a local disk. On cRIO there is no front panel, the timing is yours to specify, and the storage may well be a remote database.

Three habits make the later move cheap, and they cost almost nothing to adopt at the start: keep measurement logic separate from the user interface so the acquisition engine can run headless; put DAQ calls behind a hardware abstraction layer so the code asks for a named channel rather than a specific device; and treat data storage as a service rather than a file path. Systems built that way move platforms in weeks. Systems built without them tend to get rewritten, which is why the second version so often costs more than the first one did.

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.