Updated July 2026 · 6 min read · Adente Vision Engineering Team
Why does deterministic timing matter at 100+ parts per minute?
Deterministic timing matters because at high throughput the window to act on each part is small, and jitter in that window is what puts a reject on the wrong part. At 100 or more parts per minute the cell has well under a second per part end to end, and the inspection result has to land inside a predictable slice of that cycle, not "soon."
The imaging side already assumes fast motion: a 12 MP global shutter freezes a moving part without smear, so the capture is sharp even as the line runs. What determinism adds is on the network side, keeping the moment the result is delivered aligned with where the part is in the motion cycle. If the delivery time drifts from part to part, the reject actuator downstream can act a part early or a part late.
Adente Vision is an edge-AI visual inspection unit built by ADENTE Advanced Engineering Technologies, part of the Aden Group, sold through automation system integrators, and it supports EtherCAT alongside the other four protocols, so a cell that already runs a deterministic motion bus can carry the inspection result on the same timing discipline.
How does EtherCAT differ from PROFINET and EtherNet/IP for a fast cell?
The practical difference is timing character, and in industrial automation EtherCAT is the one usually reached for when cycle determinism is the hard requirement. As the EtherCAT Technology Group describes it, the protocol processes frames on the fly and uses distributed clocks to synchronize nodes, which gives low, predictable jitter across a fast cell.
PROFINET and EtherNet/IP are real-time capable and dominate their installed bases, PROFINET on Siemens controllers and EtherNet/IP on Rockwell, and for most inspection cells either is entirely sufficient. The case for EtherCAT is narrower: a cell where the inspection result must be tightly synchronized with motion and other axes, at a cycle where ordinary jitter would misplace the reject. Treat this as industry context for the protocol, not a spec of any one product.
So the selection follows the cell, not fashion. If the line already runs EtherCAT for motion, carrying the inspection result on it keeps one timing domain. If it does not, adding EtherCAT only for pass/fail is rarely worth it.
How do you align the inference window to the motion cycle?
You align the inference window by treating the model's decision time as a fixed budget inside the cycle, then placing the reject point far enough downstream that the decision is always ready before the part arrives. The measured field result is about 30 ms per part, and the catalog bound is 0.5 s per part at 100 or more parts per minute; the number you can commit to for your own cell depends on your parts and lighting and needs an application-specific measurement.
With a known inference budget, the integration is arithmetic. Trigger capture off the encoder or a photoelectric sensor when the part is in frame, allow the inference window, and position the reject actuator so the transport time from inspection to reject exceeds that window plus margin. On a deterministic bus the delivery of the result is predictable, so the margin can be tight rather than padded for worst-case jitter.
The reject itself usually rides a discrete output, not the reporting layer. The unit has 4 outputs at 24V, so the fail bit can drive an air blast or a diverter directly while EtherCAT keeps the coded result and the motion in step.
Protocol timing character for an inspection cell
Timing character below is general industry framing for each protocol, not a measurement of any one unit.
| Protocol | Timing character (industry) | Reach for it when |
|---|---|---|
| EtherCAT | Deterministic, low jitter, tight cycle synchronization | Motion-synchronized, high-speed cells |
| PROFINET | Real-time capable, broad Siemens installed base | Siemens lines without a hard cycle-sync need |
| EtherNet/IP | Real-time capable, broad Rockwell installed base | Rockwell lines, general integration |
| Modbus TCP | Simple, non-deterministic | Neutral reporting where timing is not critical |
When is determinism not the constraint?
Determinism is not the constraint when the line is slow enough, or the reject point far enough downstream, that ordinary network timing already lands the result in time. If a part spends seconds between inspection and reject, a few milliseconds of jitter changes nothing, and a simpler bus or plain discrete I/O does the job.
Buffering also relaxes the requirement. When parts queue in a defined order between the inspection point and the reject, the cell can track the result by position and act on it later, so the exact delivery instant matters less than the ordering. In that design the value of a deterministic bus falls, and 4 discrete outputs may carry everything the cell needs.
So reach for EtherCAT when motion synchronization at high speed is the real limit, and not by default. For the metric that decides whether a fast reject is even trustworthy, see the sibling post on the false-negative rate, and for carrying structured results to MES rather than firing a reject, see the note on OPC UA for inspection. The full method is in the pillar guide, and the connectivity behind this sits on the Adente Vision system page.