Using AI to accelerate rotor balancing throughput and reduce capex by 30%

Excessive rotor balancing runs cost engineering organisations millions per year. When applied correctly, AI models offer a route to improving throughput and reducing cost by up to a third.

It usually starts the same way. You have two rotors from the same family, balanced on the same machine. One clears in two runs. The next takes seventeen.

This isn’t rare: roughly a third of all rotors take five or more runs to clear. Each one of those outliers burns three to five times the balancing-machine time of a typical rotor. And the operator has no way of knowing which rotors will be outliers until several runs have already passed.

It’s an expensive problem that can run into millions of pounds per year. And it's widespread, affecting manufacturers of turbochargers, electric motors, aerospace rotating components, automotive driveshafts and much more!

Lost signal

It happens because of how the balancing machine corrects each rotor. The machine uses a single model that's calibrated as an average for a whole family of similar rotors. The model works for most of them, but falls over on the small fraction that respond differently to imbalance.

However, in most cases, the data required to identify those outliers on the first run already exists! 

A modern balancing machine has an onboard computer that captures the raw vibration signal from its sensors throughout every run. It then calculates a small set of summary measurements from the raw signal, which the balancing algorithm uses to plan the next correction. But despite the initial signal being written to a local file, it’s never used for anything!

The three pillars of success

I’ve worked on projects where a machine-learning model trained on the raw signal from only the first run can identify the rotors that will need many more runs. The model sits alongside the existing balancing algorithm, and the improved balancing throughput avoids capital expenditure on new balancing machines.

Plenty of teams have tried this kind of project and got nowhere, but the model is rarely the cause. It’s almost always the infrastructure. And in my experience three things have to be in place to deliver success:

• Data accessibility: The raw sensor data has to be queryable, in real time, not locked inside the machine in a proprietary format. That could be for instance 100 kHz binary streams direct from production balancing machines, available the moment the rotor starts spinning. If the data still requires a nightly export or a manual pull it’s already a huge problem.
  ‍
• Knowledge base: A generic ML classifier is not enough and physics, engineering hypotheses, and process history have to be integrated into every model interaction. The model should know what the engineering team already knows about how rotors behave, so it starts from the unanswered question rather than rediscovering the basics.
  ‍
• Autonomous execution: The model has to write code, run it against the real data, read the result, and iterate. It should be able to autonomously investigate whether a specific rotor is an outlier.

Put those pillars together and you have an AI agent with full access to live sensor data, grounded in domain physics and engineering expertise, capable of autonomously building and deploying solutions directly to production.

If you're running a balancing line where some rotors take many runs to clear, get in touch. Our team can help.

‍