OCR labels: acceptance and PLC contract

Purpose and operating boundary

Deliver a field-level verdict with traceable text and a deadline, keeping wrong text, unreadable text and communication failure distinct on the line.

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 field definitions, lot-source identity, normalization and OCR package. Begin with a simulated output contract, then use supervised real labels. 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. OCR label verification is a data-integrity task rather than a search for plausible words. Define each field, its location, expected alphabet, exact comparison policy and the trusted source of the expected value. A lot field, date field and product name may need different rules. Keep the text detection polygon and recognizer output before normalizing spaces or case. Do not silently replace I with 1 or O with 0: that can make a wrong label appear correct. The original engineering evidence includes a narrow OCR boundary case that returns NoResult or Review; increasing a crop does not establish general recognition readiness. A readable field can still contain the wrong lot, while a correct expected value does not justify filling an unreadable field with that value. 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. Define each field result as exact match, mismatch, Review, NoResult or execution error before aggregating a label verdict.
2. Send acquisition ID, revision and reason with the decision; do not let a late match replace a timed-out label.
3. Inject missing fields, incorrect lot, absent runtime and restart while work is pending; check the agreed inhibited route.
4. Compare the deadline budget with observed capture-to-acknowledgement intervals, then verify the physical label disposition.

Interpret the trial

In the hypothetical budget, OCR takes 55 ms, rules 5 ms and communication 5 ms: 65 ms against an 80 ms deadline, with 15 ms remaining. This is not measured OCR speed. A result after the deadline remains late even when its text is correct.

Recording worksheet

T = 55 + 5 + 5 = 65 ms
M = 80 - 65 = 15 ms

Two engineering views

Failure diagnosis

• A global good flag without individual fields can hide an unreadable date or lot.
• A receipt for another acquisition must not acknowledge the current label.

Acceptance and handover

Accept field completeness, exact-data correctness, failure handling and line acknowledgement separately. Record the hardware and installed model identities used for actual acceptance.

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.