Here’s a fun one. A transmission controller sitting on a test bench is a suspicious thing. It won’t shift the way it does in a real vehicle unless it’s convinced it is in a real vehicle — engine running, sensors live, the whole electrical world around it behaving normally. Get any of that wrong and it does what a good controller is supposed to do: it decides something is broken and refuses to cooperate.
Our job was to convince it otherwise. This is the kind of work behind our cRIO and cDAQ programming services, and it’s a good example of why we so often reach for an FPGA when the timing has to be exactly right.
The setup: a restbus simulation
The technique has a name in this corner of the industry — restbus simulation (or residual bus simulation). The idea is that the component you’re actually testing normally listens to a whole network of other controllers. On the bench, those other controllers don’t exist, so you simulate the “rest of the bus”: you broadcast the CAN messages the unit under test expects to hear, so it behaves as if it were fully installed in the vehicle.
For a transmission, the most important of those messages is the one that says the engine is alive and running. Without it, the transmission has no reason to shift.
The real trick: exactly 50 milliseconds, every time
Broadcasting that engine message sounds easy until you learn the tolerance. It had to go out every 50 milliseconds — not “about” 50, not “on average” 50, but 50, consistently, with very little margin for error. Real engine controllers broadcast on a tight, rock-steady period, and a transmission is watching that cadence closely. Let the interval wobble and the transmission concludes the engine isn’t behaving like a real engine, and you’re back to a controller that won’t shift.
That is a brutal requirement for a normal PC. Time the message in software and it’s flawless on the bench — until the application does something else for a moment, or the operating system slips in a task of its own, and one interval quietly stretches. On a signal that has no margin, one stretched interval is a failure.
So we didn’t ask the PC to keep time. We put the cadence on the FPGA in a CompactRIO, where a hardware timer holds 50 milliseconds to the microsecond no matter what the rest of the system is doing. Deterministic timing is the entire reason the trick works.
The part that made shifting actually correct
Steady timing alone would have produced a convincing but dumb engine — one broadcasting the same canned numbers forever. That’s not enough to get correct shifting, because the transmission’s decisions depend on live conditions.
So we did the interesting part inside the FPGA itself: we pulled several analog input (AI) and digital input (DI) signals straight off the bench hardware and folded them directly into the outgoing CAN message, in real time, right where the message was assembled. The values the transmission received weren’t a script — they reflected what was physically happening on the bench at that instant. That real-time integration of live signals into a perfectly timed message is what got the transmission shifting correctly instead of just idling politely.
Reading the signals and building the message in the same deterministic place on the FPGA is what kept everything coherent. There was no round-trip up to the host and back, so the data in each frame was fresh and the frame still went out exactly on schedule.
A few LabVIEW FPGA tips from work like this
If you build something similar, a handful of habits pay off:
- Put anything timing-critical on the FPGA and keep higher-level logic on the host. The FPGA should be your metronome; let it be uninterruptible.
- Use a tick-based hardware timer for your period, not a host loop. Counting FPGA ticks gives you a cadence that doesn’t drift; leaning on host timing reintroduces exactly the jitter you’re trying to eliminate.
- Acquire and assemble in the same place when freshness matters. If live signals have to appear in an outgoing frame, reading them on the FPGA next to where you build the frame keeps the data current and the timing intact.
- Prefer fixed-point over floating-point math on the FPGA. It’s lighter on resources and compiles smaller and faster, and most bus-level work never needs floating point.
- Log the real send timestamps back to the host. Being able to see the actual interval between frames turns “is it in spec?” into a five-minute check instead of a debate.
Why we don’t stop at “it worked”
Getting a transmission to shift on a bench is satisfying engineering, but it isn’t the whole job. A system like this runs for years, and the people who live with it usually aren’t the ones who built it. So we hand off readable, source-controlled code, documentation that explains why and not just what, and enough of a walkthrough that a client’s own team isn’t dependent on us forever.
And when something does come up later — a new signal to add, an odd trace, a question late on a Friday — we pick up the phone. Responsive support after delivery isn’t a line item we add to a proposal; it’s most of the reason clients come back for the next project.
Have a timing-critical bus or bench problem?
If you’re working on CAN/J1939 communications, a restbus simulation, an FPGA timing challenge, or any test system where “usually works” isn’t good enough, our team can help. Learn more about the engineer behind the work on our About page, or contact Dynamic Engineering to talk it through.
Joseph “Joe” Zarycki is the owner of Dynamic Engineering LLC, an automation and controls engineering firm serving the Cleveland, Ohio area since 2008, specializing in LabVIEW, FPGA and cRIO/cDAQ programming, custom test stands, and data acquisition systems.
