OCR vs OCV in Manufacturing: Reading a Code Is Not Verifying It

OCR (optical character recognition) converts an image region into a character string. OCV (optical character verification) compares the printed mark against an expected string and grades the quality of each character. The first is a reading problem. The second is a conformance problem, and conformance is what quality systems and recalls are actually about.

An OCR-only station will happily report "08/14/26" from a package that should have been marked "08/15/26". Unless something downstream compares that string to the production order, the misprint ships. The camera worked; the system did not.

Verification requires an authoritative expected value. In practice it comes from one of four places, in descending order of robustness:

• MES / ERP work order — the strongest option: the expected date, lot and SKU arrive with the order, and the inspection recipe is selected by the same identifier.
• PLC recipe register — the line controller holds the active product and expected string; the inspection system reads it over the existing fieldbus or OPC UA connection.
• Print engine / coder message — the string sent to the printer is echoed to the inspection system. This catches print failures but not an operator loading the wrong message.
• Operator entry at the HMI — acceptable as a fallback, but it re-introduces the human error the system is supposed to catch. Require confirmation and log the entry.

Character content

Each character matched against the expected string, position by position, with a defined match score threshold.

Character quality

Stroke completeness, contrast, and break/void detection — a legible-but-degraded code should be caught before it becomes unreadable.

Presence and position

Mark located within a tolerance window relative to a part datum, so a drifting coder is flagged early.

Format validity

Date format, Julian day range, shift code and lot pattern checked against a rule, catching plausible-looking but invalid strings.

1D/2D code data

Decoded payload compared to the expected value; for 2D, grade parameters (contrast, modulation, fixed pattern damage) tracked as a trend.

Code inspection projects rarely fail on algorithm choice. They fail on the physics and on the plumbing.

• Too few pixels per stroke. Thermal inkjet dot-matrix characters need enough resolution that a broken stroke is distinguishable from image noise; a common working target is on the order of 3–4 pixels across the narrowest stroke, verified on real samples rather than assumed.
• Specular substrates. Metallized film, foil lids and gloss varnish reflect the illuminator into the lens. Diffuse or dome geometry, and sometimes polarization, matters more than the algorithm.
• Free-run acquisition. Without a hardware trigger tied to part presentation, the code lands in a different place in every image and the region of interest becomes unreliable.
• No NO READ state. A binary pass/fail hides the most diagnostic condition: the image was unusable. NO READ must be its own verdict with its own reject and alarm behavior.
• Recipe drift. Per-SKU parameters edited on the floor and never versioned. Six months later nobody knows why sensitivity changed.

Printed alphanumeric verification on a controlled substrate is a solved, deterministic problem. A trained character library with per-character scoring is faster to validate, easier to explain to an auditor, and more stable over time than a learned model. Deep learning earns its place when the appearance varies in ways you cannot enumerate: heavily textured substrates, laser marks on curved reflective metal, hand-applied stamps, or degraded thermal transfer on shrink film.

A hybrid arrangement is usually the honest answer: deterministic localization and OCV for the string, a learned model only for the classification step that resists rules. That keeps the auditable path deterministic and confines the training-data burden to a narrow question.

Note the two inputs converging on the decision. The imaging chain produces a mark; the data chain produces the expectation. A station that only has the first can read, not verify.

A single-SKU line, one code position, a matte label, generous reject window and no MES linkage requirement is a good fit for an off-the-shelf smart camera or vision sensor from Cognex, KEYENCE or similar. It will be cheaper to buy and quicker to stand up, and pretending otherwise does nobody any favors.

The economics change when you have many SKUs and formats, need per-order recipe selection, need image and verdict retention for traceability, need multiple views on the same part, or need a defined fail-safe interaction with the reject mechanism. That is where a configured inspection system — imaging, logic, controls and data as one deliverable — is the appropriate architecture.