Your cavity pressure data is already good enough. Nobody's closing the loop.

Walk the floor at almost any injection molding shop running tight-tolerance parts and you'll find cavity pressure sensors installed in the tools. Kistler, Priamus, RJG — take your pick. The data is being captured every shot. Peak pressure, integral, time-to-peak, cushion, fill time. It's on a screen next to the press. Sometimes it triggers a reject gate. Usually it sits in a database nobody queries.

That's the actual problem in injection molding process data right now. Not sensor coverage. Not resolution. The loop back to the machine.

What the research keeps saying

A recent study in MDPI Processes walks through an iterative learning control approach that uses in-cavity pressure sensors to correct cycle-to-cycle variation, converging on stable part quality within a handful of shots after a disturbance. The math isn't new. What's notable is how rarely anything like it is running on a production press. The signal is there. The controller isn't listening to it.

A separate paper in MDPI Polymers goes further and tackles the long-run problem: operating conditions drift, and static quality models degrade. Their answer is drift detection plus incremental learning — retrain as the process moves, don't wait for the model to go stale. Again, sensible. Again, essentially absent from most plant floors.

On the trade side, Tech Briefs has been making the same practitioner argument for years: in-process monitoring reduces scrap and stabilizes quality, but only when the data is actually used to act. Monitoring without action is expensive telemetry.

Why the loop doesn't close

In our experience, three things get in the way.

First, the data lives in the sensor vendor's software and doesn't leave easily. It's viewable per press, not queryable across the fleet. You can't ask "which tools drifted more than 8% on peak pressure last month" without a project.

Second, the people who understand cavity pressure signatures — process engineers, tool techs — aren't the people who write code. So the analysis that would actually change a setpoint stays in someone's head or in a shift note.

Third, closing the loop means letting software nudge the machine. Barrel temperatures, hold pressure, transfer position. That's a governance conversation, not a technical one, and it usually stalls.

What to do this quarter

You don't need ILC on day one. You need the data out of the sensor software and into a place you can query, joined to shot-level part outcomes and resin lot numbers. That alone tells you which tools are drifting, which cavities in a multi-cavity mold are running hot, and which lots correlate with rising reject rates.

Once that's boring and reliable, the control loop conversation gets a lot easier. You have evidence, not a proposal.

The sensors did their job a decade ago. The next decade is about what happens with what they captured.