Browse and set any GenICam feature with a generic feature tree

Vendor viewers show a tidy tree of the features their interface designers chose to expose. The first time you need a node that tree hides — a test pattern, a register-level setting, a feature your script must set at run time — the hunt through tabs starts. It does not have to. Every GigE Vision and USB3 Vision camera publishes its own GenICam XML on connect, and that file is the feature tree. Load it, walk the category nodes, and one short piece of browser code enumerates, reads and writes any feature on any compliant camera. You leave with the node types to handle, the SFNC names that keep a browser portable, and a worked example that turns four tree values into a stream budget you can check on paper before the camera is mounted.

The tree is the camera's XML, not the viewer

A GenICam camera serves a device description file over its transport — GigE Vision or USB3 Vision. Your SDK parses that XML into a node map: every feature becomes a node with a name, an interface type, a value, a range, a unit, an access mode and a visibility level. Category nodes (the ICategory interface) hold other nodes as children, and the standard root categories are stable names: DeviceControl, ImageFormatControl, AcquisitionControl, UserSetControl and TransportLayerControl. What a viewer draws as a tree view is one rendering of that map.

Visibility splits into Beginner, Expert, Guru and Invisible. A viewer left at Beginner shows a short tree, which is why Expert nodes feel hidden — they are in the file, one toggle away. A generic browser reads the flag from each node and lets you set the filter yourself.

Hard-coded paths are the first thing to drop. A GenICam node not existing error usually means the code assumed a node the map never declared, and a browser that walks the real tree cannot make that mistake.

Node types your browser must handle

GenICam defines a small set of node interfaces. Read the interface first; the widget, the edit rules and the failure cases all follow from it.

Fill enumeration drop-downs from the node's own symbolic list, never from a table you wrote by hand — that shortcut is the whole story behind GenICam enumeration invalid value. When a value arrives as an integer from a recipe file, map it to the symbolic name before the write; the integer-to-symbolic mapping article shows the safe order. Commands run asynchronously, so keep the button disabled until the node reports the command done.

SFNC names make the browser portable

The Standard Feature Naming Convention (SFNC), part of the EMVA's GenICam standard, fixes the exact name and expected behaviour of common features: ExposureTime, Gain, Width, Height, PixelFormat, AcquisitionFrameRateEnable. Names travel; categories do not. Two cameras can group the same SFNC names under different branches, and vendors add private categories for their own extensions. Write the browser to search the whole tree by name rather than to walk a fixed path such as AcquisitionControl → ExposureTime, and the same tool reads a GigE camera like the MV-CS200-10GC (20 MP) and a USB3 model without edits.

Swapping a legacy SDK's private property names for SFNC ones follows the same logic; the legacy SDK migration guide walks that conversion step by step.

Walk the tree in four steps

1. Open the camera. The SDK fetches the XML and builds the node map. From here you work only with nodes, never with registers.
2. Recurse from the root category. For each child, record the display name, interface type, visibility and access mode — read-only, write-only, read-write, or a not-implemented flag.
3. Build the widget from the interface type, using the table above, and show only the visibility levels you have switched on.
4. Write with a read-back. Set the value or execute the command, read the node again, and compare. Command nodes finish asynchronously; the one-push autofocus notification article shows the event wait instead of a sleep.

The classic freeze is a browser that polls the node map from the same loop that services the stream. The camera feature browser freeze article is that mistake inside a vendor tool.

Worked example: stream budget for a 4000 × 3000 USB3 camera

LS-CMR-0166 is the example camera here: 4000 × 3000 at 30 fps over USB3.

Inputs, and where each comes from:

• From the tree, read Width = 4000, Height = 3000, PixelFormat = Mono8, AcquisitionFrameRate = 30 fps. The resolution, frame rate and interface match the catalog data for this camera.
• Mono8 packs 1 byte per pixel — the common mono case this example works.
• Link budget: USB 3.0 moves 5 Gbit/s raw; after 8b/10b encoding and protocol overhead, a host controller sustains about 400 MB/s of image payload. GigE moves 1 Gbit/s, about 100 MB/s usable.

Rule in words: payload per second is width × height × bytes per pixel × frame rate.

Arithmetic: 4000 × 3000 = 12,000,000 pixels, so one Mono8 frame is 12 MB. At 30 fps the stream is 12 MB × 30 = 360 MB/s. Against the ~400 MB/s practical USB3 ceiling, 360 ÷ 400 = 0.90 — the stream uses 90 % of the link and leaves about 10 % headroom. The Mono8 ceiling on that link is 400 ÷ 12 ≈ 33 fps. The GigE check fails outright: 360 MB/s against about 100 MB/s usable, a Mono8 ceiling of 100 ÷ 12 ≈ 8 fps.

Decision: keep this camera on USB3 at 30 fps Mono8 — 90 % link use is workable only while nothing else shares the port. Switch PixelFormat to Mono12 packed (1.5 bytes per pixel: 12,000,000 × 1.5 = 18 MB per frame) and the same 30 fps needs 18 MB × 30 = 540 MB/s, past the USB3 ceiling; the fix is 10GigE or CoaXPress, or a reduced ROI. On GigE, cap this resolution near 8 fps Mono8 or crop. Rerun the budget whenever PixelFormat, ROI or frame rate changes — the four tree values are the whole input.

Where a generic browser wins, and where the viewer stays

A generic browser wins in four places. It shows the Expert and Guru nodes a curated interface hides. It works unchanged across mixed fleets and interfaces. It doubles as a scriptable start-up check: enumerate the tree, compare a dozen SFNC values against golden numbers, alarm on drift. And it shows access modes as data, so a write that will fail is greyed out before you click.

It loses on live image display, drawing tools and the guards a vendor viewer puts around dangerous writes. Keep the viewer on the bench for tuning, and point your own code at the tree.

Four errors you will hit first

• A write comes back read-only. The access mode, a User Set or another application holding exclusive access is in the way. The attribute not writable and node not writable articles separate those three cases.
• Values lost after a reconnect. The camera booted its default User Set, not the one you configured. The write-protect after reconnection article walks the save-and-load pattern.
• An integer write rejected on an enumeration. Map to the symbolic name first, as in the node types section above.
• The tree view freezes mid-stream. The acquisition-thread mistake from the steps section — move enumeration off that thread.

The rest of the attribute-level failure modes are collected on the systems topic page.

Checks before you trust the tool

• Parse the XML once with explicit encoding handling; a decode error at connect is a loader guess, not a broken camera — the UTF-8 encoding fix article covers that step.
• Read Width, ExposureTime and PixelFormat, and compare each against the vendor viewer on the same camera. Same names and same numbers mean the enumeration is right.
• Round-trip one harmless write: set a value, read it back, restore the original.
• Log the visibility filter and the XML schema version with each session, so a behaviour change after a camera firmware update is traceable.

The decision: build it once, run it everywhere

If your week involves mixed fleets, hidden Expert nodes or automated start-up checks, write the generic browser — walking the map is roughly a day of work, and it keeps paying on the next camera model. If you tune a single camera on one bench, the vendor viewer is enough; do not build interface for its own sake. When viewer and code disagree, the XML decides.

Next step: pick hardware that serves a clean tree from the area scan cameras category and the camera finder, then run the browser on a controller with spare ports — MV-VC3301H-128G66 brings 5+ LAN ports and 3-4 USB 3 ports, and the vision controllers category holds the rest of the range. For a question about a specific camera's XML, the contact page reaches the applications team.