Injection Molding Monitoring with IoT: Catch Defects Shot by Shot

Injection molding monitoring means capturing the process fingerprint of every shot, not just counting parts. This use case shows how to publish per-shot cycle time, cushion, pressure and temperatures over MQTT, compare each shot against its own recent history and alert the team when the process starts to drift. The result is earlier detection of short shots, flash and dimensional problems, with a clear record of what the process looked like when each part was made.

Why Shot-Level Data Matters in Molding

An injection molding machine is very good at repeating itself, until it is not. Material moisture changes, a heater band fails, a check ring wears, or the mold warms up after a stop. Each of these shows up first as a small shift in a process value, often several shots before a visible defect. Plants that only check parts at the end of the hour find the problem after dozens or hundreds of parts are already in the box.

Shot-level monitoring changes the timing. When each cycle publishes its values, a subscriber can compare the current shot with the last 50 and react within one cycle. It also gives quality engineers evidence: when a customer complaint arrives, you can look up the process data for that lot instead of guessing.

The Process Values Worth Capturing

Machines expose dozens of values. These are the ones that most often explain defects:

Start with cycle time, fill time, peak pressure, cushion and recovery time. They come from the machine controller on every shot and together catch most process drift.

Getting Data Off the Machine

Modern machines usually offer one of these interfaces:

• OPC UA per the Euromap 77 companion specification. Many newer machines provide a standardized information model for cycle parameters. An OPC UA client at the edge subscribes to the cycle values and publishes them to MQTT when a new cycle completes.
• Older Euromap interfaces or vendor protocols. Some legacy machines expose shot data through file-based or proprietary interfaces. A gateway reads them and normalizes the data.
• Retrofit sensors. If the controller offers nothing, add a cycle signal from the mold-open output plus thermocouples or a mold temperature reading through a small PLC or ESP32. You lose pressure curves but still get cycle time and temperatures.

The industrial IoT with MQTT guide explains the gateway pattern in general. The key point here is to publish one complete message per shot, triggered by the end of cycle, not a stream of values sampled on a timer.

Message Design: One Shot, One Message

Use a topic per machine and a payload that carries the shot number, mold and material so every record is self-describing:

connectmq/demo/<your-id>/plant1/molding/imm07/shot

{
  "shot": 48211,
  "mold": "M-2231",
  "material": "PP-H 12 MFI",
  "cycle_time": 18.42,
  "fill_time": 0.86,
  "peak_pressure": 1065,
  "cushion": 4.8,
  "recovery_time": 6.1,
  "barrel": [205, 215, 225, 230],
  "mold_temp": {"fixed": 41.2, "moving": 43.0},
  "ts": "2026-10-16T08:21:44.120Z"
}

Keep units consistent across machines (seconds, bar, millimetres, Celsius) and document them once. Publish with QoS 1 so a short network hiccup does not lose shots; the gateway buffers and the broker acknowledges each message. If your plant already uses Sparkplug B, ConnectMQ can decode it and republish into ISA-95 topics, so a molding cell does not have to change its native format.

Detecting Drift Shot by Shot

The subscriber below keeps a rolling window of recent shots per machine and flags any value that moves more than three standard deviations from the window mean. It is intentionally simple: no model training, just the machine's own recent behaviour as the baseline. It publishes flagged shots to an alert topic that a dashboard, andon light or messaging tool can subscribe to.

import json
import statistics
from collections import defaultdict, deque

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/r5t1w8/plant1/molding"
WATCH = ["cycle_time", "fill_time", "peak_pressure", "cushion", "recovery_time"]
WINDOW = 50
MIN_SHOTS = 20
SIGMA = 3.0

history = defaultdict(lambda: {k: deque(maxlen=WINDOW) for k in WATCH})


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/+/shot", qos=1)


def on_message(client, userdata, msg):
    machine = msg.topic.split("/")[-2]
    shot = json.loads(msg.payload)
    issues = []
    for key in WATCH:
        value = shot.get(key)
        if value is None:
            continue
        window = history[machine][key]
        if len(window) >= MIN_SHOTS:
            mean = statistics.fmean(window)
            sd = statistics.pstdev(window) or 1e-9
            z = (value - mean) / sd
            if abs(z) > SIGMA:
                issues.append({"param": key, "value": value, "mean": round(mean, 3), "z": round(z, 1)})
        window.append(value)
    if issues:
        alert = {"machine": machine, "shot": shot.get("shot"), "mold": shot.get("mold"), "issues": issues}
        client.publish(f"{PREFIX}/{machine}/alert", json.dumps(alert), qos=1)
        print("ALERT", alert)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="molding-watch-r5t1w8")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

A few tuning notes from practice:

1. Clear the window when the mold or material changes, otherwise the new job is judged against the old one. Compare mold with the last shot and reset on change.
2. Ignore the first shots after a stop. Mold and barrel need time to stabilize, and those shots are often scrapped anyway.
3. Some parameters deserve fixed limits as well. A cushion near zero is a problem even if it has been creeping slowly, because the rolling mean follows slow drift. Pair the statistical check with absolute limits from the process sheet.
4. Do not alert on every flagged shot. Require two of the last five shots out of range before calling someone, or the alerts will be muted within a week.

For a deeper look at control charts and run rules, see real-time SPC.

What the Team Does with the Data

Monitoring only pays off when it changes behaviour on the floor. Typical workflows:

• Setters get an alert on the cell's andon light when cushion or fill time drifts, and check material drying and the check ring before scrap builds up.
• Quality links shot data to lot numbers and can quarantine only the affected time window instead of a full shift's production.
• Production planning uses actual cycle times per mold instead of quoted ones, which makes schedules and quotes more realistic. The cycle time monitoring article goes deeper on this.
• Maintenance watches slow trends such as recovery time and barrel heater duty to plan screw and heater work.

Cycle and state data from the same machines also feed OEE: shot count gives output, cycle time gives performance, and flagged shots approximate quality loss.

Running It Beyond the Pilot

The public broker at broker.connectmq.com is fine for proving the idea with a simulator, but its public area is readable by anyone, and molding parameters are process know-how you should not share. For the real cell, create a private broker on ConnectMQ and connect each gateway with its own username, password and client ID over TLS on port 8883. A fully managed MQTT service means nobody on the plant team has to maintain the broker, and running it as an MQTT broker in the cloud lets the corporate quality team see the same shot data as the plant. The portal's threshold alert rules can cover the simple absolute limits, while the statistical check runs in your own subscriber. For where this fits in a wider program, read the smart manufacturing guide.

Get Started with ConnectMQ

Create a free broker at app.connectmq.com on the Serverless plan with no credit card, connect one molding machine's gateway and the drift subscriber, and see your first shot-level alerts this week.

Frequently Asked Questions

What is the most useful single value for injection molding monitoring?

Cushion and fill time together catch a large share of process problems, because they reflect both shot consistency and material viscosity. Cycle time alone tells you about productivity, not quality.

Should I stream full pressure curves over MQTT?

Usually not at first. Summary values per shot are small and cover most needs; capture full curves only for critical parts, and keep them within your broker plan's message size limit.

Can older machines without OPC UA be monitored?

Yes. A mold-open signal gives cycle time and count, and added thermocouples give temperatures. You publish fewer values, but the MQTT pipeline is identical.

How do I avoid false alarms after a mold change?

Reset the rolling baseline when the mold or material changes and skip the first stabilization shots. Combine statistical checks with fixed limits from the process sheet.