Inspection system
Date & Lot Code Verification System
A date or lot code that prints but prints wrong is a recall risk, not a cosmetic defect. A verification station exists to prove the printed value matches the value the work order says it should be.
Direct answer
What is a date and lot code verification system?
A date and lot code verification system is a machine vision inspection station installed on the production line that images every coded pack, reads the printed date, lot or batch code, and compares it against the expected value from the work order, MES or coder controller. Each pack receives a PASS, FAIL or NO READ verdict, the verdict is handed to the PLC inside the reject window, and the image plus read value is retained as a quality record.
Presence, OCR, OCV and code verification are four different checks
Most escapes we are asked to fix come from a station that only proved a mark existed. If the requirement is that the printed expiry matches the order, the station must be an OCV station with a trustworthy source of the expected value — a presence check cannot satisfy it, and neither can OCR on its own.
For a broader treatment of the same distinction across all marking types, see our Code & Marking Inspection Systems page.
- Presence check
- Is there any mark in the region? Catches a blank coder, nothing more.
- OCR
- Reads the printed characters into a string, without knowing what they should be.
- OCV
- Compares the printed characters against the expected string; fails on mismatch, missing characters or degraded print.
- Code verification
- Grades a 1D/2D symbol against ISO/IEC 15416 / 15415 style criteria under specified optics — decodable is not the same as well printed.
Where the expected value comes from
Verification is only as strong as its source of truth. If an operator types the date into the vision HMI at changeover, the station verifies the operator's typing, not the order.
- Preferred: expected date/lot/batch string delivered per work order from MES or ERP.
- Acceptable: string pushed from the coder controller, with vision acting as the independent cross-check.
- Weak: manual entry at the vision HMI with no second source; usable only where no data path exists, and it should be documented as a known gap.
- Always: log expected value, read value, verdict, timestamp and image reference together.
- Changeover is the highest-risk moment; the recipe change and the expected-value change must be the same event, not two.
End-to-end station architecture
- Trigger — photo-eye or encoder position defines the same imaging point for every pack.
- Lighting and optics — geometry chosen for the substrate and marking method; the code region imaged at consistent scale.
- Camera — exposure short enough that travel during exposure stays well under the narrowest character stroke.
- OCR / OCV / code logic — locate the string, read it, compare to the expected value, and grade symbols where a spec applies.
- Verdict — PASS, FAIL or NO READ, with NO READ handled explicitly rather than folded into FAIL.
- PLC and reject — verdict delivered inside the available reject window with a defined fail-safe default on timeout.
- Record — image and result retained with a documented schema for traceability and audit.
Fig. — End-to-end inspection system flow
- 01
Part presentation
Conveyor, indexer, web path, fixturing, part orientation
- 02
Lighting & optics
Geometry, strobe, polarization, lens, working distance
- 03
Industrial camera(s)
Trigger-synchronised acquisition, one or many stations
- 04
VSA Inspect / IPC
Deterministic pipeline plus AI models where justified
- 05
Inspection logic
Recipe, tolerances, source-of-truth comparison, arbitration
- 06
PASS / FAIL / NO READ
Three distinct verdicts — never two
- 07
PLC & reject
Encoder-tracked reject window, fail-safe on loss of verdict
- 08
Image + quality record
Retained image, verdict, recipe, timestamp, operator
Imaging failure modes that decide the design
Character verification fails on contrast far more often than on resolution. Each combination of marking method and substrate has a distinct lighting answer, which is why feasibility imaging on real production samples comes before any hardware commitment.
- Inkjet on kraft — absorbent, feathered edges; dot spread merges characters if resolution is set only per character rather than per stroke.
- Laser on metallized film — near-mirror surface; the specular lobe must be steered out of the lens with off-axis or dark-field geometry, or cross-polarized.
- Thermal transfer on gloss — high specularity with fine, high-contrast strokes; diffuse dome or coaxial light with controlled saturation.
- Dot-matrix coders — enough resolution to keep dots separable without merging them into blobs.
- Deforming film and shrink wrap — geometry changes pack to pack; a locator feature or constrained region of interest is needed before the string is read.
- Motion blur — strobed illumination and short exposure; blur is the silent cause of intermittent NO READ on high-rate lines.
Validation discipline
A code verification station is accepted against a labeled sample panel run at production speed, not hand-fed at a bench. The acceptance criteria are written before the run.
- Assemble known-good and known-bad samples: correct code, wrong date, wrong lot, partial print, smeared print, missing code, and each substrate and SKU in scope.
- Run at production speed with real presentation variation, and record every verdict.
- Report escapes and false rejects separately — they carry different costs and have different fixes.
- Confirm NO READ behavior and the PLC fail-safe default deliberately, including a simulated timeout.
- Re-run the panel after any lighting, optics, recipe or coder change.
What VisionAxiom delivers
VisionAxiom delivers this as a complete inspection system, not a parts list: application analysis, imaging and illumination design, station architecture, VSA Inspect configuration, PLC and reject integration, quality records, and a validation run against written acceptance criteria.
- Application → imaging: optics, lighting geometry, resolution and timing budget derived from your part and line speed.
- Imaging → VSA Inspect: inspection logic, per-SKU recipes, reason codes and operator screens configured per application.
- VSA Inspect → controls: PASS / FAIL / NO READ to the PLC inside the reject window, with a specified fail-safe default.
- Controls → data: image and verdict records retained for traceability, with the schema documented.
- Validation: at-speed run on a labeled sample panel, with escapes and false rejects reported separately.
Frequently asked questions
- Can a vision system verify an expiration date against the work order?
- Yes — that is exactly what OCV does, provided the expected string reaches the vision system from the work order, MES or coder controller rather than being typed in by an operator. The station reads the printed date, compares it character by character to the expected value, and fails the pack on any mismatch.
- What is the difference between OCR and OCV for date codes?
- OCR reads the characters and outputs whatever it thinks is printed. OCV compares what is printed against an expected string and fails on mismatch, missing characters or degraded print quality. For date and lot verification, OCV is the requirement; OCR alone will happily report a wrong-but-legible date as a successful read.
- Can one station inspect a date code and a Data Matrix code?
- Sometimes, but not always well. Verification-grade symbol grading specifies its own illumination geometry, which can conflict with the geometry that gives the best character contrast. Where the requirements conflict, two simpler stations are usually cheaper and more reliable than one compromised station.
- What happens when the system cannot read the code at all?
- It reports NO READ as a separate verdict. NO READ is routed and counted independently of FAIL so that an imaging or presentation problem does not get misread as a coding problem, and the PLC behavior for NO READ is specified during design.
- Does batch code inspection require AI?
- Usually not. Trained font libraries verified against an expected string are deterministic and easier to validate and audit. Learned models help mainly with severely degraded or highly variable printing, and they add a retraining and version-control obligation tied to your quality records.
Related engineering material