Multi-camera end-of-line inspection: sizing the cycle time

The specification on the table: one machined casting every 6-10 s, up to six cameras, presence checks on several faces and one label to read. Before choosing a language, a library or a PC, size the cycle — the cycle decides the architecture, and the architecture decides whether the tooling choice matters at all. This guide walks the budget backwards from the 6-10 s takt to per-camera exposure, transfer and processing times, works the arithmetic on a six-camera station with every number shown, and ends with a decision you can write into the contract. Each figure below is a declared example input; your measured handling and processing times drop into the same formulas.

The decision: one trigger, one port per camera, sequential processing

Fire all cameras together on one hardware trigger inside the same stationary lighting window, give each camera its own network port, and process the six frames one after another while the part indexes to ejection. The cycle time then stops being six lots of acquire-plus-process and becomes handling plus the slowest single acquisition plus the sum of processing.

On the worked example below that sums to about 4.2 s against a 6 s takt: 1.0 s handling + 0.15 s acquisition + 3.0 s processing, leaving a margin of roughly 30%. Any development environment that can run six asynchronous capture sessions and feed a processing queue can implement this, so choose the environment on team experience and library support, not on the clock.

Budget the cycle backwards

Design to the worst case of the 6-10 s specification: 6 s per part. The planning slot for cameras fired one after another is:

At the 10 s end the same division gives 1.7 s per camera. Treat the slot as a ceiling to check against, not a target. A shared hardware trigger collapses it: all six exposures overlap inside one 5-10 ms lighting pulse, the transfers run in parallel on separate ports, and acquisition shrinks to the slowest camera's exposure plus transfer.

Even firing the cameras back to back stays inside the slot at these frame sizes: five 46 ms transfers plus one 110 ms transfer is 0.34 s of transfer alone. The shared trigger is still the right design — it holds every view in one lighting state, keeps the timing deterministic, and lets processing of the first frame start while the later frames transfer.

Size each camera before you budget it

Resolution comes from the smallest feature each view must confirm, not from a camera brochure:

The label view: characters 2 mm tall, read reliably at 30 px per character, FOV 60 mm. That is 60 × 30 / 2 = 900 px across the field, and a 2448-pixel-wide 5 MP sensor clears it with a 2.7× margin — 5 MP carries the label check, while 12 MP buys field of view rather than sharpness. The presence views: a 1 mm groove confirmed at 3 px across, FOV 120 mm → 120 × 3 / 1 = 360 px. Any current sensor clears that, so mount, shutter type and interface decide those cameras, not pixel count.

Exposure: a stationary, strobed view exposes for the light pulse, typically 0.1-5 ms. Where the part moves under a view, cap exposure at one pixel pitch of travel: pitch = 60 mm / 2448 px ≈ 0.025 mm, so at 100 mm/s the cap is 0.025 / 100 = 0.25 ms. The moving-case arithmetic is set out in exposure time vs shutter speed for moving-part inspection.

For the presence views, a compact 2.5 MP global-shutter GigE camera of this class keeps frame bytes small and cabling simple:

Where one view needs the larger field, the 12 MP class covers it:

What the controller and the network must carry

Six views want six camera links and six strobe channels. The vision controllers print the counts that matter on the card: LAN port count, PoE camera ports, built-in light channels and memory.

Six camera ports and six strobe channels point at the larger tier. The MV-VC5525-256G70-NN pairs a Core i5 with 32 GB memory, 5+ LAN ports, PoE camera ports and 8 built-in light channels — one box carrying the whole station. The MV-VC3301H-128G66 keeps the same 5+ LAN ports with 8 GB memory and 4 built-in light channels, which suits stations that strobe fewer views or drive strobes from an external light controller.

All 2 share: Humidity 20% RH to 95% RH (no condensation); Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

