Depth camera auto exposure options error: set the master option first

Your depth camera streams fine, reads succeed, and then one option write fails: a call that sets an auto-exposure sub-option comes back wrapped in an input/output error instead of returning. The values you chose are not the problem. On stereo depth modules, the auto-exposure tuning options — edge-detection, mean-intensity and threshold-style controls — are accepted only while the master auto exposure switch for the imager pair is on, and the firmware answers a write to a disabled dependent with error 5 instead of a clear control not available. This guide decodes that error string, gives you the one-minute test, the write order that works, the checks that separate a dependency failure from a real cable fault, and the exposure arithmetic that decides when to drop auto exposure altogether.

The symptom: one option write fails while the camera works

You set an auto-exposure sub-option on a stereo depth camera — a left- or right-sensor edge switch point, a mean-intensity threshold — and the set call raises an exception instead of returning. The console text names the transfer that failed:

UVCIOC_CTRL_QUERY:UVC_SET_CUR error 5, Input/output error

Three facts sit next to that message. The camera keeps streaming. Other option writes on the same device succeed. The failing write fails with capture started and with it stopped, so the stream state is not the trigger. A failure that follows one option while every other control works rules out the cable, the port and the bandwidth. It points at a control the firmware refuses in its current mode — and there is exactly one mode switch above these options: the master auto exposure switch for the left/right imager pair.

What the error string actually says

UVC is the USB Video Class standard. The stereo depth modules that throw this error enumerate as UVC devices, and their exposure controls are driven with class-specific control requests. UVCIOC_CTRL_QUERY is the Linux driver call that carries such a request; UVC_SET_CUR is the request type that writes a control's current value. Error 5 is errno EIO, input/output error: the transfer reached the device and the device refused or failed that one control.

So the message blames the bus when the real problem is the mode. The firmware keeps a stored value for every option in its list but accepts writes only for controls that are active. With the master switch off, its dependents are inactive, and each write to them returns the generic input/output error rather than a specific not available now code.

Likely causes, ranked

Start from the top and stop when a test clears:

1. Master auto exposure switch off. The dependent options exist in the list but are inactive, and every write returns error 5 regardless of value. This is the cause whenever reads and all other writes work, so test it first.
2. Value outside the option's range or step. Some controls accept only quantized values. Read the option's minimum, maximum and step from your SDK and clamp before writing.
3. The tool writes dependents without checking the master. A GUI that exposes inactive controls invites the same refusal, and an unhandled write error can crash the tool. The crash belongs to the tool, not the camera.
4. Transport or power fault. Every control fails, reads fail too, and the device may drop off the bus. Least likely here, because your other writes succeed.

The fix: master switch first, dependents second

The fix is an ordering rule: enable the master auto exposure switch, then write its dependents.

1. List the camera's options from your SDK and mark the master auto exposure switch for the left/right imager pair plus its dependents — the edge-detection, mean-intensity and threshold-style controls.
2. Read the master switch. Reads succeed even while dependent writes fail, so this single call confirms the diagnosis.
3. For auto exposure: write the master switch to its on value (1), then write the dependent options with the values you want.
4. For manual exposure: delete the dependent writes altogether. With the master off they do nothing, and each one returns an error you would then have to suppress.
5. Read every option you wrote back and compare it with what you sent.
6. Apply the same order in startup code, configuration import and any GUI, not only in your interactive test.

An illustrative write order, with generic handle names — your SDK prints its own option list and ranges:

MASTER_SWITCH : integer control, 0 = off, 1 = on
EDGE_L, EDGE_R: dependent integer controls

set_option(MASTER_SWITCH, 1)          # master first; without this, both writes below fail
set_option(EDGE_L, 298)               # example in-range integer payload
set_option(EDGE_R, 65237)             # example in-range integer payload
assert read_option(MASTER_SWITCH) == 1
assert read_option(EDGE_L) == 298     # read-back proves the write stuck

The proof is a pair of runs. With the master still at 0, both dependent writes return the input/output error. With step 3 in place, the identical values 298 and 65237 write cleanly and read back unchanged. Nothing else changes between the runs — same camera, same cable, same session.

Keep auto exposure or drop it: the blur arithmetic

Auto exposure earns its place when illumination changes across the field of view or over a shift. On a moving line it also has a hard ceiling, because exposure time converts part motion into blur:

Worked example. Take a part moving at 300 mm/s, a pixel that covers 0.5 mm on the part, and an accepted blur of half a pixel, 0.25 mm. Then t_max = 0.25 mm ÷ 300 mm/s = 0.00083 s ≈ 0.83 ms. Any automatic exposure dwell above 0.83 ms smears edges by more than half a pixel. If your dimmest scene needs longer than that, roughly doubling the light in that zone halves the exposure the scene needs. If the light cannot go up, run manual exposure at 0.8 ms and raise gain within your noise budget, because gain adds brightness without blur. In either manual case, the auto-exposure sub-option writes stay out of the code.

The decision per case:

• Static part, controlled light: manual exposure, master switch off, no dependent writes anywhere.
• Moving belt, changing light: master switch on, with the automatic value capped at or below t_max — see capping maximum auto exposure time to stop motion blur.
• Dark corner at short range: add light first, gain second, and never chase exposure past the blur cap.

Prevention: one write order everywhere

• Startup: set the exposure mode and master switch before streaming starts. Auto settings that seem not to apply at startup are almost always an ordering problem — see fixing depth auto exposure not applied at startup and setting manual exposure before streaming.
• Configuration import: store the master switch above its dependents in the file, apply top-down, and skip dependent entries when the master is 0.
• Live tuning: write through the SDK in the same order rather than through a GUI that lists inactive controls, the way runtime camera parameter control does for exposure and white balance.
• Multi-camera rigs: apply the order per camera, not once per rig, as in per-camera auto exposure in a stereo depth rig.
• Stable images: automatic modes left running can drift brightness over a shift; switch off what you do not need, as covered in camera image brightness drifting over time.

When it is not the master switch

If the master reads 1, the values sit inside range and step, and the identical write still fails on a second host with a short cable, treat it as hardware and start the vendor support path. Close two software states first. Check for a control write-protect or lock flag left set after a reconnect — feature write-protect errors after reconnection walks that down. Confirm each value against the option's own minimum, maximum and step, because range faults deserve their own error, and the habit of checking valid values before you set is the same as for GenICam enumeration settings. If the module is long discontinued and its control stack is frozen, a rebuild on current hardware beats more driver work.

Rebuilding on current depth hardware

When a module's control stack is frozen and every fix is a workaround, rebuilding the station on current stereo depth hardware is the economical path. The 3D sensors category holds the laser profilers and stereo cameras, and the camera finder filters them by type and series. For the depth station itself, the MV-DLS300P-04 is a laser galvanometer stereo camera and the MV-DPS200P-02 is a projected structured-light 3D camera. The camera configurator pairs either with the rest of the cell, and the area scan cameras category covers the 2D stations around it.

More depth-camera diagnosis and set-up guides sit on the 3D vision topic page. If you are speccing the replacement station, send the part, the cycle time and the working distance through the contact page and we will help you size the depth camera and its lighting.