Getting a defect record into the MES without touching the PLC

The welding cell on the east side of the plant produces a bracket about once a minute. The arm welds it, the fixture releases it, and the part slides to an outfeed where a camera sees the bead and the machined face for a few seconds before the next one arrives. On a Thursday morning the model flags a gouge on the machined face of a part on work order WO-4471. The quality engineer needs that as a record against the work order in the MES, with the picture attached, by the time the batch is reviewed. The reject arm at the outfeed needs nothing from the MES at all.

Those are two different paths, and keeping them separate is most of the design.

A REST call is a request the MES answers

The plant's MES exposes a handful of URLs. One returns the work order currently at a cell. One accepts a quality record against a work order. A REST call is a request to one of those URLs with a small JSON body, and the response is a status code and, usually, the record as the MES stored it. There is no session to hold open and no protocol to learn beyond the ones the plant's own systems already use.

Plants run three layers of communication, and REST lives in the top one. The PLCs and their I/O talk to each other in cycles measured in milliseconds. The supervisory layer collects tags. Above both, the MES and the ERP trade transactions such as work orders and quality events, and a transaction that arrives a second late is still a correct transaction. A defect record is a transaction.

The vision inspection system posts the record, the PLC rejects

An alert in LexAlert is a rule written as a sentence, with a severity and a cooldown, approved before it goes live: a gouge or a crack on the machined face at the east cell outfeed, to the quality channel and to a webhook. The webhook is the vision inspection system's side of the integration. It posts the event to a small service on the plant network, and that service calls the MES endpoint with a quality record for the work order at the cell. The monitoring and alerts guide covers what the webhook carries.

The reject arm never waits for any of that. It is wired to the PLC, and the PLC gets its signal by the path the earlier posts in this series describe, a message on the plant broker or a tag the PLC reads. An HTTP round trip through the MES has no place in a decision the arm has to make before the next part arrives, and if the MES is slow on a Thursday morning, the arm must not be.

A quality record is a fact about a part. A reject is an action on a part. They share an event and nothing else.

The record carries the work order, frame and model version

The service that posts the record has one lookup to do first: which work order is at the east cell right now. The MES knows, and a request to its work order endpoint returns WO-4471. The record then carries that work order, the cell and camera, the class the model found, the time, a link to the frame with the box drawn on it, and the version of the model that made the call.

The model version is the field people leave out and regret. Three months later the quality engineer will ask whether the gouge rate rose in June because the machining changed or because the model changed, and the version in each record is the only way to answer. The surface defect detection use case is a severity call, and severity on a bracket is size and location on the face, so the record also carries the box coordinates rather than only the class.

The frame link should point at storage the plant controls, because the record will outlive the alert.

An event id makes the record safe to send twice

Networks fail during the post. The service sends the record, the MES stores it, and the acknowledgement is lost, so the service sends it again. Without an event id the work order now shows two gouges on one bracket, and the batch review the following week argues about a part that was flagged once.

My view is that the event id should be the record's key and the timestamp should never be. The alert carries an id from the moment it fires, the service uses it as the idempotency key on the post, and the MES treats a second record with the same id as the same record. A retry is then safe by construction, and the service can retry on a schedule until the MES answers, without anybody reasoning about duplicates.

The service also needs to fail loudly in one direction. An MES that answers with an unknown work order, because the cell changed over between the lookup and the post, should produce an error a person sees, in the quality channel, with the frame, rather than a record filed against the wrong batch.

The quality engineer reads the records against the shift

Once the records exist, the batch review changes shape. The gouges on work order WO-4471 sit beside the machining parameters, the operator on shift and the material lot, in the system the quality engineer already opens every morning. Nobody exports a PLC log. Nobody asks the vision vendor for a report. On the manufacturing lines we run, the figure that holds is 99%+ accuracy maintained in production, and the records are how the plant checks it against its own scrap.

The quality engineer's disagreement with a record is also the correction. A gouge that was a reflection off the coolant comes back for review, and the reviewer's verdict is a label.

LexData takes the outfeed 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 outfeed camera, 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. The record on work order WO-4471 keeps the version number of the model that made it, and the next version writes its own.