Inspect steps and states: a vision inspection architecture

A vision inspection that grows as one long script gets harder to trust with every added check: a bad frame can leave it waiting forever, and a rejected part arrives with no record of which check failed. Structured as steps and states, the same inspection runs each trigger through a fixed sequence — acquire, preprocess, locate, measure, decide, output — where every transition has a guard and a timeout. This page defines the two terms, gives the cycle-time arithmetic that decides whether the sequence fits your line takt, and ends with the decision for each case: run the states on a smart camera or on a vision controller.

What a step is and what a state is

A step is one image-processing job applied to one frame: shading correction, a threshold, a template match, a caliper, a code decode. A step is deterministic — same pixels in, same numbers out.

A state is where the inspection stands at one moment of the cycle. It wraps its step with three things: a pass guard (the condition that moves on), named failure transitions (where each kind of failure goes) and a timeout.

A transition is the guarded move between two states, and the state machine is the whole table of states plus transitions. Three states in that table do no image work at all — idle, output and error — and they are what make the inspection a controllable machine instead of a filter chain.

The standard sequence: idle to output

Almost every discrete-part inspection decomposes into the same seven states:

1. Idle — outputs held, camera armed for the next trigger. If the trigger fires once and never again, this state is the first suspect; hardware trigger stops after one frame: check acquisition mode walks that fault.
2. Acquire — the light strobes, the exposure runs, the frame transfers in. Checks that need several images pull an image set from one trigger instead of one frame.
3. Preprocess — shading correction, filtering, thresholding, ROI crop, and buffer reuse (reuse image buffers instead of per-frame allocation). Deterministic operations only; nothing here looks at results.
4. Locate — find the part, find its pose, set the coordinate frame everything downstream uses. No part found is a transition, not an error.
5. Measure — calibrated checks inside the located frame: dimensions, presence, code grade, text.
6. Decide — combine the results against limits into one pass or fail per part, with the rejection reason attached.
7. Output — drive the I/O, handshake the result to the PLC, archive the image, return to idle.

The order carries two rules: locate before measure, so measurements ride the part's pose; decide after measure, so exactly one state owns the result.

The cycle-time formula

Whether the sequence fits the line is arithmetic, not opinion. Budget the serial case — no overlap between states — as the decision basis:

The throughput inputs, with their basis: Fast Ethernet moves 100 Mbit/s ≈ 12.5 MB/s on the wire and about 11 MB/s effective once protocol overhead is paid; GigE moves 1000 Mbit/s ≈ 125 MB/s and about 110 MB/s effective with jumbo frames enabled (budget 95-100 MB/s without them). An 8-bit mono frame and a raw Bayer color frame both cost 1 byte per pixel on the wire; decoded RGB costs 3. Pipelined runtimes overlap transfer with the previous part's processing, which only makes a real station faster — decide on the serial bound.

Worked example: a 6 MP camera against a 600 ms takt

Setup. A conveyor presents one part every 600 ms: 60,000 ms ÷ 100 parts = 600 ms takt. The camera is 6 MP, mono, 8-bit. The belt runs 500 mm/s and the check tolerates 1 mm of blur, so the strobe exposure is capped at 1 mm ÷ 500 mm/s = 2 ms.

Frame size. 6,000,000 px × 1 byte/px = 6,000,000 bytes ≈ 6 MB.

Transfer over GigE. 6,000,000 B ÷ 110,000,000 B/s = 0.0545 s ≈ 55 ms.

Processing. Budget values for a mid-range controller: preprocess 8 ms, locate 15 ms, measure 6 ms, decide and I/O 2 ms. Locate time scales roughly with the searched pixel count, so halving the search window roughly halves its share.

Serial cycle. 2 + 55 + 8 + 15 + 6 + 2 = 88 ms. Margin = 600 − 88 = 512 ms, an 85% headroom. Pass — with room for a re-trigger and an image write.

The same camera on Fast Ethernet. 6,000,000 B ÷ 11,000,000 B/s ≈ 0.545 s = 545 ms. Cycle = 2 + 545 + (8 + 15 + 6 + 2) = 578 ms, margin 22 ms, about 4%. One retransmission or one no-part frame with a 50 ms timeout and the station misses takt. Fail.

