Save camera parameters as a user set that loads on startup

You spend an afternoon dialling in exposure, gain, trigger timing and a tightly cropped ROI. Then the camera moves to a new bench, the PC reboots, and every value is back where the factory put it. On any GigE Vision or USB3 Vision camera the fix is already built in: user sets — snapshots of your feature values, held in the camera's own flash memory, with one of them designated to load at power-up. This guide shows you how to save a set, make it the startup default, verify it survives a real power cycle, and decide when a settings file on the PC should stay the master copy. The same mechanism runs on area scan, board-level and smart cameras that speak GenICam.

What a user set is, and what it is not

A user set is a named snapshot of the camera's feature values — exposure, gain, trigger configuration, ROI, pixel format, white balance — written into non-volatile memory on the camera itself. GigE Vision and USB3 Vision cameras that follow the GenICam standard all expose the same mechanism: a selector that names the set, a save command that copies your current values into it, and a load command that copies them back into the working registers. One set, called Default, holds the factory values; it is read-only on most models, and the writable sets are named UserSet1 upward.

Loading a set overwrites whatever currently sits in the working registers. That one behaviour causes most of the trouble people have with user sets, so the order of operations matters: load first, fine-tune second, save only when the tuning is proven.

Two boundaries. A user set is not a calibration store — lens distortion, pixel scale and hand–eye numbers belong in files on the PC, as the article on saving camera calibration parameters for reliable reuse explains. It also does not hold your application's own state: buffer counts, stream handling and the rest of the SDK configuration stay host-side no matter what you save.

What you need

Three things, and no code for the first method.

• A GigE Vision or USB3 Vision camera. The user set features are part of the GenICam feature tree those interfaces expose, so any area scan camera or board-level camera with one of these interfaces qualifies. The cards below span both interfaces and several form factors.

• The browser tool that ships with your camera's SDK. Any GenICam browser can open the device and show the feature tree, so you are not tied to one vendor's viewer.
• Your target values written down, in the units your camera uses. Exposure and gain are reported in different units on different models — microseconds on one, a raw register fraction on another. The guide to camera exposure and gain units shows how to read what the tree reports before you commit anything to flash.

If you run a smart camera instead, its inspection job already persists on the device; some models also expose the same user set features over GenICam when you drive the sensor from an SDK.

Save a user set in a GenICam browser, no code

1. Open the device with acquisition stopped. Values change most easily while the camera is idle, and a stopped stream cannot lose frames mid-configuration.
2. Set every feature you want to keep. The usual list: exposure time, gain, trigger mode and trigger source, width, height, OffsetX and OffsetY, pixel format, plus the black-level or white-balance controls your application depends on.
3. Find the user set controls. Most feature trees group them in a User Set Control section with four features: UserSetSelector, UserSetSave, UserSetLoad and UserSetDefault.
4. Pick a writable set. Select UserSet1, and leave another set free as scratch space for experiments.
5. Execute UserSetSave. The camera copies your current values into flash and briefly reports busy; let the command finish before touching anything else.
6. Smoke-test in the same session. Change exposure to something obviously different, then execute UserSetLoad with the selector still on UserSet1. The value should snap back.
7. Point the startup default at this set — the next section covers that — then repower and confirm.

Make it the set that loads at startup

The default set is applied when the device resets: at power-up, and on an explicit device reset — not on a software close and reopen. Set UserSetDefault to UserSet1 in the tree, remove power for ten seconds, reopen, and your settings should already be in place before you change anything.

Belt and braces is the better design. Keep the default for the power-on case, and have your application execute UserSetLoad right after it opens the device. The explicit load costs a few milliseconds and covers three situations. A bench tool may apply its own configuration after connecting; a colleague may have repowered the camera with other numbers in the working registers; some SDK runtimes skip the default-set load on open. If exposure behaviour looks wrong at startup rather than merely different, the article on the auto-exposure upper limit that startup settings miss walks through that ordering problem.

Do the same thing from your code

