Write the observable acceptance claim
Write the acceptance claim as classification of a visible liquid boundary within a declared image zone and container family. State whether the output is an image-relative height ratio or another explicitly defined visual proxy. Do not describe it as measured fill volume, mass or hidden liquid content. A curved wall, opaque container or obscured surface can invalidate the observation even when the workflow returns a number. Agree the defect classes, allowable pose, material appearance and review policy before evaluating acceptance images. This prevents a successful image-processing demonstration from silently becoming a broader promise about the filling process or the released station.
Separate development and acceptance material
Hold out identifiable containers and production batches that were not used to choose the lighting, ROI or decision interval. Include independently referenced low, normal and high visible levels together with empty controls, foam, wall reflections and allowed material variation. Keep every original frame and its reference assessment; uncertain references need their own declared disposition. Do not move an awkward acceptance sample into development and then report only the replacement. Group repeated views of the same container so they do not masquerade as independent specimens. Freeze the planned groups and test conditions before the run, and record any unavailable group instead of silently reducing the scope.
Freeze the decision contract
Freeze how Pass, Fail, Review, execution errors and missing results map to the receiving station. A valid visible-height measurement outside the configured interval is different from insufficient boundary evidence. Neither review nor a default numeric value should be converted into a confirmed low-level defect or an accepted bottle. Inspect the typed rule, geometry and numeric ports together with their identities. If a node's output contract is unfamiliar, validate it against the installed version before connecting actions. Agree the station response to an unobservable boundary with the process owner; this tutorial does not prescribe a universal safety action or a complete controller program.
The observable acceptance boundary
The accepted image zone must contain the declared visible liquid boundary across the permitted container poses.
- Declared container family
- Full original image coordinates
- Visible boundary inside the ROI
- Hidden surface remains unmeasured
Account for the full planned denominator
Retain the full planned denominator when reporting valid decisions, review, execution failures and missing results. Define each category before counting and keep specimen-level outcomes separate from repeated image observations. A worksheet should allow a reviewer to trace every count back to original events and reference classes. Report the accepted sample groups and unresolved groups alongside any summary; do not publish an accuracy claim derived only from the cases that produced convenient outputs. The evidence record below is a proposed schema, not measured production performance. Acceptance limits must come from the application's agreed risk and test protocol, not from a generic percentage copied into the workflow.
record = {
'event_id': event_id,
'image_id': image_id,
'workflow_revision': workflow_revision,
'raw_decision': raw_decision,
'execution_status': execution_status,
'handoff_status': handoff_status,
}
# Acceptance evidence schema, not a PLC implementation. Keep missing and invalid results explicit.Verify event-to-action handoff
Trace the intended bottle from acquisition event through source image, workflow revision, result and receiving action acknowledgement. Check that a late response cannot overwrite the current event and that an earlier ratio is not reused after a missing frame. Keep the actual handoff status separate from the visual decision: an image classified correctly but acted on for the wrong bottle has not passed integration. Test mappings in an isolated environment before enabling equipment outputs. Declare who owns timestamp interpretation, queue behavior and acknowledgement timeouts. The example record only names evidence fields; the receiving controller's validated interface and station-specific response remain separate implementation work.
Challenge interruptions and restart
Exercise startup, stop, restart, interrupted transport and changed bottle spacing under the agreed test conditions. Include missing images, delayed results, cancellation and unavailable runtime responses without hiding them in a successful replay summary. Confirm that the station cannot present a previous bottle's result as a fresh measurement after restart. Compare stationary and permitted moving conditions using the same reference policy, since liquid motion can change visibility without changing the actual fill reference. An offline image test can isolate the processing contract, but it cannot certify camera readiness, timing, actuator behavior or the current Windows package. Preserve which parts were simulated and which were actually observed.
Assemble the acceptance workbook
Package the frozen image groups, reference rationale, full ROI coordinates, actual acquisition settings, workflow and runtime identities, raw typed outputs and event handoff logs. Include the original failures and unresolved ambiguity rather than only annotated passing screenshots. The acceptance workbook should say what evidence proves and what it cannot prove, with an owner for each unresolved integration condition. Retain the baseline and candidate comparison so another engineer can reproduce the decision. Configuration changes made after the run require a documented impact assessment and appropriate revalidation; a familiar workflow name does not make changed optics, crop geometry or output mapping equivalent to the accepted version.
| Evidence item | Required association | Limit to retain |
|---|---|---|
| Independent bottle groups | Specimen, batch and reference class | Only declared container and appearance scope |
| Raw decision and execution state | Original image and workflow revision | Review and missing results stay explicit |
| Action handoff log | Bottle event and receiving acknowledgement | Correct classification does not prove correct action |
| Runtime and configuration snapshot | Actual installed versions and settings | Offline evidence does not certify hardware readiness |
Release only the demonstrated boundary
Release only the container family, visible boundary, operating conditions and interface behavior demonstrated by the agreed evidence. If foam or reflections still hide the surface, retain the review boundary and consider a different observation method rather than presenting a narrower sample set as complete acceptance. Historical fixed-station source evidence and saved-image evaluations do not establish that the current candidate package, physical camera or production installation is ready. Browser-local OpenCV.js execution is not an implemented capability in the reviewed scope. Deyi Vision workflow assistance can support investigation and record comparison, but acceptance remains a specific documented result, not a general claim of volume accuracy or factory performance.
From event evidence to bounded acceptance
Keep result identity and receiving action evidence before deciding whether the agreed station scope has been demonstrated.
- Acquire the identified bottle image
- Preserve typed decision and validity
- Confirm event-specific handoff
- Accept the bounded scope or retain gaps
Sources and technical references
These references explain the methods and limits used in this tutorial. Example checks are guidance; production acceptance requires evidence from your own samples.
- Triggered Image AcquisitionBasler
Acquisition triggering and readiness are camera-specific parts of event association.
Checked - Deyi Vision Vision WorkbenchDeyi Vision
Saved-image workflow evaluation must be distinguished from acceptance of an installed acquisition and integration runtime.
Checked
Component and selection references
- machine vision software
- Machine Vision Acceptance Test Checklist
- Automated Visual Inspection
- EAN-13 traceability: line acceptance
- EAN-13 traceability: decode and data rules
- Stable camera acquisition: buffers, timeouts and reconnection
- AI-assisted workflow for a visible level proxy
- Link inspection records, images and part identifiers
- OCR labels: acceptance and PLC contract
- OCR labels: native workflow and exact match
- Accept and integrate open-package completeness checks
- Build an AI-assisted open-package completeness workflow
- Build a PLC–vision handshake with explicit states
- Seal and bead appearance: line acceptance
- Seal and bead appearance: workflow rules
- SKU color sorting: acceptance and unknown route
- SKU color sorting: typed color and SKU rules
- Surface defects: acceptance and line output
- Surface defects: bounded AI evaluation
- Load-test latency from trigger to PLC decision
- Version and roll back the complete vision recipe
