Getting a machine vision pass/fail decision from software running on an edge compute unit to a PLC-controlled reject actuator — in time for the actuator to fire before the defective part passes the reject gate — is a latency problem. It looks simple from the outside: classify the part, send a signal, reject it. In practice, the latency budget is tight, the failure modes are asymmetric, and there are enough places in the signal chain where timing can break that it pays to understand each segment.
This post walks through the integration architecture we use for Procunit deployments — from the camera trigger to the actuator output — and where the latency goes at each stage.
The latency budget
Start with the mechanical constraint. At 120 ppm, a part passes one station per 500ms. The inspection station is typically upstream of the reject gate by some physical distance — often 200–400mm depending on the line layout. At typical conveyor speeds of 0.3–0.5 m/s, that separation represents 400–1,300ms of transport time between inspection and rejection.
That sounds comfortable, but the part is still moving during the entire vision-to-PLC-to-actuator sequence. The reject gate must be positioned with accurate timing relative to when the defective part arrives — too early and a good part gets rejected; too late and the defective part passes through. Industrial air-blast or diverter gate actuators typically have 20–50ms mechanical response times. PLC ladder logic scan cycles add another 2–10ms depending on the controller and program complexity.
For the vision system, a practical total latency budget from trigger pulse to PLC data available is 8–15ms on a well-configured system. This leaves margin for the PLC's own processing and the actuator mechanical response, while keeping the total timing accurate enough for precise gate positioning.
Stage 1: Trigger and frame capture
The camera trigger should come from the PLC or from a photoelectric sensor whose output is monitored by the vision system — not from a software timer on the vision PC. Software-side polling introduces jitter in the single-digit millisecond range that accumulates into positioning errors at high line speeds.
GigE Vision cameras support hardware triggering via GPIO lines. The trigger signal latency from the I/O line input to frame exposure start is typically under 1ms on most industrial GigE cameras. The exposure time itself is set to minimize motion blur at line speed — for a 120 ppm line with 50mm parts moving at 0.35 m/s, a 0.5ms exposure is at the borderline of acceptable blur for fine defect detection. Many deployments use strobe-synchronized illumination (a bright LED strobe synchronized to the trigger) which allows longer effective exposure without motion blur by illuminating only for the strobe duration.
Frame readout over GigE Vision at 5MP resolution takes approximately 8–12ms depending on camera and network conditions. This is often the single largest time segment in the chain, and it's why cameras with partial scan (reading only the ROI rather than the full sensor) can make a meaningful difference when the part occupies a fraction of the field of view.
Stage 2: Inference
The inference time for a Procunit model on a dedicated edge unit running ONNX Runtime with INT8 quantization is typically 3–8ms for a standard classification task at 640px input. Detection tasks (bounding box localization rather than binary classification) are slightly slower — 6–12ms — but provide the localization information needed to log defect position for process diagnostics.
The key here is consistency, not just average speed. A model that averages 6ms but spikes to 30ms occasionally will cause misses on the spike cycles. Using ONNX Runtime's deterministic execution mode and locking CPU affinity for the inference thread reduces jitter significantly compared to a default PyTorch inference deployment. On dedicated edge hardware with a real-time OS or PREEMPT_RT kernel, 95th-percentile latency stays within 2ms of the median.
Stage 3: PLC communication
For Rockwell Automation environments, EtherNet/IP Class 1 (implicit messaging) with a 2ms RPI (Requested Packet Interval) gives deterministic pass/fail delivery without requiring the vision PC to initiate a new TCP connection for each part. The I/O image is continuously updated; the PLC reads the latest value on its next scan. Total latency from data-ready on the vision side to PLC register updated is typically 2–4ms with this configuration.
Modbus TCP is simpler to configure and works with a broader range of PLCs (Siemens, Mitsubishi, Beckhoff, and many others). The tradeoff is that Modbus TCP is a request-response protocol — the vision system must initiate a write, and the PLC must process it. Latency is 2–5ms in typical industrial network conditions, but less deterministic than EtherNet/IP implicit messaging. For most lines running under 150 ppm, this difference is acceptable. Above 150 ppm, we recommend EtherNet/IP where possible.
PROFINET IRT (Isochronous Real-Time) is an option for Siemens environments that need the lowest jitter — sub-millisecond cycle times are achievable. The configuration overhead is higher; it requires managed switches with PROFINET support and careful VLAN configuration to keep vision system traffic isolated from general plant network traffic.
Stage 4: Encoder-based reject gating
The PLC reject logic should not use a fixed timer from the inspection trigger to the reject gate actuation. Fixed timers work only if conveyor speed is constant — and conveyor speed is not constant. Variable-frequency drive speed variations, load-dependent slip, and line acceleration/deceleration all shift part position relative to a fixed timer.
The correct approach is encoder-based tracking. An incremental encoder on the conveyor drive shaft or roller provides position feedback to the PLC in counts. The part position is tracked from the inspection trigger as an encoder count offset. The reject gate fires when the tracked part reaches the gate position in encoder counts, not after a fixed time. This maintains accurate rejection positioning across the full speed operating range of the line.
For Rockwell ControlLogix systems, this is implemented using the Motion Axis object with position-based event tasks. For simpler PLCs, a high-speed counter module reading the encoder and a compare instruction against a setpoint register accomplishes the same result.
Failure mode asymmetry and fault handling
The failure modes in a vision-to-PLC integration are asymmetric in consequence. A false positive (good part rejected) is a recoverable quality event — the part goes to the reject bin, can be retrieved and re-inspected. A communication timeout that causes a defective part to pass through unrejected is an escape event with downstream consequences.
Procunit's integration layer implements a configurable watchdog behavior for communication failures: if the vision system fails to deliver a result within the configured timeout window for a given part, the default behavior is to trigger the reject gate (fail-safe reject). This is the right choice for escape-sensitive applications. For applications where false rejects are extremely costly — expensive sub-assemblies, scarce materials — the watchdog can be configured to hold the reject gate on timeout and instead halt the line, requiring operator acknowledgment before production resumes.
The watchdog timeout itself must be configured with care. Too short and normal inference jitter on complex parts triggers false fault conditions. Too long and the reject gate fires after the defective part has already passed. The correct watchdog window is typically set to 2× the P99 inference latency measured during system commissioning, minus the gate-to-inspection distance transit time.
Commissioning and timing verification
The only reliable way to verify timing accuracy in a production integration is to run seeded defect parts through the live system and confirm that the reject gate fires correctly — not just that the PLC received the signal, but that the part ended up in the reject bin. We run this verification at the nominal line speed, then at ±10% of nominal speed to confirm the encoder tracking holds, then at the maximum acceleration rate the line uses during startup.
Timing verification should be repeated after any changes to conveyor speed setpoints, PLC scan cycle configuration, or vision system software. An integration that commissioning verified at 100 ppm may have subtle timing issues at 130 ppm that don't show up until you're in production. Building the seeded-sample timing check into the commissioning checklist rather than treating it as a one-time activity saves the pain of discovering timing drift during a production run.