Cut vision system inspection overhead in two-camera cycles

A two-camera inspection can do everything right and still miss its frame rate: acquisition under 2 ms, tools at 20 ms, and a cycle that lands at 35-40 ms when the target is 30 fps. The missing 13-18 ms is rarely the algorithm. It is the display path, cameras configured differently, and what the software does when it enters or leaves run mode. All three are measurable, and all three are fixable in an afternoon of benchmarking. This guide follows the order that finds the culprit fastest: build the frame budget, benchmark per step in run mode, match both cameras' resolution and pixel format, shrink or drop the production display, then deal with the mode-switch defect that points every acquisition step at camera 0. Where the math says a shared PC will never make budget, the way out is hardware that skips the display path entirely.

Why does the inspection run slower than the sum of its tools?

Because the cycle clock runs acquisition, display and software state overhead alongside the tools: at a 30 fps target the whole cycle must fit 33.3 ms, and 20 ms of tools plus 2 ms of acquisition leaves only 11.3 ms for all of it.

Write the budget down before touching a setting. The frame period is 1000 / 30 = 33.3 ms, and every millisecond of the cycle lives inside it.

Worked example, from a two-camera 640 × 480 mono8 cell:

• Acquisition, both cameras: under 2 ms
• Tools: 20 ms
• Measured cycle: 35-40 ms
• Residual for display plus state: 35 - 22 = 13 ms, up to 40 - 22 = 18 ms
• Margin at 30 fps: 33.3 - 22 - 13 = -1.7 ms at best, so the cell is over budget before anything else is added
• Throughput: 1000 / 35 = 28.6 and 1000 / 40 = 25.0 cycles per second

The after column is the target: display back under 5 ms gives 2 + 20 + 5 = 27 ms and 33.3 - 27 = 6.3 ms of margin, which holds 30 fps with room for a worse day. You do not need faster tools; you need the other 13-18 ms back.

What eats the milliseconds between acquisition and the result?

In order of likelihood: image format conversion and rescaling for the display window, overlay drawing, a GUI thread fighting the inspection loop, per-step result handling and logging, and mode-state bookkeeping. A copy alone cannot cost 16 ms: one 640 × 480 mono8 frame is only 0.3 MB.

Rule out transport first, because the numbers are small. One frame is 640 × 480 × 1 byte = 307,200 bytes, about 0.3 MB. Two cameras per cycle move about 0.61 MB, and at 30 fps that is 18.4 MB/s, roughly 15% of a 125 MB/s GigE link. A memory copy of 0.3 MB finishes in well under a millisecond on any current controller. The 16 ms is never the copy; it is one of these, most likely first:

1. Format conversion and rescaling in the display window. If the cameras differ in resolution or pixel depth, the window rebuilds its scaling and conversion path on every switch between camera 0 and camera 1. Test: set both cameras identical and re-benchmark.
2. A display canvas larger than the image. Drawing a 0.3 MB image across a full-screen canvas spends fill time on pixels nobody inspects. Test: shrink the run-mode window to image size or half scale.
3. Overlays drawn every cycle. Test: hide graphics while running.
4. The GUI thread contending with the inspection loop. Test: run with the display off entirely; if the cycle drops by the display figure, the threads are sharing one core.
5. Per-cycle logging and result handling. Test: disable logging for one benchmark run, then buffer results and write them in batches.
6. Mode-state bookkeeping. Entering or leaving run mode re-initializes acquisition; the bad case, where steps start grabbing the wrong camera, has its own section below.

How do I measure where the time goes in a two-camera cycle?

Benchmark per step while the system runs in run mode, not in the editor: a run-mode benchmark shows the display and state overhead that edit mode hides, and the step list tells you whether the 15 ms sits in display, acquisition state changes or the tools themselves.

1. Put the cell in run mode and start the vision software's per-step benchmark. Record at least 100 cycles so one slow part does not set the average.
2. Write the display time per cycle next to the 33.3 ms budget. Anything above 5 ms is a suspect.
3. Turn the run-mode display off completely and re-run the benchmark. The drop is the true display cost; if nothing drops, look at logging instead.
4. Cycle the modes - leave run mode, reopen the inspection view, re-enter - and confirm each acquisition step still fires its own camera. Screenshot the configuration first.
5. Sum acquisition + tools + display. Whatever remains is state overhead; more than 2-3 ms on a cell this size points at logging, result communication or a step firing twice.

The same discipline finds lost milliseconds anywhere on a line; the conveyor cycle-time loss diagnosis works the problem from the production side.

Do both cameras need the same resolution and pixel format?

Yes when one display window shows both: matching 640 × 480 mono8 on both cameras means the window never rescales or reconverts between images, and in the worked cell display time fell from over 16 ms back under 5 ms on this change alone.

A display window keeps one scaling and conversion path per geometry. Give it two geometries and it rebuilds that path on every switch, 30 times a second. Pixel depth compounds the cost: a camera left at 10- or 12-bit doubles the bytes per pixel and adds an unpacking pass before anything can be drawn, and an encoding that silently falls back from what you configured produces the same surprise. mono8 end to end is the cheapest path; when a camera ignores a requested format, check what is actually streaming before benchmarking anything else - the encoding fallback fix shows the request sequence that avoids it.

Shrinking one camera while the other stays full size sounds faster and is not: the shared window still rescales on every switch. If you need fewer pixels, set the same ROI on both cameras and keep the geometries identical. For everything else that makes two-camera cells fragile, the multi-camera capture design guide covers trigger, buffer and failure behavior.

Should the display show full images during production?

No: full-resolution display is a setup tool, and in run mode you should draw a downscaled thumbnail, draw only on failures, or draw nothing, holding display cost under 5 ms of the 33.3 ms budget.

