BusBench: prove your device speaks Modbus correctly, on every build
BusBench sits on the RS485 bus next to your device under test and plays master or slave. Your Robot Framework test suites decide what it sends and how it answers, so protocol bugs and timing problems show up in the lab instead of at a customer site.
The problem
Modbus testing is usually a laptop and a USB dongle
Modbus is everywhere in industrial equipment, and it is usually tested by hand: a PC, a USB-to-RS485 adapter and a generic Modbus tool. That checks the happy path once. It doesn't check what your device does with a malformed frame, a slow master, an exception response or a register map that changed in the last release, and it doesn't run again on the next build.
Those are exactly the cases that turn into field issues, when your device meets someone else's controller.
What BusBench is for
- Regression tests for the Modbus interface of your device, in your test lab or CI
- Testing a device as a slave, with BusBench as master, or as a master, with BusBench simulating the slaves
- Edge cases that are hard to produce by hand: errors, exceptions and unusual timing
- Repeatable test reports from Robot Framework, a tool your test engineers may already know
How it works
Three boxes, one test suite
A Raspberry Pi 5 runs your Robot Framework suites and drives BusBench over USB. BusBench handles the bus itself, with the timing a microcontroller can give and a PC can't.
Test host
Raspberry Pi 5 running Robot Framework. Configures BusBench, runs the tests and collects the results.
BusBench
STM32U5 fixture running Groundplane. Acts as Modbus master or slave with the register tables you load.
Your device
The device under test, as it will ship. No changes to its firmware are needed.
Status
What works today, and what's next
BusBench is in active development. The foundation under it is mature; the Modbus feature set is growing, and design partners help decide what comes first.
Working today
- Configure BusBench as Modbus master or slave over USB
- Register and coil tables, loaded from the test host
- Modbus RTU frame decoding, with error counters and diagnostics
- Settings that persist across power cycles
- Verified boot and signed firmware updates, from Groundplane
In development
- Response patterns that depend on the flow of a test, such as answering differently after a given request
- RS485 transceiver control
- Baud rates up to 10 Mbaud
- A Robot Framework keyword library
- A real-time tuned Raspberry Pi 5 image (RT_PREEMPT, core pinning) for low USB latency
Early access
Shape BusBench as a design partner
I'm looking for a small number of companies that build or integrate Modbus devices and want to automate their protocol testing. Design partners work with me on the test cases that matter to them and get BusBench early.
What a design partnership looks like
- Early hardware and software, before general availability
- Direct influence on the feature roadmap
- Direct contact with the engineer who builds it
- In return: your real-world test cases and honest feedback