Integrating machine vision with PLC, SCADA, MES and ERP systems

At station 6 on a bracket line, a camera over the weld cell sees a crack in a fillet at 2 am. Four things have to happen, and none of them want the same thing. The reject gate downstream needs to fire before the bracket reaches it. The screen at the cell needs to show the night lead what the camera saw. The production record needs to say which bracket, which station, and when. The report the plant manager reads on Friday needs one number for the shift.

One detection, four consumers.

Most integration projects go wrong in one of two ways: they build four integrations, or they build one and force the other three to live with its shape. Both end with a controls engineer maintaining something nobody asked for.

The PLC needs one bit, decided beside the recorder

The controller that drives the gate reads a tag. It wants a boolean, reject or accept, perhaps a small integer for the defect code, and a heartbeat so it can tell a silent camera from a clean line. A confidence value, a box, a path to an image: ladder logic has no use for any of it, and every extra tag is one more thing the controls engineer owns.

The decision behind that bit has to be made beside the recorder. A round trip to the cloud is the wrong place for a reject gate, because the bracket does not wait for the answer, and because the line has to keep inspecting when the plant's uplink does not. The runner on the plant network is where the model watches the weld camera and where the alert fires first. A small adapter on the same network turns that local event into the tag the PLC reads, and nothing in that path leaves the building.

I would rather a plant ran the gate on a runner with no uplink at all than on a fast link that will drop one night in February. That is a preference, and the controls engineer who has taken the call on that night tends to share it.

The HMI and the SCADA screen need the frame with the box on it

The night lead at the cell needs more than a bit. Which camera, what class of defect, and a thumbnail with the box drawn round the crack, because an alert that says "defect" without the frame is a thing people learn to dismiss. The SCADA layer and the HMI at the line both consume this, and so does the quality engineer's dashboard and the historian keeping the trend.

This is where a publish-once shape earns its keep. The vision side publishes one event with the station, the class, the decision and the annotated frame, and any number of screens subscribe to it. Adding a dashboard or a paging rule next quarter means one more subscriber to an event that already exists, and nobody touches the model or the camera to do it.

The MES needs a record it can hold a unit on

The execution system tracks the bracket through the plant. For it, the crack is a quality event on a serial number: the unit, the station, the defect code, the time, and a reference to the frame rather than the frame itself. Storing images inside the MES bloats a system that was never built for them, while a reference to where the frame already lives keeps the record small and the evidence one click away.

With that record the workflows start on their own. The bracket goes on hold so it cannot ship. If the crack is repairable, the unit is routed to rework. If station 6 produces the same defect code three shifts running, a nonconformance opens and someone looks at the welder rather than the camera.

The ERP needs a shift figure, never a stream of events

Nobody in finance wants a detection. They want first-pass yield for the shift, scrap cost by product family, defect rate by supplier lot. Those are aggregates, rolled up once a day or once a week from the MES or a pipeline beside it. Pushing every crack into the ERP is noise with a licence cost attached.

The discipline is the same at every layer: the consumer gets the shape it can act on and nothing more.

One published event feeds all four consumers

The alert is where the shaping starts. On the platform it is a rule written as a sentence, with a severity and a cooldown, approved before it goes live: a crack on the weld camera at station 6 is critical, the same class on the pre-weld camera is routine. Delivery is Slack, email or a webhook, and the webhook is the shape the rest of the plant consumes. The adapter that writes the PLC tag, the publisher the screens subscribe to, and the record the MES keeps all hang off that one delivery.

LexData takes the weld 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 the plant already has, on the runner beside the recorder or on your servers. 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. When the new version rolls out, the four consumers do not notice, because the event they subscribe to has not changed shape.

Doubted welds go to a person, and the verdicts retrain the model

Some fillets are neither a clean crack nor a clean pass. Those frames should never go straight to the gate. They come back to a person, the person's verdict is a verified label, and the correction is what the next training run is built from. The manufacturing case behind our numbers holds 99%+ accuracy maintained in production for exactly this reason: the doubted frames keep landing and keep being corrected.

That review queue is also the drift signal. When the night lead starts overriding the model on the same class in the same direction, the override rate is what tells you something on the line changed, whether a new supplier's bracket or a lens that has picked up spatter. When corrections cross the project's threshold a new version trains on them. When overrides step up overnight, we check the change log before anyone retrains, because a step is usually a pipeline event and a revert beats a retrain.

A controls engineer who keeps the heartbeat tag on a strip chart on a second monitor learns to read a camera outage from the shape of the trace before the alert arrives. It is hard to name a dashboard that beats it.

Start with the layer that pays and add the rest as subscribers

Not every plant has an MES, and that should not stop the camera going on the weld cell. A line with a PLC and an HMI gets the gate and the screen on day one, and the record and the yield figure arrive when the plant's systems do. The one thing to decide early is the shape of the event, so that adding the MES later is a subscriber rather than a rewrite.

If the goal is stopping bad brackets, start with the runner and the tag. If it is visibility, start with the published event and the screens. Most lines end up with all four, and the order matters far less than making the model's output one event that each layer reads in its own shape. The deployment doc covers where the runner sits and what leaves the site, which for a weld cell is a decision, a count and an alert, never the footage.