Why does JM Automated Solutions use deep learning OCR for packaging codes?

What is OCR on a packaging line?

OCR, optical character recognition, turns the characters in an image into text the system can check. On a packaging line it reads things like:

• Packer codes and lot and date codes on can ends
• Three-letter variety codes on bright-stack cans
• Product and lot codes printed on labels

Reading is half the job. The system then checks what it read against what it expected, usually the product and lot the plant's MES says should be running. That second step is what catches a wrong code.

How does rule-based OCR work?

Rule-based OCR follows steps someone sets up: find the text line, split it into individual characters, then match each character against a trained font. It works well on clean, consistent print. It struggles when the print itself varies: characters that touch or break apart, ink that is faint or smeared, embossed characters on shiny metal, or a code that lands at an angle^[1].

Each of those cases usually means retuning segmentation or retraining the font, and a new code format or a new printer can mean doing it again.

What does deep learning OCR do differently?

A deep learning OCR tool comes pretrained on a large set of real-world images: many fonts, marking methods, surfaces and angles^[2]. Instead of following a fixed set of rules, it recognizes characters the way it learned to from those examples.

In practice, that means it outperforms rule-based methods on degraded or low-contrast codes and requires no per-code training. A faint inkjet code, an embossed code on a reflective can end, or a slightly skewed label code reads without someone building a new font for it. Vendors now ship it as a standard tool; Zebra, for example, publishes reads on date and lot codes at up to 900 products per minute with its pretrained OCR^[2].

What is the difference between reading and verifying a code?

Reading, OCR, answers "what does this code say?" Verifying, often called OCV, answers "is this the code that should be here?" A line needs both. The system reads the characters, then compares the result with the expected string for the running product and lot.

That comparison is where most wrong-product errors are caught. A code that reads perfectly but belongs to the last order is still a fail, and a code that can't be read at all is treated as a fail too, never as a pass.

How fast is it?

It reads in milliseconds, fast enough to keep up with production. Across JM Automated Solutions systems, 1,200 cans per minute is the ceiling for code-reading tasks like OCR; a given line can run slower depending on lighting and print quality. A typical strobed exposure is about 60 microseconds, which freezes the code before the OCR ever sees it.

Where does JM Automated Solutions use it?

Everywhere a code has to be read. The same OCR layer runs on:

• Variety codes on bright-stack cans, read through a dome light in any orientation
• Label codes at the labeler exit, read character by character and matched to the live production order
• Can seam inspection lines, where codes on the can end are read at the same station
• Fill level stations, when the bottle carries a printed code

Because it is one layer, setup, results and reports look the same on every system, and they all show up on the same JM Automated Solutions HMI.

What does it still need to work well?

Good images. Deep learning OCR is more forgiving than rule-based OCR, but it can't read a character that isn't in the image. Lighting, lens and exposure still decide most of the result, which is why we choose the light for each code: a dome light for shiny can ends, integrated lighting at a labeler, a short strobed exposure on fast lines. See lighting and optics for how we pick it.

It also needs the right expected value. The changeover from the plant's MES over EtherNet/IP^[3] or TCP/IP tells the system which code to expect, so a correct read of the wrong code still fails.