
Date code vision inspection and reject systems
Inspection must be specified around the defect that matters. A camera that sees a mark, a reader that decodes a symbol and a verifier that grades print quality are different tools and should not be treated as interchangeable.
Choose the inspection level before choosing the camera
The correct question is not “does it have vision?” but “which defect must be detected, what response is required and how will the result be challenged?”
| Inspection level | What it may confirm | Important limitation |
|---|---|---|
| Presence | A mark or region with expected contrast is present in the inspection area. | It may not prove that the characters or data are correct. |
| Position and format | The mark falls inside an approved area and may meet size, orientation or pattern rules. | A correctly positioned wrong code can still pass unless content is checked. |
| OCR or OCV | Characters are read or compared with an expected string or pattern. | Fonts, background, distortion, glare and uncertain characters can affect performance; the rule set must match the actual print. |
| Barcode or 2D decode | The reader decodes data from the symbol and may compare it with the active job. | Successful decoding by one device is not the same as formal symbol-quality verification. |
| Verification | A suitable verifier assesses symbol quality using the applicable method and reports measured attributes or a grade. | It normally requires controlled geometry and is not automatically equivalent to high-speed inline inspection. |
Design the inspection, tracking and containment sequence together
1. Acquire a usable image
Control product position, camera distance, focus, exposure, lighting, glare and background. Transparent, reflective, curved or moving packs may require a specific optical arrangement.
2. Link the result to the right product
Identify the product at the inspection point and track it through conveyor movement, gaps, accumulation and stops. A result without reliable product identity cannot drive a dependable reject.
3. Confirm containment
Define reject actuation, reject confirmation, bin-full monitoring, line stop or product hold. The system should expose a failed containment action rather than silently assuming removal.
Challenge samples should represent real defects
A test card alone is not enough. Build a controlled set using the actual pack and print process.
- Missing code or completely blank print area.
- Wrong date, batch, product or serial data compared with the active job.
- Partial, faint, smeared, broken or low-contrast characters.
- Code outside the approved position or rotated beyond the allowed range.
- Barcode or 2D symbol with damaged modules, inadequate quiet zone or incorrect data.
- Reject device disabled, reject bin full, product removed manually or conveyor stopped between camera and reject.
Record the inspection window
For each approved format, retain the camera position, lens, lighting, exposure, region of interest, expected data, tolerances and reject delay. A format change can alter more than the printer job.
Use the print-quality testing guide to establish the physical code before tuning the inspection around it.
Fault states to include in the controls design
Camera unavailable
Loss of power, communications, trigger, lighting or image acquisition should produce the defined alarm and production response.
Inspection uncertain
Low confidence, unreadable content or an ambiguous result should not be silently converted into a good result without an approved rule.
Tracking lost
Conveyor movement, accumulation, product removal or restart can break the relationship between image and pack. Define safe recovery and product clearance.
Reject not confirmed
Monitor the failure mode relevant to the mechanism, such as no actuation, no product at reject confirmation or a full containment bin.
Barcode and 2D-code inspection needs a separate decision
For machine-readable symbols, define the data content and symbology first. If GS1 data is used, the application identifiers, data structure, human-readable information, symbol size, quiet zones and final pack position should be reviewed before the printer and camera are commissioned.
A production scanner can provide useful inline decode and data-comparison checks. Formal barcode verification is a different activity performed with equipment and methods suitable for the symbol. GS1 UK recommends reviewing or verifying barcodes on a final product sample because print and substrate affect quality. See the GS1 UK barcode review information.
Do not allow a high-quality wrong symbol to pass. Compare decoded fields with the authorised product job, batch and date rules where the project requires it. Equally, do not expect a camera to correct a weak print process; stable contrast, position and adhesion should be established first.
The required record can range from a simple reject count to stored images, decoded data or batch reconciliation. Specify retention, access and data ownership only where the business process needs them.
Date-code inspection FAQs
What can a date-code vision system inspect?
Depending on the configured hardware and software, it may check mark presence, position, contrast, expected characters, decoded barcode or 2D data and comparison with the active job. The exact inspection must be demonstrated with representative packs.
Is barcode decoding the same as barcode verification?
No. A decoder confirms that a particular reader can read the symbol, while verification evaluates print quality against the relevant method and conditions. Use the level required by the application.
How does the system reject the correct pack?
The controls track the inspected product from the camera to the reject point using distance, timing, encoder information or indexed positions. Product gaps, stops, accumulation and restart behaviour must be tested.
What happens if the reject bin is full or a rejected pack is not confirmed?
The required response should be defined in the sequence of operation. It may include an alarm, controlled stop or product hold, depending on the supplied hardware and process risk.
Can vision inspection guarantee that every code is correct?
It can reduce risk within a defined inspection window, but capability depends on lighting, presentation, print quality, software rules and challenge testing. It does not replace sound data control or site-specific quality procedures.
Specify the defect, product tracking and containment response
Send representative good and bad samples, line speed, product pitch, camera-to-reject distance and the exact data or quality rule to be checked.
OCR, OCV and barcode decode are different inspection tasks
Optical character recognition (OCR) reads visible characters and returns text. Optical character verification (OCV) checks printed characters against an expected pattern or reference. Barcode decode extracts encoded data. A coding project may need one, two or all three, but none should be described as proving more than its configured rule actually checks.
| Inspection method | Primary question | Important limitation |
|---|---|---|
| Presence or contrast check | Is there a mark in the expected area and does it meet a basic visual threshold? | It may accept the wrong characters if they have similar coverage or contrast. |
| OCV | Does the visible print resemble the expected characters or template closely enough? | Performance depends on a controlled font, location, lighting, print variation and reference setup. |
| OCR | Which characters does the system read from the image? | A correct read is not proof that the text matches the authorised job unless the result is compared with expected data. |
| Barcode or 2D decode | Which data is encoded in the symbol? | Decode success does not automatically provide a formal quality grade or prove that the data belongs to the current product. |
| Formal symbol verification | How does the symbol perform against the applicable verification method? | Verification is normally a controlled quality measurement, not a substitute for pack tracking or automatic reject confirmation. |
Reading a date is not the same as proving the date is correct
To prove a date or batch code, the inspection result must be compared with the authorised message for the running job. The control system then needs to associate that result with the correct product and respond to a mismatch, no-read, uncertain result or lost tracking state.
Challenge the image rule
- Missing character or part of a character.
- Wrong digit with a similar shape.
- Correct text in the wrong position.
- Blurred, low-contrast or contaminated print.
- Different font, spacing or background.
- Correct-looking text from the wrong job.
Challenge the line response
- No image or camera unavailable.
- OCR or OCV uncertain result.
- Product tracking lost after a stop or jam.
- Reject device failed or reject not confirmed.
- Reject bin full or containment unavailable.
- Mismatch between printer data and expected job data.