Telling the operator which dial to turn

A real-time physics digital twin of an extrusion line, and an assistant that recommends the smallest dial change that clears a fault

The extruder digital twin on a laptop at the line: live status, temperature recommendations with the reason for each, and a 3D view of the machine with live data points.

Customer and context

A manufacturer running industrial plastic extrusion — melting polymer granules and forming them into continuous plastic strand. The line described here processes Nylon 66, and the system below runs on it in production.

Extrusion holds three things in tension at once: production speed, product quality and energy cost. Push the screw harder and you may get no more output, only more heat and a larger electricity bill. Let a zone run cold and the melt thickens, pressure climbs, and the line is minutes away from an emergency shutdown. The machine gives little away while any of this happens, because everything worth seeing is inside a closed steel barrel.

The challenge

A factory dashboard tells an operator that something is wrong. It rarely tells them what to do about it.

When a high-pressure alarm fires, the operator has six heating zones and three speed settings to choose between, and no view inside the barrel. The usual response is trial and error — change a dial, wait for the line to settle, see whether it helped. Every attempt risks strand diameter drifting outside tolerance, and the production lost while the line stabilizes does not come back.

The deeper problem is that the alarm reports a symptom, pressure at the die, while the cause usually sits upstream in the thermal profile or the balance between screw and pump.

What Toobler built

Two systems that work as one: a physics digital twin that computes what is happening inside the barrel, and an AI prescriptive assistant that turns that into a specific dial change.

Part one — the physics digital twin

A real-time simulation of the extruder running alongside the machine in the plant. It connects to standard PLC and SCADA registers and reads nine signals:

  • three machine speeds — extruder screw, melt gear pump, take-up puller;
  • six zone temperatures — the three barrel zones, the screen changer, the melt pump body and the die head orifice.

From those it models polymer flow through the barrel and computes ten production KPIs in under 100 milliseconds:

  • Production — throughput in kg/h and line speed in m/min
  • Pressure — die melt pressure, pressure rise across the gear pump, pressure drop across the screen pack
  • Power — motor power draw in kW, and specific efficiency in kg/kWh
  • Polymer — strand diameter, melt exit temperature and viscosity

The power figure is an engineering calculation rather than a meter reading. It accounts for the energy needed to melt the pellets, the mechanical friction of turning the screw through viscous polymer, and transmission losses through the motor and gearbox. That is what puts specific efficiency — kilograms produced per kilowatt-hour — in front of a plant manager continuously, instead of inferred from a bill at the end of the month.

Three machine-protective interlocks sit on top: an overpressure alarm above 135 bar, a pump-starvation warning if suction pressure drops below 10 bar, and a cold-freeze lockout that zeroes flow if any zone falls below 265°C.

Part two — the AI prescriptive assistant

The twin says what is happening. The assistant says what to do about it.

This is the machine-learning half of the system, and the pairing is the architectural point. The physics twin supplies quantities no instrument on the line reports — melt viscosity, specific efficiency, the pressure profile inside a closed barrel — and the model reasons over those, not over raw panel readings alone. An optimiser working only from what the operator can already see would be guessing at the same things the operator is.

It takes eleven inputs — the eight dial settings currently on the operator panel, plus three live physical readings from the twin: die melt pressure, motor power draw and throughput. It returns an action card per controllable dial, among them extruder screw speed and the temperatures at barrel zones one to three and the die head.

The rule that shapes it: the smallest change that works

This is the part most worth copying, and it is a constraint rather than a feature.

Nobody wants a system that rewrites the machine recipe in the middle of a batch. So it was built around minimal disruption, and that shows up in three concrete decisions.

It will not touch the melt pump. The gear pump meters the flow, so its speed governs the production rate. Leaving it alone means a correction cannot quietly cost the shift its output target — whatever else changes, the line keeps making what it was asked to make.

It looks for the smallest sufficient change. If backpressure at the die is high, the first thing it reaches for is a few degrees at the die nozzle to thin the melt at the exit, not the motor speeds or the whole thermal profile.

