Application guide by addaScanCompare the inspection task, imaging conditions and validation steps with your own production line.
- Inspection focus
- Label content tied to the correct weigh event
- Primary theme
- Label verification
- Decision evidence
- Label from event B
- Trial priority
- Previous-pack label
The readable price label must belong to this pack
The original English schematic explains the observable features and the proposed decision. The tables below set out the conditions to test on your own line.
Swipe across the diagram to see all details →
Readable label fields must match the current pack’s scale transaction. Correct arithmetic does not resolve a label left over from the preceding pack. Original association schematic.
Select an image to view it at full size.
Use a pack transaction rather than the latest scale value
The scale, printer and inspection station operate at different points in the line. Define one transaction identifier and a bounded record of expected fields for each pack. Normalise units and price formatting without silently changing the business value. Clear rules are needed for printer queues, duplicate labels and packs removed between weighing and labelling. A camera reads what was printed; it cannot infer which scale event was intended.
Name the authoritative transaction for the pack before checking printed fields. Weight, product identity, unit price and total price may all be readable and internally consistent while originating from the previous pack. The inspection needs the expected values or an approved transaction reference from the weighing/label system, not an independent guess based on the visible product.
Maintain the association through weighing, printing, label application and readback. Define how a removed pack cancels its pending label and how a reprint differs from a new transaction. If a pack is reweighed or its contents change, the older expected values cannot remain authoritative. Readability, field agreement and transaction identity should have separate result states.
Compare label content with the active scale transaction
Swipe across the table to compare all columns →
| Approach | Useful when | Limit or integration responsibility |
|---|---|---|
| Label-only OCR or barcode check | Legibility and internal field consistency | Does not prove association with the weighed pack. |
| Transaction-linked verification | Expected weight, product and price | Requires scale, printer and conveyor event integration. |
Standalone OCR can check visible characters and format, but cannot establish which scale event supplied them. A transaction-linked check is appropriate where previous-label or wrong-pack faults matter. Include the scale and printer interface, data latency and exception policy in that comparison rather than comparing cameras alone.
A previous-pack label can look entirely correct
Illustrative scenario: weight and price on the label agree with each other but match the previous pack transaction. Hold the current pack and reconcile the printer queue.
Cancel stale print jobs before creating a replacement tied to the same pack. Read the replacement label and verify the complete expected field set. Release only when both the content and event association agree; retain the rejected label image and correction history.
On a scale timeout or unstable value, hold the print/readback transaction rather than using the latest stored weight. A corrected label needs a fresh matched readback, with the superseded label and removed pack accounted for before the line resumes.
Challenge duplicate prints and missing scale events
Swipe across the table to compare all columns →
| Challenge sample or event | Expected behaviour to establish | Evidence to retain |
|---|---|---|
| Previous-pack label | Detect a mismatch even when arithmetic is valid. | Pack event, current scale transaction, expected fields, observed previous-pack label and mismatch containment. |
| Duplicate print and removed pack | Prevent the event queue from shifting silently. | Print/reprint identifiers, cancelled or removed pack event, label consumption and the deduplication decision. |
| Scale timeout or unstable value | Hold the transaction without reusing the previous result. | Scale stability flag, acquisition time, timeout state, reacquired weight and final label-to-transaction match. |
Intentionally place a valid preceding label on the current pack and interrupt the sequence around printing. Confirm that a correct arithmetic relationship cannot bypass a wrong-event result. Weighing accuracy and any trade requirements remain with the separately qualified weighing system.
Label matching does not certify the weighing instrument
This guide does not replace trade-approved weighing equipment or the applicable legal-metrology process.
Define the scale, printer and readback interfaces
Share permitted photos or drawings, plus details of scale message examples, label formats, rounding rules, pack tracking and reprint procedures. Agree any physical sample arrangements after the initial assessment.
Weigh price label verification for meat trays links the visible label check to scale and print records. Define the authoritative fields and the physical hold route before agreeing reader hardware.
SMT labels: catch print faults, duplicate serials and missing labels shows why printing and duplicate-identity checks need event records. For meat labels, the expected record must additionally belong to the current weighing transaction.
Review the indicative station budget and exclusions. Match the quoted views, product range and reject arrangement to the trial; changes to the production machinery and other exclusions remain separately agreed.
For line conditions around label content tied to the correct weigh event, see meat, staples and dry-goods packing.
Compare lighting, processing, interfaces and support in the HIKROBOT and other vision solutions guide. Agree sample testing, acceptance responsibilities and handover through the delivery process.