Building an 8-Motor Motor Control Center Hardware-in-the-Loop Rig

Part 2 — What we actually achieved, what the whole project taught us, and where it goes from here.

Siemens S7-300 · BeagleBone Black · Nucleo-F446RE · STM32F429I-DISC1

Part 2 of 2 — Part 1 covers goals, architecture, and the debugging journey

Where it landed

After every layer described in Part 1 was found, fixed, and re-verified, the rig reached a state that’s genuinely end-to-end validated rather than validated-in-pieces:

simulated motors, 5–50 HP

fault types tested per motor

independent protection layers

~5s

end-to-end command latency

30+

real bugs found & documented

live operator dashboard

Every motor has been started, stopped, and driven through overcurrent, thermal, phase-loss, and short-circuit fault injection, with both the PLC’s FB chain and F446RE’s independent hardware layer confirmed to react — at their own, deliberately different thresholds. The dashboard reflects Start/Stop state within about 5 seconds end-to-end (browser click through the PLC, through the physics model, and back), fault indication animates live on the motor card that’s actually affected, and the SQLite historian now genuinely holds what the dashboard displays, closing out the invalid-query bug from Part 1.

The rig has moved from “does the wire work” through “does the logic decide correctly” to “does the whole loop — PLC, physics, dual protection, and operator console — agree with itself under fault conditions.” That’s the actual bar a real MCC has to clear, and it’s the bar this project was built against.

What the whole project taught us

A handful of lessons showed up over and over, in different disguises, across every layer of the system — controls logic, physics modeling, data handling, and low-level firmware alike. These are the ones worth carrying into the next project, not just this one.

Silent failure is the single most expensive pattern in the whole project. The relay that never called its own protection logic, a UART path that quietly did nothing on certain replies, a SQL error swallowed behind a plausible-looking fallback, pre-blend values logged as if they were final — all of these hid real, wrong states for days at a time. Every one of them got fixed by adding loud, specific diagnostics in place of quiet ones.

Proving the pipe works is not the same claim as proving the receiver acts on it. The UART chain round-tripped perfectly for an entire debugging session while the code on the receiving end never once acted on what arrived. Verify both, separately — a passing wire test proves nothing about the logic downstream of it.

Shared resources need an owner registry. A stale diagnostic network’s leftover timer address, a duplicated variable table, an address reused across two motors’ logic — every one of these traced back to the same root cause: an address used twice, unknowingly. A STEP7 cross-reference check before assigning any new timer or memory bit is now a mandatory step, not an optional one.

Measure the real system; don’t trust the design target. A loop specified for 100 ms actually ran at 420 ms. A 250 ms pulse went completely unsampled by the polling code watching for it. A clock silently drifted and time-stamped data from the future. In every case, what the system was supposed to do and what it was actually doing had quietly diverged, and only direct measurement caught it.

Test evidence beats plausible reasoning, every time. A timer misdiagnosis looked completely reasonable on paper — inverted logic, a clean explanation, a clean fix — and was wrong. It was corrected the same day by video evidence of an unaffected motor behaving correctly under the “wrong” logic. When evidence and theory disagree, trust the evidence and go find out why the theory was wrong.

Ask for the literal file, not the one you assume matches it. Comparing the real, currently-loaded IDE source against a reference copy — rather than trusting memory of what should be there — caught the project’s single most consequential bug (the relay that never protected anything) and closed out several other investigations outright.

Realistic physics changes what “correct” protection logic even means. Idealized fault injection alone never would have surfaced the DOL starting-inrush nuisance-trip bug — it took a physically realistic motor model, with real starting current behavior, to expose that the protection thresholds had only ever been validated against artificial fault values, never against the system’s own normal operating transients.

What’s planned next

The rig as it stands validates protection and sequencing logic convincingly. The next phase is about deepening that into something closer to an industrial-grade digital twin platform, and about broadening the motor-control depth beyond direct-on-line starting alone.

Phase 2 · Motor Object Library

Parameterized starting methods: DOL, reversing, star-delta, soft starter, VFD

Replacing the single hardcoded DOL physics model with a strategy-pattern library covering five real industrial starting methods, each with its own current/timing profile and its own protection-coordination requirements — generalizing the existing 3-second start-inhibit fix into a per-method configuration instead of one fixed timer.

Phase 2 · System Modeling

Formal control-systems modeling on top of the physics engine

Moving from an empirical slip-current blend to a derived equivalent-circuit model, a linearized transfer function, and a closed-loop PI speed controller for the VFD starting method — Bode plots, step response, and root locus analysis, not just simulation.

Phase 2 · Real hardware FOC

MCSDK-based field-oriented control on the existing Nucleo-F446RE

Adding a motor control expansion shield and a small test motor to run ST’s Motor Control SDK — automated system identification via the Motor Profiler, tuned current and speed control loops on real PMSM/BLDC hardware, and optionally a telemetry bridge back into the existing dashboard as a genuine physical-twin motor card.

Digital Twin roadmap

Industrial protocol integration and predictive capability

An OPC UA server and MQTT telemetry egress so the rig speaks the protocols a real plant historian/SCADA system expects, followed by anomaly detection and eventually remaining-useful-life estimation built on the historian data this rig already generates.

Platform hardening

Test automation, authentication, and functional-safety documentation

A pytest-based hardware-in-the-loop test harness automating the fault-injection sequences that are currently run by hand, dashboard authentication ahead of any remote-access work, and a lightweight HARA/FMEA writeup formalizing the dual-protection-layer design’s safety reasoning.

Every item above will get the same treatment as everything already built: a versioned file, a changelog explaining the real problem that drove it, and a debug log entry for whatever goes wrong along the way — because in this project, the wrong turns have consistently been as instructive as the working result.