Apply new camera settings without replug: set, stop or reset

A production camera that has to run two very different setting sets — a short exposure for bright parts and a long one for dark ones, or two resolutions for two inspection steps — too often ends up on a cable that an operator unplugs twice a shift. The replug is never necessary. Exposure, gain and most other options are live: you write them to the running stream and the next frame carries the new value. Only the stream definition itself — resolution, frame rate, pixel format, the set of enabled streams — needs a stop and a restart, and a hardware reset exists for the rare case where the camera stops answering. This guide gives the order to try, the time each method costs, and the recovery path when a restart returns a timeout instead of frames.

The decision: live write, restart or reset

Work through the three methods in this order and the replug disappears from the work instructions.

The costs are the whole argument. A live write is one small control packet — a register write on USB3, a control write on GigE Vision — so budget about a millisecond per option. A restart reopens streams and reallocates buffers: typically 0.5–2 s on a depth camera, and less on most area scan cameras. Measure your own stop-and-start once, then treat that number as the price of a resolution change.

Change these settings on the running stream

Whatever the API calls it — a set_option call in a depth camera SDK, a write to the GenICam ExposureTime feature on an industrial camera — the mechanism is identical: the value applies to the next exposure. Write the option, then trigger, and the captured frame already carries it. The depth camera call looks like this:

sensor.set_option(RS2_OPTION_EXPOSURE, 33000);

The exposure option is in microseconds on this SDK, so 33000 is a 33 ms exposure.

Three habits make live writes reliable:

1. Read the supported range before writing. A value outside the range is the most common reason a write appears to do nothing — query the option range before setting exposure or gain shows the calls.
2. Turn auto-exposure off before writing manual exposure, and on depth cameras set the master auto-exposure switch first: depth camera auto exposure options error: set the master option first.
3. Write options from one thread, between grabs, so a write never races a frame callback.

Gain follows the same pattern — change camera gain at runtime without stopping the pipeline covers the ordering. A value that is fixed for the whole run belongs in the start-up configuration instead: set manual exposure before streaming: initialization order. For pushing settings into a capture that is already running, apply camera settings while streaming without stalling capture is the wider pattern.

On an industrial camera such as the LS-CMR-0166, exposure and gain are ordinary feature writes you can make between frames while acquisition runs.

Triggered cameras gain the most, because the write slots cleanly between pulses. A hardware-triggered GigE model such as the MV-CU020-90GC can carry a different exposure on every trigger pulse, with the option written between pulses.

These settings need a stop and a restart

Resolution, frame rate, pixel format and the set of enabled streams belong to the stream configuration, not to per-frame options: they change how much data the sensor pushes, so the stream itself is rebuilt. The sequence is strict.

1. Stop the pipeline — pipe.stop() in the depth camera SDK, the corresponding stop in a GenICam stack.
2. Build the new configuration. Use only profiles the camera itself enumerates; an invented resolution or frame-rate pair is rejected or quietly replaced, the failure behind 3D camera no matched video stream profile: set a listed depth mode.
3. Start again with the new cfg in place — pipe.start() — and re-apply every live option afterwards, because the restart returned them to power-on defaults.
4. Read back the profile the start call returns and log it.

A start with no configuration opens the camera's default profile, which is usually the wrong one. And a start issued before the previous stop completes leaves the acquisition engine busy: single frame acquisition still busy: why repeated starts need a stop dissects that error. Budget each restart as the downtime you measured above.

Depth cameras: one exposure can serve two streams

Compact depth cameras that generate the RGB image from the same imager as depth have no separate RGB exposure option. One exposure value drives both streams, and it lives on the depth sensor. A report that "the RGB exposure will not change" is almost always this: the option exists once, and you are already writing it.

Exposure also bounds the frame rate on depth cameras — lengthen it past the frame period and the frame rate falls with it: depth camera frame rate drops: exposure settings cap the FPS maps the boundary.

The 3D sensors range, from laser profilers to stereo structured-light models, splits its controls along the same live-versus-restart line. A ToF sensing camera such as the MV-DT01WMU takes exposure writes on the running depth stream.

Worked example: two exposures on one cycle

