You can change exposure, gain, trigger mode or any other camera feature while the line runs, without opening a configuration screen, because every GigE Vision camera exposes its features as registers you read and write over the network. Your control code needs three things: the feature's register address and width from the camera's GenICam XML, a register read/write function, and the big-endian encoding the standard puts on the wire. This walkthrough shows where each number comes from, the write order that keeps auto functions from undoing your value, and how to prove the number landed.
What do I need to write camera registers from control code?
You need a GigE Vision camera, one program that owns the camera's control channel and has a 32-bit register read/write function, and the camera's GenICam XML for addresses — the same trio behind any station built from area scan cameras, a controller and a cable.
- The camera. Any GigE Vision model works; the protocol is standard even though each model's addresses differ.
- The host. A vision controller or your PLC's vision library ships a register function block — on most it is named for a UDINT read or write. What GigE Vision guarantees for camera compatibility holds here too: the register mechanism is identical on every conforming camera.
- The link. Ordinary GigE; pick a drag-chain rated GigE cable when the camera moves with the machine.
A typical set: a GigE area scan camera, a controller with camera ports, and a high-flex cable.
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
Which command does a GigE Vision register write use?
GVCP — the GigE Vision Control Protocol, carried on UDP port 3956 — takes your write as command 0x0083 (WRITEREG) for 32-bit registers or 0x0081 (WRITEMEM) for byte blocks, and your library's register function block assembles that packet for you.
The four commands you will meet:
| GVCP command | Code | What it moves | Request payload |
|---|---|---|---|
| READREG | 0x0082 | One or more 32-bit registers | Address + register count |
| WRITEREG | 0x0083 | 32-bit registers | Address + value pairs |
| READMEM | 0x0080 | A byte block, such as the XML file | Address + byte count |
| WRITEMEM | 0x0081 | A byte block | Address + length + bytes |
One exposure write is a single WRITEREG pair. The acknowledge carries a status word; 0 means success. Check it — an unnoticed failed write costs an hour of tuning against the wrong value.
Where do I find a feature's register address and width?
In the camera's GenICam XML: bootstrap register 0x0900 holds the XML URL as a 512-byte string, and inside that file every named feature resolves to an IntReg entry that prints the Address, the Length in bytes and the access mode.
Exposure, for example, is an Integer feature named ExposureTimeRaw. Follow its value pointer and the IntReg underneath gives the address plus a Length of 4 — one 32-bit unsigned integer, a UDINT. A Length of 2 marks a 16-bit register, common for gain. When the URL reads local:name;size;crc32, the XML lives on the camera and READMEM (0x0080) fetches it; an http URL downloads directly. Addresses differ between models and firmware versions, so take them from your own camera's file, never from another model's.
How do I encode a 32-bit value for the wire?
Most significant byte first — big-endian, like every other field in a GVCP packet — so a UDINT of 2,000 travels as the four bytes 00 00 07 D0, and a 16-bit register takes only two of them. Background on byte order, if you want it.
The arithmetic for a 2,000 µs exposure, end to end:
Send one WRITEREG pair: the address your XML prints for the exposure register, then the value 0x000007D0. On cameras that follow the standard feature names, the raw exposure integer is microseconds; the feature's unit element in the XML states it.
In what order do I write exposure, gain and the auto functions?
Auto off first, value second, read-back third — any other order invites the camera's auto loop to overwrite your number within one frame, which looks exactly like a write that never arrived.
- Pause acquisition, or time the write into the gap between frames.
- Write ExposureAuto = 0. In the standard enumeration, 0 is Off, 1 is Once, 2 is Continuous.
- Write ExposureTimeRaw — 0x000007D0 for 2,000 µs.
- Write GainAuto = 0 first, then GainRaw, when gain changes in the same recipe.
- Read both registers back with READREG and compare against what you sent.
- Change trigger mode and source last. When a trigger goes quiet, checking the GenICam line settings finds the fault faster than re-writing registers.
- Resume the stream and watch the first frames' metadata.
Keep exposure under 90 percent of the frame period so the sensor always has time to read out:
At 30 fps the period is 1,000,000 / 30 = 33,333 µs, so hold exposure at or under 30,000 µs; the 2,000 µs from the example sits far inside. Push past the period and you get trigger overlap faults — the camera trigger overlap configuration checks catch that class of fault at startup.
How do I confirm the write reached the camera?
Read the register back, then check the image: the read-back value must equal what you sent, and mean gray level should scale with the exposure step — double the time and brightness roughly doubles until you approach saturation.
Frame metadata is the stronger proof. Enable chunk data and the camera stamps each image with the exposure and gain actually used: per-frame exposure and gain: verifying camera metadata shows the fields. When those numbers look odd, camera exposure and gain units: interpreting raw values explains the encodings you will see there.
When do cached addresses and saved values stop being valid?
Addresses hold for one model-and-firmware pair and change with either, and unsaved register values revert to the startup user set at every power cycle — so cache addresses per camera, and save the state you want to keep.
Three rules cover it:
- After a firmware update, re-pull the XML. The size and CRC32 values inside the local: URL change when the file changed, which is your cue.
- Save what must survive power cycles. Write the recipe's base values once, then UserSetSelector to UserSet1, UserSetSave, and set UserSet1 as the startup default. Your runtime code then writes only what changes between products.
- One controller at a time. A GigE Vision camera accepts a single control channel; the holder keeps it with a periodic READREG against register 0x0000. A configuration GUI left open holds the channel and your writes fail, so close it before the shift starts. Settings that silently revert at boot have the same smell: auto exposure upper limit not applied covers that check.
Leave stream packet-size and bandwidth registers at their commissioning values while the line runs. Resizing the stream live is a classic cause of dropped frames and GigE camera buffer overflow errors.
When is raw register access the wrong answer?
When your environment already speaks GenICam by name — use named feature access there, because it survives address changes between firmware versions and costs the same single GVCP round trip, which is why it is the default wherever you control the code.
Decide by environment:
- A vision library or Python stack with a GenICam feature tree — named writes: setting camera exposure time through a GenICam API in Python, and for gain, changing camera gain at runtime without stopping the pipeline.
- PLC code with a register function block and no feature tree — this article's path: cached addresses, width-checked values, auto functions off first.
- A code reader or smart camera with its own host protocol — send its parameter commands instead of GVCP; barcode reader PLC communication: plan a reliable link covers that link.
- One box to run the code, strobe the lights and hold the recipe — a controller such as the MV-VC3301H-128G66 keeps the register writes, the trigger and the lighting in one program.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
What should you check before the station ships?
- Address cache keyed on camera model and firmware version.
- ExposureAuto and GainAuto written to 0 before any per-product value.
- Every recipe load ends with a read-back compare.
- Base state saved to a user set flagged as the startup default.
- Configuration GUI closed on the production line; the control code holds the channel.
- Exposure ceiling checked at 90 percent of the frame period for the fastest recipe.
Next step: run the configurator to pair camera, controller and cable, or bring your camera's register map to our contact page and we will pull the addresses with you.
Questions
Can a configuration GUI and my control code share one camera?
Not the control channel. A GigE Vision camera accepts one controller, and that program keeps the channel with a periodic READREG of register 0x0000. The image stream is different: several programs can watch it, for example through a GigE Vision multicast receiver set-up, while a single program writes registers. Close the GUI before the shift, or make the viewer read-only.
Do register addresses change when the camera reboots?
No. Addresses are fixed per camera model and firmware version, so read the XML once, store the addresses against both strings, and reuse them across reboots. Re-read after a firmware update or a camera swap. The size and CRC32 values inside the camera's local XML URL change when the file itself changed, so they work as a change detector.
What unit does the exposure register take?
Microseconds as an integer on cameras that follow the standard feature names: write 2000 for 2,000 microseconds, and the feature's unit element in the XML confirms it before you commit code. Some sensors add a multiplier register that scales the raw integer; the XML ties it to the feature when it exists. Read back after the first write to catch any scaling surprise.
How much time does one register write add?
One UDP round trip on your LAN, typically 0.2 to 1 ms when the camera answers a switch directly. Named feature access pays the same round trip because it lands in the same WRITEREG packet, so raw registers buy you no speed. Choose them when your environment offers no feature tree, not to shave milliseconds.
Is it safe to write registers while the camera streams?
Feature registers, yes: the camera applies most of them at the next frame boundary, so exposure takes effect on the next triggered frame. Keep writes out of the window between trigger and exposure end, and keep them off links already running near bandwidth limits, where extra control packets can cost image frames. Bootstrap registers are the exception. Leave those alone in production.


