Updated July 2026 · 7 min read · Adente Vision Engineering Team
What is a cycle-time budget for inspection?
A cycle-time budget is a per-part accounting of every millisecond an inspection step consumes, set against the time the line allows for that step. You list each activity the station performs, trigger, capture, inference, output, add them up, and compare the total to the window the index line leaves open. If the sum fits inside the window with margin, inspection is not the bottleneck; if it does not, the station gates line speed.
Building the budget before you buy or place a station is what stops a late surprise. A unit can be accurate and still be too slow for a fast index line, and the only way to know in advance is to write the budget down and check the total against takt. The manufacturing KPI definitions for takt time, cycle time and throughput used here are standardised in ISO 22400-2.
Takt, cycle and inspection time: which one bounds you?
Three time figures govern the line, and confusing them is how a budget goes wrong. Takt time is the available production time divided by customer demand, the beat the line must hit to meet the order. Cycle time is what a station actually takes to process one part. Inspection time is the slice of the cycle the vision step consumes. Inspection must finish inside the cycle, and the cycle must be at or under takt for the line to keep up.
On a fast index line, the window for inspection is not the full cycle: the part has to index into position, settle, get inspected, and index out, so the real inspection window is the dwell time while the part is stationary and in frame. At 100 parts per minute the whole cycle is 600 ms, and the usable inspection dwell inside that is smaller once you subtract index and settle. Budgeting against the dwell, not the full cycle, is what keeps the number honest.
How do you budget capture, inference and I/O settle per part?
You budget by splitting the per-part window into named line items and assigning each a time, then summing. The four that always appear are trigger-and-settle, capture-and-exposure, inference, and I/O settle-and-emit, plus a margin for jitter. Each is driven by a different part of the cell, so each is tuned separately.
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. Because it runs inference on a fanless edge board inside the enclosure, the inference line item is a local computation rather than a network round-trip. On a delivered cap-inspection line the measured inference was about 30 ms per part, and the catalog bound is 0.5 s per part with throughput of 100+ parts per minute. Treat those three figures as an envelope: the ~30 ms is a real field result, the 0.5 s is a conservative upper bound, and the number you commit to for your own cycle needs an application-specific measurement on your parts and lighting.
How do the cycle-time budget line items break down?
Each line item covers a distinct activity and is driven by a distinct part of the cell, which is why they are tuned independently. The table names them and what governs each, rather than assigning fixed milliseconds that only a measurement on your parts can supply.
| Budget line item | What it covers | What drives it |
|---|---|---|
| Trigger and part settle | Detecting the part and letting it stop moving | Encoder or photoelectric trigger, conveyor and fixture mechanics |
| Capture and exposure | Acquiring one sharp frame | Light intensity, exposure time, 12 MP global-shutter readout |
| Inference | The model decides pass/fail or variant | Model size and edge compute; measured ~30 ms/part on a delivered line |
| I/O settle and emit | Sending pass/fail to the PLC, actuating a reject | Fieldbus scan time or 24V discrete I/O timing |
| Margin | Headroom for jitter and worst-case parts | How tight takt is against the summed window |
Where do lighting and trigger jitter eat the budget?
Lighting and trigger jitter are the two line items that quietly consume budget, because both trade directly against capture time. A dim scene forces a longer exposure to get a usable image, and a long exposure both eats milliseconds and risks motion blur on a moving part, so brighter, controlled lighting buys back capture time. A global shutter helps here: it exposes the whole sensor at once, so a fast-moving part is frozen without the skew a rolling shutter adds, and the camera characterisation standard behind these sensor behaviours is EMVA 1288.
Trigger jitter is the variation in when capture actually fires relative to the part's position. If the trigger wanders, you either widen the capture window to be safe, spending budget, or you risk capturing the part slightly out of position. Triggering off an encoder pulse or a photoelectric sensor rather than a fixed time interval locks capture to the part itself, which tightens jitter and lets you run a smaller, more reliable window.
When is a single viewpoint the real constraint?
A single viewpoint becomes the constraint when the check needs surfaces that one camera position cannot see in one capture. One unit is one viewpoint, so a part that must be inspected top and side, or all the way around, either needs multiple capture positions, which multiplies the time budget, or multiple units, which multiplies cost rather than time. Deciding this early prevents a budget that assumed one shot from failing on a part that needs three.
When one viewpoint does cover the check, the per-part budget stays simple, and a station that decides on-device in the tens of milliseconds leaves room under a fast cycle. When it does not, the honest budget accounts for every capture the coverage requires, and the coverage question, not raw inference speed, is what sets the total. For the latency and data-path side of why on-device timing is predictable, see the sibling post on edge versus cloud inspection; for the full method, see the pillar guide, and to see the hardware the budget rests on, the camera, lighting and edge compute in one box, browse the system.