Independent exposure per camera: control each head separately

A four-head rig takes exposure commands, but the change meant for one head lands on all of them — or only the first head ever listens. The cause is rarely the cameras. It is the control path: a script that opens one connection to whichever device the driver lists first, or walks every device in a loop and applies the same setting to each. This guide shows how to give every head a path of its own, opened by serial number and kept open for the session; how to run different exposure times per head against one shared trigger; how much bandwidth four heads really need; and how to prove from logs that each head holds its own setting. The same pattern covers GigE, USB3 and GenTL heads, from full-size area scan cameras to compact board-level cameras.

Why does one exposure change land on all four heads?

Because the control path is shared: the script opens one connection to whichever device the driver lists first, or it loops over every device and applies the same setting to each, so nothing in the path distinguishes one head from another.

Most demo scripts hold either a single device object or a list they iterate. A write to a shared object reaches whichever head that object was opened on — one head, seemingly at random. A loop that applies the same write to every handle reaches all heads at once. Neither path can express "this head only", so no parameter value you send can be per-head. The fix is architectural: give each head its own connection, addressed by a stable ID, and route every command through the connection for the head you mean. Acquisition code already lives under this rule — one acquisition object per camera in one process — and control calls deserve the same separation.

How do you open each head by its own ID?

Open by the serial number printed on each head, never by enumeration index. On GigE Vision and USB3 Vision heads the serial survives re-plugging, reboots and added cameras, while an index is only the order the driver happened to scan the bus that morning.

Enumerate once, write down the serial each head reports, and treat that serial as the head's address for the life of the station. GigE Vision heads also carry a MAC and an IP address, so a persistent-IP plan keeps addresses stable across power cycles. On board-level modules the serial is usually printed on the board or reported at first boot; record it before the module goes into its housing, where labels become hard to reach. Keep the serial-to-role map next to the station wiring diagram, and "which camera is which" stops being a guessing game after the first rewiring.

What does a per-head control path look like in code?

One handle per head, opened once at start-up, kept open until shutdown, stored in a dictionary keyed by serial number. A control command is then a method call on one handle, and the other heads never see it.

1. List every head's serial number and write the serial-to-role map before you write code.
2. At start-up, open one device handle per serial and fail loudly if a serial is missing.
3. Route every exposure, gain and feature write through the handle of the head you mean.
4. Read the value back from the same handle after each write and log it with the serial.
5. Keep all handles open until shutdown; reopening resets features and quietly brings the broadcast habit back.

# Illustrative names: open_by_serial / write_feature / read_feature stand in
# for your SDK's equivalents. "ExposureTime" is the GenICam standard feature name.
exposure_us: dict[str, float] = {"HEAD-A": 5000.0, "HEAD-B": 15000.0}  # key = serial
handles: dict[str, object] = {}
for serial, value_us in exposure_us.items():
    handles[serial] = open_by_serial(serial)               # one path per head
    handles[serial].write_feature("ExposureTime", value_us)
    assert abs(handles[serial].read_feature("ExposureTime") - value_us) < 1.0

For the exact calls against a GigE or USB3 Vision head — node names, types and units — see Setting camera exposure time through a GenICam API in Python.

How do you run 5 ms on one head and 15 ms on the next?

Write 5000 μs to one head's handle and 15000 μs to the other's; a shared hardware trigger keeps working, because the trigger line only starts each exposure while each head's own exposure-time setting decides its length. At 30 fps the 33.3 ms period clears the 15 ms head with room to spare.

Both values sit inside one 30 fps cycle: 1000 ÷ 30 = 33.3 ms per frame, so the 15 ms exposure leaves 18.3 ms for readout and transfer. The trigger edge starts both heads together; exposure duration is a per-head feature, not a per-system one. Gain — the "sensitivity" dial in most demo tools — rides the same per-head path: write it through the head's own handle and it moves one sensor, not four.

