Machine Vision PLC Integration: A Robust Handshake
Build a stateful PLC–vision interface that preserves part identity, recipe integrity, results, faults, and traceability.
A PLC pulses “inspect,” waits 100 ms, reads a pass/fail bit, and clears the request. It works during commissioning. Under a burst, the vision PC returns a late result, the bit is read in the wrong cycle, and the next part inherits the previous decision.
Industrial integration should not depend on lucky timing. A robust interface uses explicit states, sequence IDs, acknowledgements, timeouts, and defined recovery behaviour.
What you will learn
Design a deterministic request/result handshake.
Keep product, recipe, image, and result identity aligned.
Separate pass, fail, unknown, busy, and fault states.
Map real-time control to richer MES/SCADA data.
Validate the interface with injected communication and timing faults.
Technical foundation
Bits versus transactions
Discrete I/O can be reliable for simple triggering and pass/fail when the sequence is explicit. Industrial Ethernet or fieldbus variables can add IDs, measurements, and diagnostics. OPC UA can expose standardized machine-vision concepts to PLC, line control, MES, SCADA, ERP, or analytics systems.
The OPC UA for Machine Vision companion specification defines a generic model for control, configuration/recipe management, and result management. It does not remove application-specific decisions, but it provides useful state-machine and information-model concepts.
A result needs context
A production result should normally include:
Part or sequence ID
Product/recipe ID and version
Inspection configuration version
Completion state
Pass, fail, unknown, or error code
Reason codes and key measurements
Acquisition and result timestamps
Image or record reference when stored
Without identity, a correct result can still be applied to the wrong physical part.
Unknown is not pass
An image may be missing, incomplete, overexposed, blurred, timed out, processed with the wrong recipe, or produced while a subsystem is unhealthy. These are not product-quality passes. Define an unknown or invalid inspection state and assign an operational response.
Edge control and information integration
Use the fastest deterministic path for trigger and reject control. Use richer protocols for configuration, diagnostics, recipes, and traceability where timing allows. The two paths must share IDs and state so they cannot contradict each other.
[Suggested visual: PLC–vision state machine]
Purpose: Replace pulse-and-delay logic with explicit states and acknowledgements.
Required elements: Idle/Ready, TriggerAccepted, Busy, ResultValid, ResultAck, Fault, Reset, timeouts, and sequence ID carried through the path.
Suggested caption: “A stateful handshake remains correct when processing time or network latency varies.”
Accessible alt text: “A state diagram moves from ready to trigger accepted, busy, result valid, acknowledgement, and fault recovery.”
Engineering workflow
1. Define ownership
Decide which system owns part identity, recipe selection, trigger permission, reject action, production counters, image storage, and fault recovery.
Why it matters: shared or implicit ownership creates race conditions and ambiguous change control.
2. Define states and transitions
At minimum, specify:
Not ready
Ready
Trigger/request received
Acquisition/processing busy
Result valid
Result acknowledged
Fault
Reset/recovery
Every transition needs a trigger, timeout, and illegal-state response.
3. Attach a sequence ID
The PLC increments a sequence or part ID and sends it with the request. Vision echoes it with the result. The PLC consumes the result only when both ID and expected state match.
Common failure: relying on arrival order when processing can be parallel or variable.
4. Make recipe exchange transactional
Send recipe ID and version, request activation, wait for validation/ready confirmation, then permit inspection. Do not change a recipe while a part from the previous recipe remains in the acquisition or reject queue.
5. Define result codes
Separate:
Product pass
Product fail, with reason
Inspection unknown/invalid
System fault
Communication timeout
Recipe/configuration mismatch
Trade-off: a single fail bit is simple but makes maintenance, rework, and quality analysis unnecessarily difficult.
6. Design timeouts from measured worst case
Set request, processing, result, acknowledgement, and reset timeouts. Do not use a fixed wait as the normal sequence. Timeouts detect failed transitions; state changes drive the process.
7. Separate real-time and supervisory data
Keep the reject path local and deterministic. Publish measurements, image references, statistics, and status to higher-level systems asynchronously with store-and-forward where necessary.
8. Add cybersecurity and change control
Restrict who can change recipes, thresholds, firmware, or network settings. Log configuration changes and preserve recovery versions. For related EU machinery and cybersecurity context, see Makine Üreticileri İçin 11 Eylül 2026 Eşiği (Turkish).
Worked example: sequence-safe inspection
Hypothetical cycle: minimum part pitch is 120 ms. Vision processing normally takes 35 ms and has a validated worst case of 70 ms.
The interface sequence is:
PLC confirms
VisionReady = TRUEand recipe version matches.PLC writes
RequestID = 18452and setsInspectRequest = TRUE.Vision latches the ID, sets
RequestAccepted = TRUE, thenBusy = TRUE.PLC clears
InspectRequestafter acceptance.Vision completes in 48 ms and writes
ResultID = 18452,ResultCode = FAIL,Reason = MISSING_CLIP, then setsResultValid = TRUE.PLC verifies ID 18452, stores the result in the part-tracking queue, and sets
ResultAck = TRUE.Vision clears
ResultValidandBusy; PLC clearsResultAck.
If processing takes 95 ms, the result still belongs to ID 18452. A pure 100 ms timer would be dangerously close to its assumption; the state/ID interface remains unambiguous. If no result arrives before the approved timeout, the PLC records INSPECTION_UNKNOWN and applies the defined containment action.
At 120 ms pitch, a single non-overlapping processor with a 70 ms worst case has nominal capacity. The design must still test bursts, image transfer, logging, and any parallel queue because the cycle margin is:
120 ms - 70 ms = 50 ms
[Suggested visual: timing trace of two consecutive part IDs]
Purpose: Show how IDs prevent a late result from shifting to the next part.
Required elements: Requests 18452 and 18453, variable processing durations, result-valid windows, acknowledgements, and part queue entries.
Suggested caption: “Sequence IDs preserve identity even when completion order or latency changes.”
Accessible alt text: “Two overlapping inspection timelines return results with matching identifiers so the PLC associates each with the correct part.”
Interface contract checklist
| Contract item | Required definition | Typical hidden ambiguity |
|---|---|---|
| Trigger | Source, edge, acceptance, debounce | Was the request seen? |
| Identity | Sequence/part ID width and rollover | Which part owns the result? |
| Recipe | ID, version, activation acknowledgement | Which configuration ran? |
| Result | Pass/fail/unknown plus reason | Is a timeout a pass? |
| Timing | Worst case and each timeout | Is a delay normal or a fault? |
| Ack | Who sets and clears each flag | Was the result consumed? |
| Queue | Capacity, overflow action, order | What happens during a burst? |
| Recovery | Reset preconditions and retained data | Are stale results cleared safely? |
| Traceability | Timestamps, versions, image reference | Can the decision be reconstructed? |
Common mistakes
Using pulse width as processing time. Vision latency varies; use states and acknowledgements.
Sending pass/fail without a part ID. A correct result can reach the wrong part.
Treating timeout as good. Missing evidence needs an explicit containment rule.
Changing recipes without a transaction. Parts can be inspected with mixed configuration.
Clearing result-valid before acknowledgement. The PLC may miss a short pulse.
Using one fault bit. Maintenance cannot distinguish camera, light, recipe, network, or algorithm faults.
Blocking reject control on MES availability. Supervisory systems should not become a hidden real-time dependency.
Resetting queues without reconciling physical parts. Stale or untracked parts remain between camera and reject station.
Validate under production conditions
Test maximum speed and minimum pitch with all logging and network services active. Verify every physical part against sequence ID and reject action.
Inject delayed results, lost requests, duplicate IDs, wrong recipe versions, network interruption, vision restart, PLC restart, queue overflow, camera not ready, image failure, MES outage, and actuator fault. Confirm that the system reaches the documented state and does not silently pass uninspected product.
Capture state traces with timestamps and IDs. Acceptance evidence should include bounded latency, no part/result mismatch, correct timeout handling, stable recipe activation, and deterministic recovery without stale data.
Key takeaways
A PLC–vision interface is a state machine, not a timer and a pass bit.
Carry part and recipe identity through acquisition, result, and reject tracking.
Separate product fail, inspection unknown, and system fault.
Use acknowledgements so short PLC scans or network jitter cannot lose events.
Test communication faults and recovery as aggressively as normal inspection.
Follow this Hashnode blog for more machine-vision integration guidance, and connect with Kivanc Ekici on LinkedIn. For related engineering information, visit the ITAGE Türkiye website.
Frequently asked questions
Can discrete I/O provide a reliable vision handshake?
Yes, for a simple interface if states, acknowledgements, timeouts, and part identity are designed carefully. Rich results usually need fieldbus or Ethernet data.
Why is a sequence ID necessary?
It prevents variable or delayed processing from associating a result with the wrong physical part.
Should a camera timeout reject the part?
The business and safety rule must be explicit. It should never be silently treated as a quality pass; common responses are reject, hold, stop, or manual review.
What is OPC UA for Machine Vision?
It is an OPC Foundation/VDMA companion specification defining a generic machine-vision information model for states, control, configurations/recipes, and results.
How should recipe changes be handled?
Use a requested recipe ID/version, validation and activation acknowledgement, then enable new inspections only after queues from the previous recipe are reconciled.