If a switch sits between cameras and controller, the uplink carries the sum of all frames. Six 5 MB frames = 30 MB, and 30 / 110 ≈ 0.27 s — harmless. Six 20 MP color frames at 60 MB each = 360 MB, and 360 / 110 ≈ 3.3 s — more than half of a 6 s takt. One port per camera removes the shared-link question; where a switch must stay, run the divide-the-link arithmetic from the multi-camera GigE bandwidth budget guide.

Triggers, time-stamps and the acquisition loop

One trigger line into all six cameras during the stationary window — hardware trigger, not software. A software loop starts each exposure at a different instant and drifts with CPU load, so the views stop sharing one lighting state.

Then confirm what actually happened: latch each frame's exposure-end time from chunk data and compare across cameras — the chunk data timestamp guide shows the latch. Structure the capture so no camera's wait blocks another: one wait call per frame with a timeout, as in the frame timeout guide. The session layout of queues and buffers is worked through in the multi-camera acquisition session architecture guide, and the pattern for processing that trails acquisition is in fixing the frame-rate gap.

Where this budget breaks

• One loop that waits. Capture, process, capture again serializes every camera behind every algorithm. Keep two loops: acquisition fills a queue, processing drains it.
• A shared uplink with large frames. The 3.3 s color case above eats the budget — divide the link or give each camera a port.
• Processing overrun. Cut pixels before buying compute: process ROIs around each feature and bin where resolution allows — 4x4 binning vs 2x2 shows why the sensor, not the software, sets that win. Halving the pixels halves the transfer, and most checks scale with pixels too.
• Image quality drift. The 0.4 s-per-check figure assumes clean, high-contrast images; the lighting-first discipline in stable 2D vision inspection systems is what keeps processing near those figures. A flaky image costs more cycle time than a faster CPU saves.
• Handling creep. Index strokes lengthen at production speed with fixtures loaded. Measure handling at full load, not on an empty table.

Does the development environment change the budget?

None of the four budget terms — exposure, bytes, link rate, processing — knows which language the loop was written in. What the environment changes is how quickly the station gets built. Text-based toolkits expose the camera SDK calls directly and leave the timing model in your hands; graphical environments assemble the pipeline faster and some generate the acquisition skeleton for you, at the cost of a timing model you must read carefully. Underneath, both talk to the same camera SDK. The trade-offs are compared in choosing a machine vision development environment.

Put the architecture in the contract, not the tool: the takt, the margin and the measured processing times on the delivered hardware. When the question starts one level higher — whether an end-of-line vision scope makes sense and where its boundaries sit — the same budget-first method applied to a filling line is in this end-of-line vision selection walkthrough.

Checks before you commit

• Handling time from the index-table datasheet at production speed, fixtures loaded — the number most often quoted optimistically.
• One trigger reaching all six cameras inside the stationary window, and every frame present with its exposure-end chunk time-stamp.
• Per-frame processing measured on the delivered controller with worst-case parts: the dirtiest casting, the densest label.
• Margin of at least 30% of the takt at the fastest spec point — 1.8 s of the 6 s in the worked example.
• Port map: one LAN port per camera, and strobe channels at least equal to strobed views.
• Reject path timed separately: if ejection runs serially after the verdict, it must fit inside the next index stroke or it adds to the takt.
• Cable plan: GigE reaches 100 m per hop; USB3 passive cables run about 3 m. Set camera positions to the interface, not the other way round.

When this answer is wrong

• Parts arrive faster than about one per second, or present as a continuous web: the clock moves to line scan, where exposure, line rate and encoder set the pace — the under-vehicle line scan system plan works that case.
• The check is geometry — depth, volume, flatness — rather than presence: a 3D sensor changes both the acquisition model and the processing cost, as in the 3D cylinder head volume measurement case.
• The camera rides a robot between views: robot motion joins the budget and the cycle planning changes — see collaborative robot vision inspection: plan a reliable cycle.

Bring the takt, the fields of view and the check list to a quote request — the budget above is the first thing we check with you. To browse the sensor classes used here, start at the area scan cameras category or the camera finder, and pair camera to lens at the camera configurator step. More station-level budgets like this one sit on the systems topic page.