Save camera settings across power cycles with a user set

An industrial camera that forgets its configuration is a quiet kind of failure: exposure, gain, pixel format, region of interest and trigger all look right during set-up, then a power cut returns the camera to factory settings and the station grabs dark, oversized or untriggered images. The values live in volatile working memory until you write them into the camera's non-volatile user set storage and name that bank as the power-up default. This guide walks the four GenICam features involved, the save sequence from your own code, a worked readback example with the arithmetic, and the failure modes that send settings back to factory. It applies to any GenICam-compliant GigE Vision, USB3 Vision or CoaXPress camera.

The decision: one bank, one default

Settings survive a power cycle when two things are true: the current values were written into a user set bank with the save command, and the default selector names that bank so the camera loads it at every boot. Everything else, from live edits in a viewer to values your software pushes after connecting, sits in volatile memory and disappears when power is removed.

Some manufacturers call these banks memory channels; the GenICam standard calls them user sets, and every compliant camera exposes the same four features in the UserSetControl group:

• UserSetSelector — the enumeration picking the bank: Default, UserSet1, UserSet2 and further banks where fitted.
• UserSetLoad — the command copying a stored bank into working memory.
• UserSetSave — the command writing current working settings into the selected bank.
• UserSetDefault — the enumeration naming the bank loaded automatically at power-up.

The Default bank holds the factory configuration and is read-only on nearly every camera, so your work belongs in UserSet1. The sequence below applies to any GenICam-compliant camera in the area scan cameras range, for example this 6 MP GigE model:

Where the settings can live

Four places can hold a configuration, and only two of them survive a camera power cycle without help from a host:

The first two rows are the same mechanism: a viewer's save-to-camera button issues UserSetSave and sets UserSetDefault behind the dialog. If you configure from a viewer rather than from code, saving camera parameters as a user set that loads on startup walks that flow end to end.

The save sequence, step by step

1. Configure the camera live: exposure, gain, pixel format, region of interest and binning, trigger source and activation, acquisition mode, and white balance on a colour camera.
2. Stop acquisition. Most cameras refuse the save command while frames are being captured, and the refusal is easy to miss in a viewer that reports success without checking.
3. Set UserSetSelector to UserSet1.
4. Execute UserSetSave. The bank now holds a snapshot of every setting exactly as it stands.
5. Set UserSetDefault to UserSet1. The camera loads that bank at the next power-up.
6. Remove power from the camera completely, mains or Power over Ethernet, and reapply it.
7. Reconnect and read the critical values back. They must match the snapshot.

The same save from your own code

The feature access follows the pattern of setting camera exposure time through a GenICam API in Python; only the feature names change.

# Illustrative Python-style code. The feature names are GenICam standard
# names; the variable names and the connect call are yours.
exposure_us: int = 8000    # working exposure, microseconds
bank: str = "UserSet1"     # bank to write

cam = connect_first_camera()   # your API's discovery and open call

cam.AcquisitionStop()          # required before saving on most cameras
cam.UserSetSelector = bank     # pick the bank (string enumeration)
cam.UserSetSave()              # write current settings into the bank
cam.UserSetDefault = bank      # the camera loads this bank at power-up

The test that proves the save, run after a full power cycle and reconnect:

assert cam.UserSetDefault == "UserSet1"
assert abs(cam.ExposureTime - exposure_us) <= 1.0  # µs, one increment in this example

Reading ExposureTime back also catches quantisation: cameras store the value rounded to their exposure increment, so compare against one increment rather than the exact number you typed.

Worked example: an 8,000 µs exposure at 30 fps on a 12 MP USB3 camera

The camera for this example:

Inputs: an exposure time of 8,000 µs chosen for the station's lighting, the camera's rated 30 fps frame rate, and a full-resolution 4000 × 3000 image. The rule: the saved exposure must fit inside the frame period with room left for readout, or the frame rate drops the moment the bank boots.

The exposure occupies 24 % of every frame period, so readout keeps 76 % and the camera holds 30 fps straight from the bank. Saving follows the sequence in the previous section; the pass test is a cold boot with power removed, then a readback: ExposureTime must read 8,000 µs and UserSetDefault must read UserSet1. A readback showing the factory value instead means UserSetDefault was never changed, which is cause 2 below.

Why the settings came back anyway

Ordered by how often each one is the cause:

1. Nobody saved. Viewer edits sit in the camera's working memory; power-off discards them unless a save command wrote them to a bank.
2. The bank saved, the default did not. UserSetDefault still pointed at Default, so the camera boots factory values even though UserSet1 holds your work.
3. The save was refused mid-acquisition and the tool reported success anyway. Stop acquisition, repeat the save, and read the command result.
4. Host software overwrites the bank at connect, through an SDK auto-restore or your own initialisation code. Transport settings are the classic case, and keeping camera bitrate settings after a power cycle covers the identical trap on the link side.
5. Two programs share one camera and one overwrote UserSet1. Give each station its own bank and write the bank name on the station sheet.
6. You looked for network settings in the bank. A GigE Vision camera stores its persistent IP outside the user sets, through the interface control channel. Packet size belongs to the host session, so set it at start-up as setting the GigE packet size before acquisition shows.

Auto exposure can mask all six: the camera re-finds brightness whatever the bank says, so the fault only shows up as timing drift. Camera image brightness drifts over time explains why every auto mode belongs off before you judge a saved bank. The pattern is wider than cameras, too: drive parameter save failures after a power cycle follow the same diagnosis, values held in volatile memory with no write to non-volatile storage.

Smart cameras and vision controllers

On a smart cameras device the persistence unit is the inspection job: exposure, region of interest, tools and outputs all travel inside it, so saving the job to the device is that platform's equivalent of a user set. The MV-SC5060XM-08M-WBN, a 6 MP model with an 8 mm lens on an M12 mount, keeps its configuration the moment its job is saved to the device. A vision controllers station adds a second layer: your application boots with the controller and loads its own profile, while each attached camera still carries its bank so the cameras behave identically no matter which host connects.

Typical hardware on both layers:

The MV-VC3301H-128G66 pairs 8 GB of memory with 4 built-in light channels, so its boot profile covers lights as well as cameras. Keep the light values in the controller profile and the imaging values in the camera bank, and each layer restores itself.

Checks before you ship

• Read the UserSetSelector enumeration at runtime and note which banks your camera actually offers.
• Save with acquisition stopped, and read the command result rather than assuming it.
• Test with power removed, and only after taking the station out of production.
• Read the critical values back after the cold boot and compare them with the snapshot.
• Turn auto exposure and auto gain off before judging the readback.
• Write the bank name on the station sheet so the next programmer does not overwrite it.

Where to go next

Run the save and the cold-boot readback on your own camera first; it takes minutes and settles the question for every camera of that model. For a new station, start from the camera finder and carry the choice through lens, light and controller below. If a camera refuses the save or the readback never matches, bring the model number and the readback values to the contact page and we will work through them with you.