The Fast Ethernet ceiling at this takt. Transfer may consume 600 − 33 = 567 ms, so the largest frame is 0.567 s × 11 MB/s ≈ 6.2 MB, about 6.2 MP. A 6 MP sensor fills that ceiling entirely. The decision: at a 600 ms takt, Fast Ethernet is a ≤3 MP interface — a 3 MB frame transfers in 273 ms, the full cycle lands at 306 ms and the margin is 49% — while 6 MP belongs on GigE. That is the class of the HK-TD032-12-WBN, a 1.6 MP mono vision sensor on Fast Ethernet.

When a built station drifts and frames start going missing, the pattern is acquisition faster than processing: fix the frame-rate gap.

Transitions, guards and timeouts

Each state gets one success transition, one or more named failure transitions, and a timeout. A concrete guard for the locate state: match score at least 0.7 passes, anything below exits through the NO_PART transition, and the state holds a 50 ms timeout.

The timeout is not decoration. A trigger that never arrives, a camera that drops mid-cycle and a part that stops in front of the lens must all leave through bounded paths, or the machine sits in LOCATE forever while the conveyor backs up. The missing-part path exits within the timeout, outputs a NO_PART code and returns to idle: a missing part costs one takt slot, never a line stop.

The same table exists one layer down at the camera itself: idle, open, running. A second application asking to open an already-open camera gets refused, which shows up as nodes that will not write — GenICam node not writable: check camera access state is that layer's state machine doing its job.

One long script or a state machine

A script is still the right shape for a one-shot lab evaluation or a station with a single check and no line consequences. The state machine pays for its structure once several checks share a trigger, a takt must be held, or an operator needs to know why a part failed.

Where the sequence runs: smart camera or vision controller

Run all seven states on the device when one camera does one check, the cycle budget fits the camera's processor, and the result leaves over discrete I/O or fieldbus. The PLC program stays untouched — the inspection is just a network node with a pass/fail bit.

For a station in that class, the MV-SC5060XM-08M-WBN carries the whole loop: 6 MP mono over GigE with an 8 mm M12-mount lens.

Move the states to a controller when several cameras must expose on one shared trigger (multi camera exposure synchronization with a shared trigger), when results feed a register handshake or a database, or when the locate state alone eats the camera's budget. The controller hosts every state centrally, the cameras become acquisition devices, and the strobes are driven from the same state machine.

The MV-VC5525-256G70-NN is built for that role: PoE camera ports, 8 built-in light channels, 32 GB of memory and an Intel Core i5 processor.

Three parts from the catalog span the whole decision — a color smart camera with its own multi-color light source, an entry controller that ships with its runtime license, and a compact Fast Ethernet vision sensor:

Browse smart cameras and vision controllers to compare the full ranges side by side.

What this architecture does not fix

State structure organizes work; it does not create image quality. If the feature is not in the pixels with contrast to spare, no transition tree recovers it. Lighting and exposure belong in the loop as designed states, with ambient variation handled deliberately (ambient light variation in pick and place vision: control it) — not left to an auto-exposure that the decide state's own feedback can destabilize (auto exposure ROI instability from detection feedback).

Two more limits. Fragmenting work into micro-states adds bookkeeping to every cycle, so keep one state per job, not per function call. And an AI or deep-learning check belongs inside a deterministic wrapper: the states around the model stay rule-based so the station keeps a fixed, auditable decision path — AI vs rule-based smart camera inspection: how to choose covers that split.

Commissioning checklist

1. Write the state list before opening any software: one verb per state, idle to output.
2. Give every state a pass guard, a named failure transition and a timeout.
3. Fill the cycle budget with measured per-state times and keep the serial cycle under half the takt.
4. Size the interface from the frame: bytes = pixels × bytes per pixel; transfer = bytes ÷ effective throughput.
5. Set exposure and light output as explicit values in the acquire state, not as a running auto-exposure.
6. Alarm on any per-state time that doubles against its commissioning baseline.
7. Test the failure paths on the bench — block the trigger, hide the part, pull the cable — and confirm each exits in bounded time.

Build the station around the sequence, not the other way round. Pick the camera in the smart-camera finder or start the configurator at the camera step; if you send the state list and the takt through the contact page, we will return a parts list that fits them. More build notes sit under the systems topic.