PLC to Vision Handshakes and Recipe Versioning: Making Inspection Stations Predictable

Many machine vision problems on a production line are not image problems at all. The camera sees the part well, the algorithm works, and yet the station occasionally passes a part it never inspected, or stops after a recipe change no one can explain. Two engineering notes from Deyi Vision, a Foshan-based machine vision supplier, deal with these integration failures: one on the PLC to vision handshake, and one on recipe versioning and rollback. Together they describe how to make a vision station behave predictably.

Engineering illustration of a PLC to vision handshake state machine with ready, busy, result and fault states. Image: deyivision.com.

Treat the handshake as a state machine

Deyi Vision's note on the PLC vision handshake state machine recommends defining the exchange between PLC and vision system as explicit states rather than a loose set of bits. The example uses four states: Ready, Busy, Result and Fault. The PLC triggers only when the vision system reports Ready; the vision system reports Busy while acquiring and processing; it publishes a Result tied to that trigger; and any unexpected condition goes to Fault rather than to an ambiguous idle state.

Timeouts belong in the design

The note's example uses a 200 ms processing deadline and a 500 ms acknowledgement timeout. These are illustrative values, not recommendations, but the principle is general: every wait needs a limit, and what happens when the limit is exceeded must be written down. A result that arrives late should not be applied to the next part.

Tie results to the part

A result bit with no identifier invites mismatches. Including a trigger count or part ID in the result lets the PLC confirm that the answer belongs to the part in front of it, and makes logs useful when something goes wrong. It also helps when two parts are close together on a fast conveyor.

Keep the signal list short and documented

A handshake that grows by adding bits over time becomes hard to reason about. Write down every signal exchanged between PLC and vision system, its direction, its meaning in each state and who owns the change. When a new requirement appears, update the state description first and the code second. Commissioning engineers, maintenance staff and the vision integrator should all be able to read the same document and predict what the station will do after a power cycle, an emergency stop or a camera restart.

Decide what a fault does to the part

The safe default for an inspection station is that a part without a valid result is not a passed part. A timeout, a lost connection or a vision fault should route the part to reject or hold, not let it continue. This is a policy decision for the line owner, and it should be part of the acceptance test rather than discovered during production.

Engineering illustration of vision recipe versions with a controlled rollback path. Image: deyivision.com.

Version recipes like software

A vision recipe holds the regions, thresholds, tool settings and camera parameters for a product. Deyi Vision's note on vision recipe versioning and rollback treats it as a controlled artefact. Its example names recipe versions R10 and R11, a camera configuration C4 and application version 2.0, and shows why all of them need to be recorded together: a recipe that worked with one camera configuration or application build may not behave the same with another.

Practical rules from the note include:

• Give every released recipe a unique version and keep previous versions
• Record which recipe, camera configuration and application version were active for each production period
• Change one thing at a time and document why
• Keep a tested rollback path to the last known good combination

Re-test after every threshold change

Changing a threshold shifts the balance between false rejects and escapes. Deyi Vision's note on the inspection threshold confusion matrix explains how to evaluate that trade-off with labelled good and bad samples rather than judging by eye.

Make the active version visible

Operators and quality staff should be able to see which recipe and application version are running without opening an engineering tool. Showing the version on the HMI and writing it into each result record turns an investigation from guesswork into a lookup.

Build both into the acceptance test

Handshake behaviour and recipe control are easy to test before handover and painful to retrofit afterwards. Deyi Vision's machine vision acceptance test checklist is a useful template. Add tests that deliberately cause a timeout, disconnect the vision system during a cycle and load a previous recipe, then confirm the line responds as specified.

Machine vision acceptance test bench with inspection camera and test samples. Image: deyivision.com.

For software-side questions, Deyi Vision's machine vision software page describes its software routes, and project details can be sent through the contact page.

FAQ

What states should a PLC to vision handshake include?

Deyi Vision's example uses Ready, Busy, Result and Fault, with defined transitions and timeouts between them.

What should happen when the vision result times out?

The part should not be treated as passed. The line owner should define a reject or hold action and test it before go-live.

Why version the camera configuration with the recipe?

A recipe tuned for one camera configuration or application build may behave differently with another, so the combination must be recorded and restorable.

How do I judge a threshold change?

Test it on labelled good and bad samples and compare false rejects and escapes, for example with a confusion matrix.

Contact Deyi Vision: email sales@deyivision.com · deyivision.com