Your own test bench software: control, live visualization and automated test cases

Why your own software instead of a licence model?

Commercial test bench software costs licence fees year after year, and every change goes through the vendor: ticket, quote, waiting. Self-developed test automation reverses the relationship. The software belongs to the operator; a new test procedure, an additional evaluation or a changed report format is an internal task, not a procurement process.

Add a quality argument: software built for exactly one test bench and exactly its tasks stays lean and robust. It does not have to serve a hundred device families and corner cases, but one purpose, reliably, including endurance runs over days and weeks.

What the software does on the bench

At its core it is control and visualization software: it drives setpoints for speed, torque or power, monitors limits and shows all measured quantities live during the run, from torque to temperature.

Test automation builds on top of that, deliberately in two ways: complex sequences with logic and branching are written as Python scripts. Simple setpoint profiles, on the other hand, enter the software as CSV setpoint files, a tabular profile any team member can create in a spreadsheet, without any programming knowledge. Both then run automated and reproducibly.

In the end, what comes out matters: the measurement data is stored and exported in a wide range of formats, from simple tables for a quick look to compact formats for automated evaluation. The results land directly in the tool your development team already works with.

Two speeds: 10 ms day to day, 1 ms when it counts

Live visualization and data storage typically run at a 10 ms cycle, smoother than the eye can follow and more than enough for most evaluations. When details matter, say the settling of a controller or short load peaks, RT logging on the real-time level takes over: it records every detail at the real-time system's cycle time, including all internal quantities of the Linux RT system, 1 ms on our benches. So there is no compromise between a fluid interface and gapless recording; both paths exist in parallel.

A clear architecture makes this possible: the user interface (based on Qt and Python) is strictly separated from the real-time control. The interface may take its time, the control never, and neither disturbs the other.