It says HOLD. Where a zone is already in a healthy range, the recommendation is explicitly to leave it alone. A system that speaks only when it wants something changed teaches operators to distrust its silence; one that confirms a good setpoint is one they can read top to bottom.

Each recommendation arrives as an action card — INCREASE, DECREASE or HOLD, with the recommended value and the reason in plain language. The operator makes the change. The system advises; it does not actuate.

That boundary is the whole reason this is AI a plant will switch on. A model holding the controls is a model that can take the line down, and it has to be trusted completely or not at all. A model that states its recommendation, shows the reading behind it and waits can be overruled by the person whose shift it is — so it only has to be useful, not infallible.

The two faults it clears in production

These are the two conditions the line meets most often, and both now resolve the same way: the twin sees the cause, the assistant names the change, the operator makes it.

Pressure climbing at the die. Tooling cools — a draft across the line, a cold die head — and the melt thickens. Backpressure climbs toward the machine limit, which is where filter seals blow and the breaker plate and die adapter take mechanical stress. A conventional dashboard reports the pressure; it cannot tell the operator that viscosity at the exit is what caused it. The twin is already modeling that viscosity, so the assistant goes straight to a modest temperature increase at the die head. Thinner melt at the exit, pressure back inside its band, no stoppage — and the screw, the pump and the rest of the thermal profile are left alone.

Power rising while output stays flat. An operator runs the screw faster than the pump can meter. Because the gear pump governs flow, the extra screw speed produces no extra output at all — it churns polymer against the pump and turns electricity into heat. Nothing alarms, because nothing is out of range. The line is simply paying more for the same product, and it can do so for a whole shift unnoticed.

This is the fault the twin is uniquely placed to catch, because specific efficiency in kg/kWh is a computed quantity rather than a reading on a panel. The assistant recommends trimming screw speed and warming the barrel zones slightly; drive power comes down and throughput holds exactly where it was.

The first fault announces itself as an alarm but hides its cause. The second never announces itself at all. Neither is solvable from a conventional dashboard, which is the case for having a model of the process rather than more instrumentation on it.

What it watches over a shift

Alongside the live outputs, the twin tracks five health indicators built for trends rather than alarms:

  • Barrel zone uniformity — how far the three barrel zone temperatures sit from each other. The zones are meant to differ, but an unexpected spread usually means a heater band failing, a thermocouple drifting or insulation breaking down, which shows downstream as viscosity variation and surging.
  • Maximum temperature deviation — the single worst control error anywhere in the thermal system at that instant. A worst-case watchdog, because an average will hide one runaway zone, and a single hot spot at the die is enough to cause localized degradation or gels while everything else looks healthy.
  • Screw speed tracking — how closely the drive achieves the commanded speed. Persistent lag points to the motor working against high resistance, often a partially blocked screen or die, which means throughput is not what the panel says it is.
  • Thermal control accuracy — all six control loops rolled into one normalized score, so gradual degradation across a shift is visible without reading six numbers. Normalized by setpoint, so it stays comparable across different recipes.
  • Melt temperature deviation — tracked separately from the rest because melt temperature governs viscosity, and viscosity governs everything after it. Too high and the polymer degrades and discolours; too low and it never fully melts.

Where it runs

The whole system solves in milliseconds on ordinary hardware — a factory PC, a cloud instance, or an IoT edge gateway at the line. That is what makes it practical to run continuously beside the machine rather than as an analysis someone opens after a bad shift.

What this means for manufacturing

The pattern here generalizes well beyond extrusion. A physics model of a process, running fast enough to keep pace with it, turns a closed machine into one you can see inside — not through more sensors, but by computing the quantities that were never directly measurable.

What makes it usable on a factory floor, though, is the restraint layered on top. Industrial AI given free rein over a production line is a liability; one that holds the output rate fixed, changes as little as possible and tells the operator why is something a shift supervisor can actually accept. The engineering that computes the melt flow is the harder half to build. The decision not to touch the melt pump is the half that gets it switched on.

Let's talk about your project.

Start with one measurable use case.

A Readiness Sprint is a fixed-scope engagement that maps your integration and AI readiness and produces a production-oriented plan — before anything is built.