Your 3D camera refuses to flash, and the updater is blunt about the reason: a firmware update is not supported while the camera holds a dynamic, DHCP-assigned address. This guide is for integrators and line engineers hitting that gate on a network-connected depth camera, and for whoever inherits the XML-RPC timeout that sometimes follows the fix. In about ten minutes plus the flash itself, you will write a static IPv4 address, subnet mask and gateway into the camera, switch DHCP off, pick an address your DHCP server never offers, and aim the update tool at the right place.
Why the update refuses a DHCP address
The gate is flash safety, not bureaucracy. An update is not one transfer: the tool writes the image, the camera reboots into its updater mode, and the tool reconnects to the same address to finish the write. That sequence runs for minutes, and a DHCP lease can expire inside it. On renewal, the server is free to hand the camera a different address, and the tool then talks to an address where no camera lives. A half-written flash is the good outcome of that race; a camera that never boots again is the common one.
So the rule: before its first firmware update, every network-connected depth camera gets a static address, outside the DHCP pool, written into its persistent configuration. DHCP stays off from then on. Plants already run this discipline for PLCs and HMIs — the reasoning in static, BootP and DHCP address management for PLCs and HMIs applies unchanged to a camera on the same wire.
Write the static address before you update
Four values go into the camera's network block: the static IPv4 address, the subnet mask, the gateway, and the DHCP on/off flag. The vendor's tool writes them as one small configuration payload, sent to the camera at its current address, because the tool has to reach the camera to change it. In the tool's own naming, the keys are StaticIPv4Address, StaticIPv4Gateway, StaticIPv4SubNetMask and the flag UseDHCP, grouped under the camera's network section:
{"Net": {"StaticIPv4Address": "192.168.0.61",
"StaticIPv4Gateway": "192.168.0.201",
"StaticIPv4SubNetMask": "255.255.255.0",
"UseDHCP": "false"}
}
Send that to the tool's configuration command, let the camera reboot, and it comes back on 192.168.0.61 with DHCP off. If you do not know the camera's current address, read it from the DHCP server's lease table; on a network you did not commission, that is the fastest reliable route. On a Windows host, changing a GigE camera's address can trip an admin-rights error in the configurator tool, so run the tool elevated.
Worked example: a camera at 192.168.0.68 on a /24 subnet
Inputs, as commissioned in the case behind this guide:
- Current camera address: 192.168.0.68, assigned by the plant DHCP server.
- Subnet mask: 255.255.255.0, a /24 network and the plant default.
- Gateway: 192.168.0.201, the router address on this subnet.
- Update tool's assumed device address: 192.168.0.69, the factory address such tools fall back to when nothing else is set.
- Candidate static address: 192.168.0.61, chosen before anything was written.
- Pool check: read the pool range off the DHCP server and confirm it never offers 192.168.0.61.
The rule in words: a host address is usable only inside the subnet's host range, and it must not collide with the gateway, another device, or the pool the DHCP server hands out.
The arithmetic: a 255.255.255.0 mask leaves 8 host bits, so 2^8 = 256 addresses exist in the subnet. The network address (192.168.0.0) and the broadcast address (192.168.0.255) are not usable, which leaves 256 - 2 = 254 host addresses, 192.168.0.1 through 192.168.0.254:
Checking the candidate: 192.168.0.61 sits inside 192.168.0.1-192.168.0.254; it is not the gateway (192.168.0.201); it is not the tool's default (192.168.0.69), so a second camera still at factory defaults stays findable; and the DHCP server never offers it. All four checks pass.
Result: the block above reboots the camera onto 192.168.0.61 with DHCP off. Decision: any address in 192.168.0.1-192.168.0.254 that passes the four checks is valid, and 192.168.0.61 does. Set the tool's device address to 192.168.0.61 before the flash starts, because a tool left on its 192.168.0.69 default connects to nothing and times out.
Ping passes but the update times out
The classic sequel: after readdressing, every tool call fails with an XML-RPC timeout that asks whether you can ping the sensor, while ping works perfectly. In this case the camera sat at 192.168.178.36, five packets returned with 0% loss and round trips of 0.40-0.44 ms, and all ten tool tests still threw the timeout. Ping proves the wire; it says nothing about where the tool's session is aimed or which route it takes. The session is XML-RPC over HTTP, which is exactly why proxy variables and stale default addresses bite it. Work the causes in this order:
| Likely cause | Test | Fix |
|---|---|---|
| Tool still on the factory default address | Compare the device address the tool is configured for with the address you pinged; a tool left at 192.168.0.69 talks to nothing | Set the SDK's device-address variable to the camera's address, in the shell that runs the tool |
| Plant proxy intercepting the session | Print the shell's http_proxy setting; a set proxy routes the tool's HTTP session through a server that cannot see the camera subnet |
Add the camera's address to the standard no_proxy variable, in the same shell |
| Host and camera on different subnets | Compare the NIC's address and mask with the camera's; a host on 192.168.0.x reaches 192.168.178.36 only with a route | Add a second address on the camera's subnet to the host NIC, or add a static route |
| Tool never installed after a source build | Run it; "command not found" means the install step is missing | Rerun the project's install step with superuser rights, then open a fresh shell |
Here the first two rows fixed it together: device address and no_proxy both set to the camera's address, both exported in the shell that ran the tests, and all ten passed on the next run.
If your stack reaches the camera through a ROS node, the address arrives through the launch file's ip argument instead of a shell variable, but the proxy story is identical. The node inherits the environment of the window that launches it, so set both variables there before you start the node, not in another terminal.
Update rules that prevent a dead camera
Three habits keep a flash boring, which is what you want. Wired only: a dedicated switch port near the host, no Wi-Fi bridge, no VPN, no proxy in the path. One camera at a time, with each new address written into the plant IP register as you go. Stable power for the whole run: the write takes minutes, and an interruption at the wrong moment costs far more than the ten minutes this job takes.
When the tool reports completion, let the camera finish rebooting before you reconfigure anything. A version complaint from the SDK right after a successful flash is a different problem with its own fix, below.
When the network is not the problem
A clean static address clears the gate; it does not fix everything downstream of it. If the tool connects but the flash fails, or the camera will not boot after a completed update, move to the USB recovery route in depth camera firmware update by DFU: do it safely. For the process around the flash — approval, readback, sign-off — the camera firmware update workflow covers the whole sequence. If the SDK and the new firmware drift apart and you start seeing version mismatch errors, use the 3D camera header version mismatch fix. Once the camera streams again, tune the network for image throughput rather than control traffic, starting with packet size before starting acquisition.
The decision, and what to do next
Decide it in three lines. Camera on DHCP, update refused: write the static block with a pool-excluded address and DHCP off, then point the tool at the new address. Ping passes but the tool times out: fix the tool's device address and no_proxy first, the subnet second. Flash fails mid-write or the camera stays dark afterwards: recovery, not networking. Record every camera's address in the register, and the next update is a five-minute job.
If you are standardizing depth cameras on a line, these are the projected structured-light and ToF families we carry:
- Type
- Stereo / structured light
- Type
- Depth / ToF camera
Browse the full 3D sensors range, filter by type in the camera finder, or read the other 3D vision guides. If a flash still refuses after a clean static address, send the updater's exact message and your network block through the contact page and we will work the case with you.
Questions
Which address should I give the camera?
The first address in the camera's subnet that the DHCP server never offers. On the /24 network in this guide (mask 255.255.255.0) that means anything from 192.168.0.1 to 192.168.0.254 outside the server's pool; the worked case chose 192.168.0.61 with gateway 192.168.0.201. For several cameras, reserve a block below the pool start, say 192.168.0.2 through 192.168.0.99, and give each camera one address from it, recorded in the plant IP register.
Why does ping work when the update tool still times out?
Ping only proves that ICMP packets reach the camera. The timeout comes from the tool's configuration session, which is XML-RPC over HTTP: it goes to the address the tool has been given, along whatever route the shell's proxy variables allow. Point the tool's device address at the camera you actually pinged, and clear the proxy path with no_proxy, and the session connects.
Does the camera keep its static address after the update?
Yes. The network block is written to the camera's persistent configuration, so the address, mask, gateway and DHCP-off state survive the flash and every reboot after it. Write the address down before you start: after the update, the host and the tool must use the new static address, and the old DHCP lease entry is dead history.
Can I run a firmware update over Wi-Fi?
Avoid it. A flash is a timed write that needs every packet in order; a dropped Wi-Fi frame or a handoff between access points interrupts it, and power or link loss mid-write can leave the camera unable to boot. Use a wired port on a nearby switch, keep the camera on clean power for the whole run, and wait for the tool's completion message before touching anything.
How do I point the SDK or the ROS node at the new address?
The SDK reads the camera address from an environment variable, so export it, with no_proxy alongside it, in the same shell that runs the tool. A ROS camera node takes the address differently: it comes in through the launch file's ip argument and is passed down to the same driver underneath. Either way, set the variables in the window that starts the node, not in another terminal.