Heads with software-exposed exposure and gain features carry this pattern — global shutter preferred where parts move. The trio below spans 2.5 MP GigE and 12 MP USB3 options.

How much bandwidth does each head really need?

One head's link load is pixels per frame times bytes per pixel times frames per second. A 12 MP Mono8 head at 30 fps moves 360 MB/s — just over three GigE links — while one USB3 link takes it with headroom to spare.

A 12 MP Mono8 frame is 12,000,000 pixels × 1 byte = 12 MB; at 30 fps that head draws 360 MB/s. One GigE Vision link carries roughly 118 MB/s of usable payload — about 950 Mbit/s of its nominal 1 Gbit/s — so this head needs its own fast link; on USB3 it fits under the interface's practical ceiling near 400 MB/s. The two-head rig from the last section is lighter: 2,500,000 pixels × 1 byte × 30 fps = 75 MB/s per head, so two heads draw 150 MB/s, more than one GigE link. Either give each head its own link, or cap both at 20 fps: 2 × 50 = 100 MB/s, which fits one link with only 18 MB/s of margin. That squeeze is a decision to make on purpose, not a surprise to find at install.

For what each interface standard guarantees — and where 2.5G and 5G Ethernet fit — see 5GBASE-T camera interface: bandwidth, cables and distance and Machine vision connectivity standards: what each one does.

When do four heads need a vision controller instead of a desktop PC?

When the two-head example grows to three or four GigE heads, add LAN ports rather than improvised links: a controller with 5+ LAN ports gives every head its own GigE link in one box, and PoE models carry each head's power over the same cable as its data.

A desktop with one Ethernet port serves one head cleanly; the classic fix is a multi-port network card. A vision controller builds the ports in, alongside the light-control channels a multi-head station needs anyway. The MV-VC5525-256G70-NN pairs 5+ LAN ports with PoE camera ports and 8 built-in light channels.

That is one link per head with power on the same cable, plus direct drive for the light stages, in a single addressable box. Spread USB3 heads across host controllers the same way — a head at the loads computed above takes most of one host controller's capacity by itself.

How do you prove each head kept its own setting?

Read each feature back from the same handle right after you write it, then log the exposure time each head reports per frame. The write-time check catches a command that went nowhere; the per-frame log catches something rewriting it later.

A log line per frame — serial, exposure, gain — settles arguments in seconds: if a head's rows read back at the value you wrote, the setting holds; if they drift, something on that head is rewriting it. Two usual suspects: the head's own auto-exposure, which re-aims exposure every frame until you switch that head to manual, and a second application holding the feature lock on the same head. Per-frame exposure and gain: verifying camera metadata walks the metadata checks, and Automatic iris, exposure and gain control in machine vision explains what the auto loop is doing while it overwrites you.

What still goes wrong most often?

Three failures cover most cases: a loop that applies settings to every head, auto-exposure left enabled so it overwrites your value each frame, and handles reopened per command, which resets features to power-on defaults. Each fix is one line.

• The broadcast loop. A start-up script that sets "the same exposure everywhere, to be safe" erases per-head settings on every boot. Address one head per command, or send nothing.
• Auto-exposure left on. Your manual write succeeds, then the head's own loop rewrites it before the next frame. Switch that head's exposure-auto feature off when you take manual control.
• Open, close, reopen. Reopening a head restores power-on defaults, so yesterday's exposure silently reverts. Open once, keep the handle, close at shutdown.
• Two owners, one head. A test tool left connected holds the lock and your writes fail or queue. Disconnect tools before the station runs.

If the demo tool you were handed exposes no per-head controls at all, Camera demo has no exposure or gain controls: what to do covers the workarounds while you build the real path.

Next step: shortlist heads in the camera finder or work from your current camera in the camera configurator. Size the links with the formula above before you order; the cameras topic page collects the neighbouring guides, and the contact page gets you a bandwidth plan for a specific station.