High-Speed Can Inspection & Traceability

The challenge

A seafood cannery fills and packs cans under a number of different brands on the same lines. Each can carries a four-character product code stamped into the bottom during filling, a UPC on the label applied afterward, and a barcode on the shipping carton it ends up in. Those three codes have to agree: the right label on the right can, in the right carton. When they do not agree the result is a product mix-up, and a mix-up in food packaging means a recall and a damaged brand.

Reading that can code is harder than it sounds. It is inked onto a curved, shiny can dome, so contrast is poor before anything else goes wrong. The ink smears. Cans arrive spinning, so the code lands at a different angle and a different distance from center on every single can, and some roll far enough off-center that no system could read them. And the line moves fast. The plant's existing code reader was inconsistent enough that operators could not trust it, and the false failures it threw were a production problem in their own right.

Proving it before building it

Rather than sell a system and hope, we ran an engineering study on the live line. Two approaches were installed and run side by side in real production for three weeks: a conventional rules-based OCR camera, and a deep-learning reader trained on the plant's own can codes.

Every failure was pulled apart into three kinds, because they are not the same problem. A location reject is a code that rotated too far off-center for anything to read. A missing or unreadable code is smeared or absent ink, which a person could not read either. A false failure is a code that was perfectly legible and the system should have read. Only the last one is the vision system's fault, and separating them is the only honest way to know what you are buying.

The deep-learning reader handled the plant's print variation better than the rules-based approach, and it did so having been trained on just three days of codes. More training data would only sharpen it further.

What the trial actually measured

These are results from a single day of live production during the study, not a lab estimate:

• Cans read in one day269,190
• False-reject rate0.0784%
• Errors or skipsNone detected

The rest of the rejects were real: codes rotated out of view, or ink too smeared to read. Those are process and printer problems, and knowing the difference tells the plant which ones to go fix.

What we designed

The study pointed to one line-side system rather than three disconnected cameras. Three inspection points, the code on the can bottom, the UPC on the applied label, and the barcode on the shipping carton, report into a single controller, so the codes are checked against each other instead of each being judged in isolation.

Changeovers run from a recipe. Each recipe ties a bottom code to its label UPC and its carton barcode, and recipes load from a file or by scanning a code, so switching brands does not mean re-teaching a camera. The controller talks to the plant's PLC over EtherNet/IP, and an enclosure holding the PLC, an industrial PC, and a 15-inch HMI puts the system line-side where the operator actually is. Images and running statistics are saved for review.

The trial also produced a set of unglamorous requirements. Over three weeks, can crashes knocked the trigger sensors out of alignment and destroyed a light outright, and dust settled on the optics. So the production design encloses the cameras and lighting and moves the sensors onto the conveyor itself. A system that cannot survive the line is not a system.

Capabilities used

Machine vision, deep-learning OCR, barcode verification, on-line engineering studies and production trials, PLC and HMI integration, recipe-driven changeover, and control panel design.

On the line