Skip to content

Multi-Channel Motor Control — Firmware Test with Simulated Drives

Drives and sensor feedback simulated as the counterpart; validation moved from real drive hardware into an automated CI/CD pipeline.

Industry: Manufacturer of mechatronic devices with multi-channel motor control (up to eight drives per controller).

The challenge

The control and sequencing algorithms are developed in Python and then ported to C/C++ firmware on the MCU. Validation previously required the real drive hardware — heavy-load tables and motors.

  • A complete drive cycle takes a long time to run; the setup is large and cumbersome to handle.
  • Tests run mostly serially, one unit after another.
  • Corner-case, load and stress tests tie up additional manual bench time.

The LoopCheck solution

A test board adapted to the controller reproduces the drives and sensor feedback as the counterpart. The motor model runs in real time (microsecond time steps) on the test controller, and the customer MCU is connected through its real interfaces and tested against the model.

A LoopCheck adapter board configured for drive and sensor emulation

  • Drive simulation — current profile and mechanical behavior are adjustable via parameters.
  • Python control — parameters and load torques are set at runtime; test runs execute automatically on every commit.
  • Extensible — the customer adds their own test logic and has built their own operating GUI on top.

Reproducing non-ideal effects

The relevant non-ideal effects are reproduced deterministically and can be extended by the customer: end-stop variants and mechanical stops, the current profile within the PWM phase matched to real inductance and parasitic effects, hard load changes, mechanical backlash and non-ideal pulse encoders.

Tested interfaces (counterpart)

High-level overview of what the counterpart emulates and measures:

  • Motor drives (H-bridge PWM) with per-drive current sensing
  • Position feedback (quadrature encoders and potentiometer)
  • Additional application-specific PWM signals
  • Safety edge / switching strips
  • RS485 / Modbus and RS232 serial links
  • Acoustic signal (buzzer) capture for long-run test points

Result

  • Development desk

    Tested at the development desk instead of on real drive hardware.

  • Parallel

    Several units under test at once, instead of serially.

  • CI/CD

    Automated test runs on every commit.

Related: Workflow integration · Cyber Resilience Act · All reference projects