The three calls and their order are what matters; every SDK wraps them in its own API, and most ship a ready-made user set example among their sample programs:

# Deploying a configuration (run once, from your setup tool):
UserSetSelector = UserSet1
UserSetSave()                # copies the current values into flash
UserSetDefault = UserSet1

# Every start-up (immediately after opening the device):
UserSetSelector = UserSet1
UserSetLoad()                # copies flash back into the registers

Two error cases come up again and again. Writing features while the camera is acquiring fails on many models, so stop the stream before saving. And if a feature name is not found on the device, the model may name or nest it differently; enumerate what the camera actually exposes before hard-coding names, as the article on discovering the exposure feature before acquisition shows.

Verify the set survives a power cycle

A software close-and-reopen is not a reset. Run this check:

1. Scramble one value in the tree — push exposure to its maximum, say.
2. Remove mains power for ten seconds, reapply it, reopen the device.
3. Read one value per functional group: exposure, trigger mode, ROI width. Three readings, under a minute.

Mind the units before you judge the result. You saved 4,500 µs and the tree reports 4,500,000 ns — the same number, since 4,500 µs × 1,000 ns/µs = 4,500,000 ns. Confirm the unit first, then conclude.

Budget check while you are there. Say the application runs 60 fps and the saved exposure is 4,500 µs:

If the loaded set also crops the ROI, the camera still has 12.2 ms per frame for readout and transfer, so it should hold full frame rate. Push exposure the other way — 15,000 µs at 60 fps leaves 1.7 ms — and expect dropped frames unless the model tolerates the squeeze. To see what the camera actually delivered per frame, use per-frame exposure and gain metadata rather than trusting the configuration alone.

What lives outside the user set

The general rule of the interface standard: features the tree exposes for acquisition and image formation go into the set; host-side settings and the camera's network identity do not. A handful of models mark individual features volatile, so if a value you expected comes back different after repower, treat that one as host-side and apply it in code after the load.

For the numbers that decide image quality — exposure, gain and the trade between them — the article on industrial camera image quality settings explains what to settle before you freeze a set into flash.

When a settings file is still the better master

A user set serves one camera running one stable recipe. Move the master copy to a file when any of these holds:

• A fleet, not a bench camera. A file keyed by serial number is diffable, reviewable and restorable; flash is none of those. Deploy by writing the file's numbers to the camera, then saving its user set so it still boots ready.
• The recipe changes per product. Load the user set as the base at changeover and apply the deltas in registers. Save to flash only when a recipe is proven — a snapshot per changeover buys nothing.
• You need a change history. A set is a snapshot with no log. When someone asks what changed between March and April, the file answers and the flash cannot.
• The camera will be replaced eventually. A failed camera takes its user set with it; the file rebuilds the configuration on the replacement in minutes.

Sample images are a separate archive again. If you keep frames for offline testing or enrollment, the article on saving camera frames to disk covers that store.

Common mistakes that revert a configuration

Each of these costs an afternoon, and all are avoidable:

• Saved to one set, default pointed at another. The selector, the save target and UserSetDefault must name the same set; re-run the power-cycle test after any change.
• Testing with a software reopen instead of a repower. Only a device reset applies the default. Pull mains power for ten seconds.
• Tuning after saving. The set is a snapshot; any value changed afterwards stays out of the set until you save again.
• Loading last instead of first. The load overwrites your working settings, so it goes immediately after opening the device, before any other configuration.
• Trusting the bench tool to have written nothing. Some viewers apply their own startup configuration after connecting; read the values right after open, before any tool script runs.
• Hard-coding a feature name you never enumerated. Models differ in naming and grouping; if a basic feature such as exposure is missing from the tree, work through the property-not-found troubleshooting article.

If you are standardizing this across a bench or a line, fix the set names once and reuse them on every camera. The camera configurator starts at the camera step, the camera finder filters by interface and shutter, and the systems topic page collects more on keeping a vision system's configuration healthy. For a second pair of eyes on the strategy for your fleet, reach us through the contact page; every order includes free expert support.