EAN-13 traceability: line acceptance

Purpose and operating boundary

Carry each barcode event through decision delivery and the correct physical disposition, including no-read, late result and missed acknowledgement.

This tutorial defines an engineering evaluation, not a ready-to-run product certification. The current Deyi Vision public PC example covers an EAN-13 workflow on confirmed sample images. Native OCR and detection work in the engineering code must be checked against the installed runtime, bound models and job before use. A browser template does not prove browser execution: the planned OpenCV.js backend needs separate verification. Cloud recognition requires explicit approval of the image scope, provider, model and cost. A review archive is not an executable release package. Camera, firmware and driver compatibility require their own check. All worksheet values below are hypothetical; they are not Deyi Vision measurements or customer results.

Prepare the evidence

Freeze reader scope, encoder convention, item-event identity and approved product mapping. Test inhibited outputs before supervised conveyor operation. Define which timestamp starts the deadline and which acknowledgement proves completion. Save queueing and communication delays beside image processing so that a fast algorithm does not conceal a late line result. Use monotonic timing for intervals and a separately documented clock mapping when devices use different clocks. Record tail delays, missing results and reconnect behavior, not only the average. A new recipe must not reinterpret results already in flight; either finish under the recorded revision or apply the agreed inhibit procedure. Keep the output sequence, product position and confirmation together. The acceptance record should distinguish correct classification from successful communication and from confirmed physical routing. Keep decoding, identity validation, print verification and unit tracking as separate records. The EAN-13 value identifies a trade item and is normally shared by multiple physical units; it is not a per-frame sequence number or a unique serial. A successful decode does not prove print-quality compliance, correct product master data or successful downstream rejection. This series uses EAN-13 as its bounded example because that is the confirmed public PC evaluation scope. Other symbologies, QR, direct-part marks and reader hardware require their own confirmed integration. The original source image must retain bars, spaces and quiet zones; a cropped display or cleaned binary image alone is insufficient failure evidence. Specify how a missing frame and an unreadable code differ in the traceability database. Write the line contract before connecting a verdict to an actuator. Define acquisition identity, recipe revision, result state, deadline, acknowledgement and the disposition of missing or late data. Exercise the handshake with outputs inhibited, then use a supervised line trial under the plant acceptance procedure. Measure from the same defined event on each run; processing time alone omits queueing, transfer and output delay. A repeated product identifier is not a unique frame identifier. Test stop, restart, reconnect and recipe change with outstanding work. Preserve the full sequence so that the part being rejected can be traced to the evidence that justified that action.

Procedure

1. Map capture position to decision deadline and keep the agreed mechanical guard interval explicit.
2. Send event ID, payload or no-read reason and recipe revision; acknowledge the same event before closing it.
3. Inject missing frames, repeated delivery, late result and restart with items pending; verify the agreed safe handling.
4. Compare decision records with encoder position and supervised physical route; an application receipt alone is not a reject confirmation.

Interpret the trial

The hypothetical distance is 0.6 m at 1.2 m/s, giving 500 ms travel time. An 80 ms decision budget and 40 ms guard leave 380 ms. This is a budget example, not measured reader speed or actuator readiness. Encoder slip, variable transport and queue delays must be measured on the actual line.

Recording worksheet

travel = 0.6 / 1.2 = 0.5 s = 500 ms
margin = 500 - 80 - 40 = 380 ms

Two engineering views

Failure diagnosis

• A correct payload associated with the next item is a failed traceability result.
• A timer-only reject without position evidence can fail when the conveyor slows; validate the declared transport model.

Acceptance and handover

Accept record completeness, data association, deadline compliance and physical disposition independently. Keep unresolved no-reads and faults visible, and retain the witnessed line-test record before claiming production readiness.

Keep the source images, the expected decision, the exact revision and the complete result record together. Freeze the evaluation set before selecting the final parameters. If those answers are later used to tune the workflow, mark that set as development data and obtain a new independent acceptance set. Keep Review, NoResult, execution error and missing acquisition visible in the denominator; do not turn them into passes by filtering rows. Save a reproducible failure alongside the successful sample. The handover should identify who may change the recipe, how a prior approved revision is restored and which device output remains inhibited until acceptance. A software result alone does not establish that a moving physical part reached the correct destination.