Updated July 2026 · 7 min read · Adente Vision Engineering Team
What is the latency budget of an inspection cell?
The latency budget of an inspection cell is the total time allowed from the moment a part triggers the camera to the moment a pass/fail result reaches the controller and acts. If a cell indexes a new part every 400 ms, every stage of the vision check, capture, inference, decision and the I/O signal, has to complete inside that window with margin to spare. Miss the budget and the reject fires on the next part, or the line stops.
That budget is a chain, not a single number. Each stage adds time, and the slowest, least predictable stage sets whether the cell holds its cycle. The engineering job is to know where each millisecond goes and to remove any stage whose timing you cannot bound.
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 is built to close that chain on-device so the decision never leaves the cell to be made.
Where does the time go, from trigger to reject?
The path from a part arriving to a reject actuator firing runs through five stages: trigger, capture, inference, decision and I/O. Four of them are small and predictable. One, inference, is where the real compute cost sits, and it is the stage a cloud architecture moves off the line.
| Stage | What happens | Where the time goes |
|---|---|---|
| Trigger | Encoder pulse, photoelectric sensor or fixed interval fires | Sub-millisecond and deterministic when hardware-triggered |
| Capture | Global-shutter frame exposed and read out | Fixed by exposure and sensor readout, not by the network |
| Inference | Hybrid classical CV plus AI classifies the part on-device | The main compute cost; about 30 ms measured on a live cap-inspection line |
| Decision | Pass/fail resolved against the threshold | Negligible; runs on the same board as inference |
| I/O emit | Result driven onto a 24V output or a fieldbus tag | Sub-millisecond on discrete I/O; protocol-cycle-bound on fieldbus |
Read down the table and the pattern is clear: with hardware triggering and on-device inference, every stage has a bound you can measure and hold. The measured field result on a live cap-inspection line is about 30 ms per part, and the conservative catalog bound is 0.5 s per part at 100+ parts per minute. Treat those as the envelope: the number you can commit to for your own cycle needs an application-specific measurement on your parts, lighting and index time.
Why does a cloud round-trip break the budget?
A network round-trip is the one stage in the chain you cannot bound. Send the image to a cloud model and the pass/fail now depends on link latency, queueing, packet loss, a retransmit, a busy shared server and the return hop, none of which your PLC controls. The average case may look fine in a demo, but a latency budget is set by the worst case, not the average, because the part that arrives during the one slow round-trip is the part that ships uninspected or halts the line.
On-premise servers narrow the problem but do not remove it. A camera to frame-grabber to PC to GPU path still crosses cables, a switch and an operating-system scheduler, each adding jitter. The point of edge inference is to collapse that path: capture and compute happen on the same board inside the enclosure, so the variable network hop is gone and the decision time is dominated by the inference itself.
How does about 30 ms of edge inference fit a fast index cycle?
About 30 ms per part is the measured field result on a live cap-inspection line, small enough to sit inside most fast index cycles with room for the mechanical reject to act. On a line running 100+ parts per minute, the per-part window is well under a second, and an inference that lands in the tens of milliseconds leaves the rest of the budget for indexing, settling and actuation.
The hybrid design is what keeps that number stable. Adente Vision combines classical computer vision for measurement with AI inference for judgement, running on a fanless Jetson-class edge board of 8-16 GB inside the unit. There is no PC to boot, no GPU server to share and no cloud queue to wait on, so the inference time you measure at commissioning is close to the inference time you get on the thousandth part. Because triggering comes from an encoder pulse, a photoelectric sensor or a fixed interval, capture is locked to the part rather than to a timer, which keeps the part centred in frame and the exposure consistent, both of which keep inference fast and repeatable.
Discrete I/O or fieldbus: how should the pass/fail reach the PLC?
Once the decision is made, it has to become a signal the PLC already understands, and there are two clean ways to send it. Discrete I/O is the lowest-latency path: the unit has 4 inputs and 4 outputs at 24V, so a pass/fail can drive a reject actuator or a good/bad lane gate directly, in sub-millisecond time, with no protocol stack in the way. Use it when the reaction has to be immediate and the information is one bit.
A fieldbus is the right choice when the result carries more than pass or fail. Adente Vision speaks PROFINET, EtherNet/IP, Modbus TCP, EtherCAT and OPC UA, so a variant code, a defect reason or a measured dimension can travel as a tag on the network your controller already runs. The trade-off is that the signal is now bound to the protocol's update cycle, which on an industrial real-time fieldbus is still deterministic and well inside a typical inspection budget. A common pattern is to do both: a discrete output for the hard, fast reject, and a fieldbus tag for the reason code and traceability record the MES logs behind it.
For the wider edge-versus-cloud trade-off behind this latency argument, see the sibling post on edge vs cloud visual inspection; for the full method, see the pillar guide on AI visual inspection. For the hardware that closes the chain on the edge, see the Adente Vision system overview.