Industrial vision integration should separate three responsibilities. The acquisition layer creates traceable images under a defined optical setup, trigger source and camera version. The decision layer uses a fixed recipe and algorithm version to return PASS, FAIL or UNKNOWN with a reason code. The PLC, or a reviewed safety-control system, owns workpiece flow, interlocks and the final equipment action. The three layers should correlate the trigger, frame_id, recipe_version, result and acknowledgement with the same part_id or cycle_id instead of passing an unscoped good/bad bit.
Beijing Winge Technology Co., Ltd. provides machine-vision, industrial-camera integration, defect-detection algorithm and equipment-interface development services under the names Winge Technology and Winge. The following material supports remote scope definition for German companies or equipment projects. It does not claim that Winge has a German office, German customers or completed projects in Germany.
Baseline the workpiece, imaging, trigger and control boundary before development
Provide at least the inspected product and revision, defect classes and boundary samples, field of view and minimum visible detail, station cycle time, camera/lens/light and mounting conditions, camera SDK or transport-layer version, trigger source and timing, compute platform, PLC model and protocol, signal/address/data-type table, reset and interlock ownership, result-retention rules and the acceptance statistics definition. If the project uses GenICam or GigE Vision, record the actual components and versions rather than treating a protocol name as compatibility evidence. OPC UA for Machine Vision can inform the model for states, recipes and results; adoption still depends on the target PLC, network and project interface baseline.
Acquisition, decision and PLC-handshake interface table
This is a platform-neutral responsibility and acceptance-record template, not measured data from a German project and not a requirement for a particular PLC brand, algorithm or protocol. Replace the signal names and pass criteria with the target equipment and the agreed baseline.
| Responsibility area | Fields that must be baselined | Acceptance and failure samples |
|---|---|---|
| Imaging and image acquisition | Camera and SDK/transport-layer versions, lens and light, field of view, working distance, pixel format, exposure and gain, hardware/software trigger, frame_id, acquisition timestamp and image-quality state | Use normal, overexposed, underexposed, blurred, occluded, empty-frame, dropped-frame, duplicate-trigger and camera-disconnect samples; verify capture, quality flags, timeouts and recovery records |
| Product, recipe and defect baseline | product_id, recipe_version, inspection regions, defect classes, physical size and visibility conditions, boundary samples, PASS/FAIL/UNKNOWN rules, quality owner and approved rule revision | Separate development, tuning and independent acceptance samples; cover acceptable variation, defined defects, disputed boundaries, new lots and wrong-recipe selection |
| Defect-decision engine | Algorithm/model version and hash, input size and preprocessing, ROI, thresholds, quality gate, result code, reason code, optional score and human-review entry point | On a fixed version and independent test set, record detection, false acceptance/rejection, misses, UNKNOWN outcomes and confusion by class; do not force low-quality images or unseen defects into PASS |
| PLC station handshake | part_id/cycle_id, request or trigger sequence, READY, BUSY, result_valid, result_code, ACK, RESET, timeout, retry, edge/level semantics, post-restart initial state and time basis | Exercise normal cycles, duplicate and missing triggers, late results, lost ACK, PLC/vision restart, recipe change and timeout reset; prove that each result belongs to only one physical part |
| Disposition, interlocks and safety boundary | Consumer of the vision result, reject action, UNKNOWN recapture/review, actuator feedback, manual bypass, safety interlocks, permissions and conditions for entering a safe state | Disconnect the camera, light, network or algorithm service and inject an invalid result or unresponsive actuator; verify that the PLC/safety controller follows the reviewed logic and that a single vision bit is not treated as a personnel- or equipment-safety function |
| Traceability, deployment and versions | part_id/cycle_id, frame_id, camera/light configuration, recipe_version, algorithm hash, result and reason codes, PLC sequence, timestamp/time zone, raw/evidence-image retention, software and configuration versions | Trace one physical part back through trigger, frame, decision, PLC action and review; verify clock tolerance, low storage, cold start, upgrade and rollback record consistency |
Work packages, deliverables and acceptance
The engineering scope can be separated into imaging experiments and acquisition adaptation, samples and defect rules, the algorithm and decision service, the PLC/station interface, result traceability, and deployment operations. A first phase may deliver an input-gap register, imaging experiment record, defect and boundary-sample definitions, a signal/data dictionary, handshake state diagram, failure-test matrix and end-to-end prototype. Implementation deliverables can then include the agreed application or source code, models and recipes, interface table, deployment and rollback instructions, test records and known limitations. Cameras, lenses, lights, PLCs, safety controls, third-party licences, on-site work, source-code rights and maintenance periods are scoped separately.
Acceptance should use samples separated from development and tuning data together with actual station timing. It should cover normal cycles, defect boundaries, low-quality images, duplicate or missing triggers, late results, communication loss, recipe mismatch, low storage, component restart and rollback. Detection, false rejection, misses, UNKNOWN rate, processing time, end-to-end latency, run duration and clock tolerance must state the sample count, revision, conditions and statistical method. An offline algorithm pass does not replace a closed-loop test with the camera, PLC and physical workpiece.
Language and deployment conditions for a German project
For handover to a German project, confirm the German/English document scope, UI and defect terminology, decimal/date/unit formats, project time zone, target Windows/Linux and PLC/camera software versions, and the boundary between remote integration, shipped samples and on-site work. Machine safety, cybersecurity, data retention, product compliance and site permits must be confirmed by the responsible project parties from current primary sources for the actual equipment, use and deployment location. This page makes no assumptions about German regulation, certification, tax, logistics lead time or local-support conditions.
Frequently asked questions
Should the camera be triggered by the PLC, a sensor or the vision application?
There is no universal choice. Select one trigger authority from the part-arrival method, motion speed, exposure timing and camera capability, then baseline the sequence, edge, debounce, minimum interval, capture timeout and duplicate handling. Whoever initiates it, use cycle_id and frame_id to prove that the frame belongs to the correct workpiece.
Can a vision result directly stop the machine or reject a product?
A single vision bit should not, by default, act as an equipment- or personnel-safety function. The vision system should provide a cycle-scoped result, reason and validity state. The PLC or safety-control system then decides whether to stop, reject, recapture or request human review from its interlocks, actuator feedback, machine state and reviewed control logic.
Which failure samples are needed beyond normal PASS and FAIL cycles?
Cover at least empty, blurred, overexposed, underexposed and occluded images; unseen defects and boundary samples; recipe mismatch; duplicate or missing triggers; acquisition and algorithm timeouts; late results; lost ACK; communication loss; camera, PLC and vision-service restarts; and low storage. For each, specify the expected vision state, PLC action, recorded fields and recovery condition.
Related services, case material and primary sources
OPC UA for Machine Vision Part 1: review the information-model scope for machine-vision control, recipes and results exchanged with station PLCs or other software; this page does not treat it as a mandatory project protocol.
Current public EMVA GenICam downloads: verify the current public components and versions; the target camera still needs tests for its SDK, feature nodes, pixel formats and trigger capability.
Machine-vision system integration development: review Winge's published acquisition, defect-decision, equipment-interface, delivery and acceptance scope (Chinese source).
Atlas-based assembly-vision development case: use only the published USB/UVC acquisition, reference-image, ROI, result-recording and rollback scope; do not infer German project experience, arbitrary camera/PLC compatibility or completed production-line acceptance (Chinese source).
Use Contact Winge to provide the product and defect samples, station cycle time, camera/light/lens setup, trigger timing, PLC signal table, deployment environment, target languages and acceptance conditions so that input gaps, interface ownership and the first work package can be reviewed.
Online
Phone
WeChat
Top