PLC and computer vision integration, where the model fits next to the controller

The reject arm on the carton line is driven by a PLC that has been in the cabinet since the line was built. It scans its inputs, runs its ladder, writes its outputs, and does it again, every few milliseconds, whether or not anything interesting is happening. When the barcode scanner reports a bad read, a bit goes high, the ladder sees it on the next scan, and the arm pushes the carton off the belt before it reaches the case packer.

A camera over the same belt can see what the scanner cannot: a crushed corner, a label upside down, a carton with no label at all. The question the controls engineer asks is the right one. Where does the model's answer go, and who owns the arm.

The scan cycle is a clock, and the model has to respect it

A PLC does not wait for events. It reads every input, executes the whole program from top to bottom, writes every output, and starts over, and the time that takes is bounded and predictable. That predictability is why the PLC still runs the line and a general purpose computer does not: the arm fires within the same window every time, regardless of what else is going on.

A vision model runs on a different clock. It samples a frame, infers, and produces a result some tens of milliseconds later, sometimes more. If that result is written into a register asynchronously, the PLC sees whatever value is there at the moment of its next read. So the model's answer has to be a value that is valid until replaced, tagged with which carton it belongs to, and the ladder has to be written to treat a stale value as no answer rather than as a pass.

The PLC keeps the arm, and the model is an input

My own view is that the model should never drive an actuator directly, and it is a view most controls engineers hold before anyone from the vision side arrives. The PLC keeps the reject arm. The model is one more input, like the scanner, and the ladder decides what to do with it: reject on a crushed corner, log an upside-down label, ignore anything else. The safety logic, the interlocks and the timing all stay where the plant already maintains them.

That division also keeps the line running when the model does not. A runner that goes offline produces no value, the register holds its default, the ladder treats no answer as no reject, and the line carries on with the scanner alone until someone looks. A model wired to the arm fails differently.

The detection arrives as a webhook into the broker the PLC reads

The mechanism is ordinary. The model watches the belt camera from a runner beside the recorder, and an alert is a rule written as a sentence, with a severity and a cooldown, approved before it goes live: a crushed carton on the outfeed belt, high, delivered to a webhook. The webhook endpoint is a small service on the line network that writes the result into a message broker. The PLC's gateway reads that broker and drops the value into a register, with the carton's position on the belt, the class the model gave it, and the time of the frame.

The alert written as a sentence is the same object that would go to Slack, pointed at a URL instead of a channel. Nothing on the PLC side knows there is a model. It sees a register that goes to a value, on its own clock, the way it sees the scanner.

The same alert can go to Slack too, for the shift lead, with the frame. The PLC gets the value and the person gets the picture.

The line's timing decides what latency the model is allowed

Latency is a line question before it is a model question. On the carton line the camera sees a carton at the outfeed and the reject arm is a belt's length downstream. The belt speed sets how long the model has: the time for a carton to travel from the camera to the arm, less the PLC's scan, less the arm's own stroke. On this line that is comfortably longer than the model needs. On a faster line it would not be, and the fix is the camera further upstream rather than a faster model.

The model is sampled about every two seconds on a monitoring camera. On a reject line the frame is triggered by the carton itself, a sensor on the belt firing the capture, so every carton gets exactly one frame at the same position. Timing that to the belt is the controls engineer's job, and the register's carton identity is what ties the frame's answer to the right stroke of the arm.

The carton line's oldest ladder rung carries a comment from the year the line was built, asking whoever changes it next to leave the reject timer alone.

The model's frames come back to a person, the PLC's do not

What the PLC never does is learn. What the model does, on the frames it doubts, is bring them back to a person: a carton with a corner in shadow, a label at an angle the training frames never showed, a new carton size from the packaging change in spring. Those verdicts are labels, and the next version trains on them.

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 belt camera the line already has, 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 PLC in the cabinet does not notice the version change, which is the point of the register.

Across the manufacturing lines we run, the arm is always the PLC's, and the model is the input that got better while the ladder stayed the same.