Seal and bead appearance: line acceptance

Purpose and operating boundary

Accept visual decisions, complete event records and physical handling separately; a passing appearance result cannot certify leak tightness or adhesive strength.

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 visual path definitions, material state, runtime identity and agreed Review handling. Keep any required functional seal or bond evidence as a separate acceptance workstream. Define the visible acceptance feature before building a seal or bead mask. A tamper-seal edge, a heat-seal band and an adhesive bead have different physical meanings and must not share an undeclared appearance rule. Record the reference path, permitted projection, substrate and state of the material at capture. Wet adhesive, cured material and a reflective backing can produce different boundaries without an equivalent change in joint integrity. Include a deliberately visible gap, an offset path, a plausible reflection and an obscured section as separate controls. The assigned image rule evaluates observable surface appearance only. It cannot establish airtightness, leak rate, peel strength, bond strength, cure or a hidden interface. Those claims need their own process-specific evidence. If the required interface is hidden, return insufficient evidence or choose another validated observation method; do not complete the path from an expected drawing. 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. 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.

Procedure

1. Use independently referenced continuous, gap, offset and hidden controls, retaining all planned events.
2. Send event identity, visual verdict, validity and reason with the exact revision; reject stale or mismatched acknowledgement.
3. Inject no image, unavailable runtime, duplicate delivery, late result and restart with work pending before enabling actual outputs.
4. Verify the supervised physical route for the current part and keep its evidence distinct from functional joint testing.

Interpret the trial

The hypothetical budget is acquisition 8 ms, segmentation 14 ms, rules 6 ms and communication 4 ms: total 32 ms against a 100 ms deadline, leaving 68 ms. It is not measured throughput. Even a correct visual result after the deadline cannot authorize the next part, and message receipt alone is not proof of the current part disposition.

Recording worksheet

T = 8 + 14 + 6 + 4 = 32 ms
M = 100 - 32 = 68 ms

Two engineering views

Failure diagnosis

• A complete-looking path can coexist with poor adhesion or a hidden channel; preserve the scope of the visual claim.
• Counting only completed passing images conceals unobservable and execution-failure events.

Acceptance and handover

Accept only the declared appearance scope demonstrated by independent samples, observed timing and current-event handling. Record the tested hardware and executable package; retain unresolved visibility and separate functional qualification without inventing 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.