Options, cheapest first:

• No image in run mode: display costs 0 ms and the cycle runs on acquisition and tools alone.
• Half-scale thumbnail, 320 × 240 from 640 × 480: a quarter of the pixels to draw.
• Draw on failure only: near-zero cost while parts pass, full cost only on rejects, which is exactly when you want the image anyway.

Keep the last failed image on screen or on disk so the cell stays diagnosable.

Window layout matters as much as whether the window appears; display ROI design for responsive vision tools covers sizing the window and the overlays to the pixels that matter.

Why do both inspections grab camera 0 after a mode switch?

Because the acquisition steps fell back to the default camera: entering or leaving run mode re-initializes acquisition, and this class of multi-camera defect selects the default camera for every step until a reboot. The lasting fix is the vendor's current software update, not a configuration change.

The signature is specific. The configuration shows camera 0 on one inspection state and camera 1 on the other; the benchmark passes while the system stays in one mode; both states acquire from camera 0 the moment you leave run mode or the inspection view, and a reboot clears it. Nothing in the acquisition parameters causes it. On a mode change or an edit, acquisition steps that each name a camera fall back to the default, which is a known defect class in multi-camera inspection software.

Fix it in the software, not the configuration: install the vendor's current release or service pack - release notes for these updates list the defect where multi-camera acquisition steps select the default camera after saving, reloading or editing - then repeat the mode-change test from the section above as an acceptance check.

Keep it from returning:

• Update the vision software on the controller before commissioning, not after the first line stop.
• Make the mode-change camera check part of the startup checklist.
• Never accept 'reboot to fix' as a production recovery; schedule the update.

What hardware takes display overhead out of the cycle?

Two options: a smart camera inspects on the device and ships only results over the network, so no display path exists in the cycle; or a vision controller with several LAN ports and built-in light channels runs both cameras, the lighting and the display from one box you benchmark once.

The cheapest fix is subtraction: give each view its own inspector and there is no shared window to tune. A smart camera or vision sensor decides on the device and reports pass, fail and coordinates over Ethernet; two of them, one per viewing angle, run two independent cycles with no display between them. The smart cameras category lists the range, and the camera finder filters it by resolution and interface. Two from the current shelf, a mono sensor for geometry and code work and a color sensor for presence and labels:

The HK-TD032-12-WBN is a 1.6 MP mono vision sensor with a global shutter, an M12 lens mount and a Fast Ethernet interface. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter and an M12 mount, also on Fast Ethernet. Both decide on the device, so the 16 ms display problem does not exist to be solved.

When the two views must share timing - one trigger, one light, synchronized results - keep one controller and remove the display instead. The vision controllers category exists for this: several camera ports, built-in light channels, no desktop to composite. The MV-VC3301H-128G66 pairs five or more LAN ports and four built-in light channels with 8 GB of memory and an Intel Core i3 processor. The VM6200Pro license is included; there is no PoE, so the cameras need separate power.

For more cameras or PoE cabling, the MV-VC5525-256G70-NN adds PoE camera ports, eight built-in light channels and 32 GB of memory on an Intel Core i5, with PCIe expansion supported.

If you are specifying a new cell rather than rescuing this one, do the same budget arithmetic at selection time; the vision inspection selection walkthrough for a screw line shows the breakdown done before purchase.

When is the camera the limit, not the PC?

When the acquisition step itself approaches the camera's frame period: at 60 fps the period is 16.7 ms, so an exposure above roughly 10 ms loses frames no matter how fast the controller is. Under 2 ms of acquisition means the camera and link are innocent here.

Use acquisition time as the dividing line. Under 2 ms against a 16.7 ms period is 12%, so the camera delivered promptly and the PC side owns the problem. When acquisition climbs toward the frame period, the limits move to the camera side, in this order: exposure that no longer fits the period, then link bandwidth, then camera configuration. Exposure must fit inside the period: 16.7 ms at 60 fps puts the practical ceiling near 10 ms, while 33.3 ms at 30 fps gives proportionally more room. Bandwidth: the same two cameras at 60 fps move 2 × 307,200 × 60 = 36.9 MB/s, about 30% of GigE, still comfortable; at higher resolutions or packed 12-bit formats, run this sum before blaming the controller. When acquisition and processing race each other, the acquisition-versus-processing frame-rate gap fix walks the split.

Which fix do I apply first?

Apply them in this order: match both cameras' resolution and pixel format, cut the run-mode display to a thumbnail or nothing, re-benchmark in run mode, and only then change software or hardware - the first two steps recovered 11 ms of the 16 in the worked cell.

Decisions by case:

• Cycle over budget with double-digit display time: match the cameras, shrink or blank the run-mode display, re-benchmark in run mode. The worked cell lands at 27 ms and holds 30 fps with 6.3 ms spare.
• Both inspections acquiring camera 0 after a mode change: update the vision software to the current release or service pack, then make the mode-change camera check part of commissioning.
• Two fixed viewing angles, presence, geometry or code checks: two smart cameras, one per angle; the display path disappears instead of being tuned.
• Shared timing, several cameras, lights to drive: a vision controller with multiple LAN ports and built-in light channels, benchmarked once.

Keep it fixed:

• Identical resolution and pixel format on every camera that shares a window.
• Run-mode display blanked, thumbnailed or failure-only; full display for setup.
• Run-mode benchmark after every software change, not just at commissioning.
• Vision software current on the controller before the line starts.

Point the system configurator at your camera count, formats and cycle target to shortlist hardware that makes the budget, or reach the applications team through the contact page if you want a second pair of eyes on your benchmark numbers.