Getting a defect detection to the PLC over MQTT

The camera over the case packer on line 3 sees a crushed carton at 2:40 pm. The model is sure of it, and the frame with the box drawn on it is already on its way to the line lead's Slack channel. The reject arm that could push the carton off the belt is wired to a PLC that has never heard of a vision model. Between the two sits a broker that has been on the plant network for years, carrying the energy meters and the andon displays.

The question is how the defect flag gets from the model to a ladder rung without anybody writing an integration that only one person understands.

The model joins the plant's broker as one more client

MQTT is a publish and subscribe protocol. A client publishes a small message to a named topic on a broker, and every client subscribed to that topic receives it. Nobody polls, nobody holds a connection open to anybody but the broker, and a device that drops off the network picks up where it left off when it returns. Most plants running anything newer than a serial line have a broker somewhere, often installed for the meters and forgotten.

The vision side does not need to know any of that. An alert in LexAlert is a rule written as a sentence, with a severity and a cooldown, approved before it goes live, and one of the places it can be delivered is a webhook. The webhook carries the event as a small JSON payload with the camera and the class in it, the time, and a link to the frame. A broker with an HTTP publish endpoint takes that as it arrives.

A broker without one needs a bridge of a few lines on the plant network that receives the webhook and publishes it, which is the one piece of custom code in the whole arrangement, and it does one thing.

The monitoring and alerts guide covers the webhook side. Everything after it is the plant's own plumbing.

A topic per line and camera keeps each PLC apart

Topics are paths. A reasonable layout for a plant puts the site first, then the line, then the camera, then the kind of event, so the case packer's camera publishes to something like plant/line3/casepacker/defect and its neighbour over the labeller publishes to plant/line3/labeller/defect. The PLC for line 3 subscribes with a wildcard on the camera segment and sees every defect on its line and nothing from line 4.

The same layout gives each camera a count topic and a defect topic, and a health topic beside them, each carrying a different kind of message. The count is a number that updates every few seconds. The defect is an event with the frame link. The health message says the camera is connected and the model is watching it, and the broker can retain the last one so a screen that connects at 6 am shows the state without waiting for the next message.

A topic scheme is the only part of this worth arguing about in a meeting, because renaming a topic later means touching every subscriber.

The delivery guarantee follows what the message does

MQTT lets the publisher choose how hard the broker tries to deliver each message: at most once, at least once, or exactly once. The choice belongs to the message, and the three kinds of message in this post want three different answers.

A count can be lost. The next one arrives a few seconds later and nobody will miss the gap, so at most once is right and cheap. A defect flag should arrive, and the cost of a duplicate is low if the payload carries an event id the subscriber can use to drop the second copy, so at least once is the working default. A message that a PLC will act on with a stop, if the plant ever chooses to publish one, is the one place exactly once earns its handshake.

The energy meters on the same broker have been publishing at most once for years, which is why the broker's operator will suggest that for everything. For the counts, they are right.

The SCADA screen subscribes to the same topics

The plant's SCADA layer is another subscriber. Its gateway takes the defect topic and the count topic and turns them into tags beside the ones it already holds for belt speed and reject count. The crushed carton at 2:40 pm shows on the same screen and lands in the same historian as everything else on line 3. Nobody builds a second dashboard for the camera.

That is also where the number becomes useful over time. A defect count per hour per camera, in the historian, beside the changeover log and the shift pattern, is what a quality engineer needs to see that the crushed cartons cluster after the 2 pm changeover. On the manufacturing lines we run, the accuracy figure that matters is 99%+ maintained in production, and it is maintained because somebody is looking at the count against its own history rather than at the model in isolation.

The camera's messages are a few hundred bytes. The historian will not notice them.

The reject decision stays in the PLC

My view, and not every integrator shares it, is that a vision model should never be the thing that stops a line or fires an actuator. It should be the thing that tells the PLC what it saw. The PLC reads the defect flag as one more input, checks it against the interlocks and the timing it already owns, and decides whether the reject arm fires on this carton or the next one. If the broker is down, the PLC's logic is unchanged and the line keeps running, which is the whole reason the decision lives there.

Written that way, the message from the camera is advisory and the PLC is the authority, and the plant's safety case does not change because a camera was added. The model's job is to be right about the carton. The controls engineer's job is unchanged.

MQTT was designed in 1999 to carry pipeline telemetry over satellite links that dropped for minutes at a time. That is why a plant network hiccup does not lose a message, and why the protocol fits a factory wired long before anybody put a model on a camera.

The person gets the frame, the PLC gets the flag

The same event goes two ways. The flag with the event id goes to the broker, where the PLC and the SCADA screen read it. The frame with the box drawn on it goes to the line lead, who can see in one glance whether the model was right. When it was wrong, the line lead's correction is the signal the loop acts on.

LexData takes the carton model through its whole life. You type what to look for, Lexi puts a box on every frame, and a person checks each label before anything trains on it. The model then watches the cameras over the line, in the cloud, on your servers, or on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime.

With the runner beside the recorder, the alert fires on site first, the webhook reaches the broker over the plant network, and the footage never leaves the building. The deployment guide describes that arrangement, and the broker's operator will recognise it as one more client on the network they already run.