Here’s a scene that plays out in a lot of test labs. The test stand itself works fine — thermocouples, pressure transducers, flow meters, all logging cleanly. But the unit under test isn’t just a mechanical device anymore. It has a controller on board, and the most interesting numbers — commanded operating point, internal temperatures, fault codes, actuator states — live on a CAN bus the test stand can’t hear.
So somebody improvises. A technician plugs a USB-CAN dongle into a laptop, starts a logger, and hits “go” on the test stand at roughly the same moment. At the end of the run there are two files with two clocks, and an engineer spends the afternoon in Excel trying to line them up — hoping the interesting event didn’t happen in the gap between timestamps.
If that sounds familiar, this post is for you. Getting network data into your automated test system properly isn’t exotic — but it does need to be designed in, not bolted on. At Dynamic Engineering, we’ve been integrating CAN bus communication into LabVIEW-based test and data acquisition systems for well over a decade, from engine and transmission test cells to fluid-evaluation systems that exercise vehicle hardware. Here’s what we’ve learned.
Why the Two-Laptop Approach Falls Apart
Logging CAN separately from your analog data seems workable until you look closely at what it costs you.
Your timestamps never really agree. Two free-running clocks drift, and “we synced them at the start” degrades over a long test. When you’re trying to correlate a pressure spike with a commanded state change, tens or hundreds of milliseconds of uncertainty can be the difference between an answer and a shrug.
You can only listen, not talk. A passive logger can’t command the controller to a setpoint, request a diagnostic session, or clear fault codes between test steps. That means an operator is still in the loop doing those things by hand — which is exactly the variability an automated test exists to remove.
The test can’t react. If the ECU throws a fault code forty minutes into a two-hour run, a standalone logger just records it. An integrated system can catch it in real time, flag the run, safe the stand, or branch to a different test sequence.
Someone has to merge the data. Every hour an engineer spends aligning spreadsheets is an hour not spent on the actual engineering — and every manual merge is a chance to introduce errors into results people will make decisions with.
What Proper Integration Looks Like
In an integrated system, CAN is just another set of channels. The same application that reads your analog instrumentation also reads — and writes — the network, on a shared timebase, into one dataset.
Concretely, that means the test software speaks the protocol your device speaks: raw CAN or CAN FD, J1939 for heavy-duty and off-highway equipment, OBD-II for light-duty diagnostics, or CANopen on industrial devices. On the NI (now Emerson) platform we typically use NI-XNET CAN interfaces or CAN modules in CompactDAQ and CompactRIO chassis, with the signal database loaded so frames decode to engineering units at acquisition time. Commanding the device — setting operating points, requesting diagnostics, stepping through modes — happens from the same test sequence that controls the rest of the stand, so a complete run needs no one standing next to it.
The payoff shows up in the data: one file, one clock, network signals plotted directly against physical measurements. Questions like “what was the commanded state when that temperature ran away?” stop being reconstruction projects.
When There’s No Signal Database
Standard protocols are the easy case. The harder — and surprisingly common — case is proprietary CAN traffic with no .dbc file and no documentation, because the supplier won’t share it or the knowledge is simply gone. This is solvable: our team has reverse engineered CAN bus communications on vehicle systems, correlating bus traffic against known stimuli until the signals of interest give themselves up. It’s methodical work, but it turns a black-box network into usable test channels.
Repeatability Is the Real Prize
The deeper reason to integrate the network isn’t convenience — it’s variability. When software commands the device instead of a human, every run is the same run. One project we like to point to: instrumenting a test vehicle so that the software controlled acceleration and speed on a test track while the driver only steered. Taking the human foot off the pedal measurably tightened the consistency of the results — the same principle that applies on any stand where an operator is still turning knobs between steps.
We’ve applied the same approach in oil-additive and fluid test systems, where CAN data from vehicle hardware runs alongside conventional instrumentation as part of long, unattended evaluations.
Not Just Automotive
If your product talks J1939, this applies to generators, agricultural and construction equipment, and marine systems just as much as trucks. And the underlying problem — a device under test whose controller data is invisible to the test stand — shows up with Modbus and serial instruments too. The integration thinking is the same even when the connector isn’t.
Getting Started
If you have a test today where network data is being logged separately — or not at all — the first step is small: an assessment of what’s on the bus, what protocol it speaks, and what it would take to bring those signals into your existing test system. Often the hardware change is a single interface card or C Series module; the value is in the software architecture around it.
Dynamic Engineering LLC is a data acquisition system integrator in Cleveland, Ohio, designing and building LabVIEW-based automated test systems since 2008 — including systems that speak CAN, J1939, and OBD-II as fluently as they read a thermocouple. Contact us and tell us what your test stand can’t hear yet.