A station inspects two part types alternately, one part per frame. Castings need a long exposure; bright stamped parts need a short one. Example numbers — put your own in their place.

• The camera runs at 15 fps, so the frame period is 1000 / 15 = 66.7 ms.
• Part A needs 2500 µs of exposure; part B needs 33000 µs (33 ms).
• Readout on this example sensor is about 20 ms, so part B consumes 33 + 20 = 53 ms of the 66.7 ms period — it fits, with 13.7 ms of margin. The full budget method is in maximum frame rate on a hardware trigger: exposure plus readout time.

Live switching: two writes per part change at about 1 ms each, so the cycle stays 66.7 ms and the station holds 1000 / 66.7 = 15 parts per second.

Restart switching: one stop-and-start per change, 1.5 s on this example system, so the cycle becomes 66.7 + 1500 = 1566.7 ms and the station drops to 1000 / 1566.7 = 0.64 parts per second.

The decision: write the exposure before each trigger and keep the stream alive. The restart path buys nothing here because the resolution never changes. When the change you make mid-run is a shorter exposure, watch the trigger timing — reduce exposure time mid-acquisition without an overtrigger error covers that direction.

No frames after the change: causes in order

The symptom: the start call returns, the stream reports open, and the first wait for a frame times out with a "no frames received" message. Work down this list, most frequent first.

1. The start opened a default profile, not yours. Test: compare the profile the start call returns — resolution, frame rate, stream list — with what you asked for. Fix: attach the configuration to the start call, built from enumerated profiles.
2. The previous acquisition never stopped. Test: query the acquisition status before starting. Fix: stop, wait for the stop to complete, then start.
3. The exposure does not fit the frame period. An exposure longer than the frame period is clamped or silently lowers the frame rate. Test: read the exposure back after writing; a value that snapped to something else means the budget is exceeded. Fix: lower the frame rate or the exposure.
4. A reset left your code on a stale device handle. After hardware_reset() the device re-enumerates and the old handle is dead. Test: poll the device list until the camera reappears, allowing a few seconds. Fix: rebuild the pipeline and configuration from the fresh enumeration, then start. The same recovery applies after a power dip — depth camera no frames after power loss: the software reset fix.
5. The camera left the bus. Test: look for the camera in the operating system's USB or Ethernet device list. Fix: reseat the connector and swap the camera cable; a bus-level reset can reach a camera the SDK cannot even enumerate. When a camera repeatedly disappears over USB, depth camera not detected over USB walks the port, cable and power checks.

If frames arrive but are flagged incomplete, discard and requeue rather than process them: incomplete frames stay incomplete: discard, requeue, grab a new one.

Use the hardware reset only to recover

hardware_reset() is the software equivalent of the unplug: the device reboots, re-enumerates on the bus, and every option returns to its power-on default. Two rules keep it out of your way.

1. Call it only when the camera ignores a correct stop-and-start. As a routine settings tool it is expensive — seconds of re-enumeration per reset, and every option back to default.
2. Re-enumerate before reconnecting. Poll for the device, rebuild the pipeline from the fresh enumeration, then re-apply settings. Connecting through the pre-reset handle is the classic route to the "no frames received" timeout.

A reset issued at the USB port level from the shell reaches the camera even when the SDK cannot see it — the right tool when the device has vanished from enumeration entirely.

If the goal is only to clear settings back to defaults rather than recover a hung device, no reset is needed at all: reset camera settings programmatically before capture is the lighter path.

Prevention: make every start rebuild the settings

• One function builds the full configuration — streams, resolution, frame rate — and attaches it to the start call. No other start exists in the program.
• After every start, write the complete option set from code, then read back the values that matter and log them. A default profile or a clamped exposure then shows up in a log line, not in scrap.
• Keep all option writes on one thread, between grabs.
• On a Linux host, disable USB autosuspend for the camera; the last FAQ below gives the mechanism.
• Fit screw-locked or latched connectors, so a bumped cable cannot mimic a replug.

The habit to build is simple: the camera is either running with the settings you just wrote, or it is starting through that one configuration path. Anything in between is a bug.

If you are specifying the station rather than repairing one, the camera finder lists GigE, USB3, 10GigE and CoaXPress models, and the configurator walks camera, lens and light in one pass.