DHCP for a 3D camera: set the mode and run one server

A 3D camera that is switched to DHCP while no server is running disappears from discovery at the next power cycle: no lease, no IP address, no capture. The fix is an order of operations, not new hardware. Put the camera in DHCP mode first, start exactly one DHCP server on its subnet, and point your discovery configuration at hostnames instead of addresses. The steps below cover Windows and Ubuntu, size the address pool and the lease with the arithmetic shown, and end with the decision for each cell layout.

What changes when a 3D camera runs DHCP

A statically configured camera stores its address, mask and gateway internally, so it wakes at the same address every time. A DHCP camera instead broadcasts a request on its subnet at boot and waits for a server to offer a lease, in the standard discover–offer–request–acknowledge sequence. RFC 2131 also sets the renewal timer: the client renews at T1, half the lease time, so an 8-hour lease renews after 4 hours with no interruption to acquisition.

No server on the subnet means no lease, and no lease means the camera is not addressable. One server per broadcast domain is the rule: two servers with overlapping ranges both answer, and which offer wins decides the address you get.

The stable handle through all of this is the hostname. Addresses can change with every lease; the name does not.

What you need

• The camera and its current address, read with the SDK's camera list utility before anything is changed.
• A Windows or Ubuntu acquisition PC with a second network interface, or a dedicated camera switch, so the camera subnet is isolated from the office and plant networks.
• A DHCP server program: the dhcpsrv server on Windows, or the ISC Kea DHCPv4 server on Ubuntu.
• The camera's serial number, for the hostname plan.
• A short locking Ethernet cable for the bench configuration.

The steps are the same for every Ethernet 3D sensor in the 3D sensors range, whatever the depth technology:

Run the server on the PC that acquires from the camera — a bench PC or a unit from the vision controllers range — so the camera subnet stays on hardware you control.

Step 1: Put the camera in DHCP mode while you can still reach it

Do this on the bench with the camera on a direct cable, before it is racked. The camera must be reachable when you change the mode; afterwards it will expect a server at every boot.

1. Connect the camera directly to the PC and read its address with the camera list utility. That address is the handle the configuration tool needs.
2. List the cameras once more to confirm the tool sees the device before you change anything.
3. Set the mode. The viewer's menu path is Cameras → All Cameras → Configure: select the automatic (DHCP) mode and click Apply. The CLI does the same job one camera at a time; its set command takes the current address and a --dhcp flag, so for a camera at 172.28.60.5 the command reads:

set-config 172.28.60.5 --dhcp

4. Set a hostname in the same pass, using the tool's optional hostname argument. The default is normally derived from the serial number; a deliberate name such as cell3-profiler is easier to audit across a plant.
5. Repeat for each camera: the tool configures one camera at a time.

Step 2: Start exactly one DHCP server on the camera subnet

If a router already serves DHCP on the camera subnet, use it and start nothing of your own. Otherwise host the server yourself.

Windows: the dhcpsrv server

Unpack the server, set the address pool and the network interface in dhcpsrv.ini, then start dhcpsrv.exe. The tray icon shows whether it is running. Bind it only to the interface that faces the cameras.

Ubuntu: the ISC Kea DHCPv4 server

Find the interface name with ip link, back up /etc/kea/kea-dhcp4.conf, then replace it with a configuration that declares the camera subnet and the lease pool on that interface, and restart the service.

Keep the camera subnet off shared networks: a test server accidentally exposed to the plant LAN disrupts everything on it, not only the cameras. Wrong subnet and routing choices on the capture side also surface as latency symptoms — the depth camera latency fix walks that diagnosis.

Step 3: List hostnames, not addresses, in discovery

Many SDKs restrict which cameras a host will discover through a config file — for example a Cameras.yml. Whatever the file is called, the rule is the same once addresses are dynamic: list hostnames. An address list has to enumerate every address the server could hand out, or be re-edited each time a lease moves; a hostname list survives reassigned addresses untouched. Older SDK versions may need an extra name-service setting for hostname lookup; current versions resolve names with no added step.

If a downstream tool insists on a fixed address, use a reservation instead: pin the camera's MAC address to one IP in the server's pool. The camera stays in DHCP mode and the server always answers with the same address.

Worked example: size the pool and the lease

Assume an isolated camera interface addressed 172.28.60.1/24 serving three cameras, with statically addressed devices kept below .100. These are example inputs; the arithmetic is what transfers.

A /24 subnet holds 2^8 = 256 addresses; minus the network address 172.28.60.0 and the broadcast address 172.28.60.255, that leaves 254 usable. Pool 172.28.60.100–172.28.60.149: 149 - 100 + 1 = 50 lease addresses. Three cameras draw three, leaving 47 spare — roughly 16 times the requirement — so a swapped camera, a service laptop and a fourth sensor never exhaust the pool.

Set the lease to 8 hours: T1 = 8 / 2 = 4 hours, so a camera powered since the morning shift renews mid-afternoon with no visible interruption. A 1-hour lease (renewal at 30 minutes) suits a test bench where addresses should recycle fast; multi-day leases let a camera retired on Monday hold its address all week.

Decision for this cell: a 50-address pool, an 8-hour lease, and hostnames in the discovery file. That set-up cannot run out of addresses and cannot lose a camera to a moved lease.

How to verify it worked

1. Power-cycle the camera.
2. Run the camera list utility: the camera must appear within seconds of boot.
3. Open the server's lease table: the camera's MAC and hostname sit against an address from your pool.
4. Ping the hostname from the acquisition PC and get a reply.
5. Capture a frame in the viewer and confirm the timestamps advance.

Discovery over GigE is a subnet broadcast, which is why a ping proves less than the camera list utility; the GenICam discovery broadcast article explains what that broadcast can and cannot cross. If the camera still fails to appear, work through the GigE camera not detected checklist before touching the DHCP configuration again — most of those failures are subnet or driver basics that no lease can fix.

Common failures and fixes

• Camera set to DHCP before any server existed. It boots without a lease and drops off discovery. Direct-connect it, run the network tool against its last known address, and re-apply the mode once the server is confirmed running.
• Acquisition broke after a power cycle. The script held an address where it should hold a hostname. Swap the discovery list to hostnames or add a MAC reservation.
• Wrong addresses appearing on several devices. A second DHCP server is answering on the same link. Audit every interface, switch and VLAN until exactly one server remains per subnet.
• Two identical cameras trade addresses between boots. Tell them apart by hostname and list both names; the two identical cameras article covers the duplicate-name pitfalls in detail.

When DHCP is the wrong choice

A single camera on a dedicated interface with nothing else on the link is simpler as static: two addresses, no server, no lease to wait for at boot. Firmware updates are a second reason to keep static — the static address and firmware update article explains why DHCP blocks that path.

Choose DHCP with hostnames once any of these is true: more than one camera shares the subnet, cameras move between benches or PCs, or one PC serves several cells. Choose DHCP with a MAC reservation when plant policy mandates DHCP but a downstream tool insists on a fixed IP.

A typical static case is a single laser profiler on its own port:

Order of operations checklist

1. Bench the camera on a direct cable; read its address and serial with the camera list utility.
2. Set DHCP mode and a hostname in one pass; Apply, then re-list to confirm.
3. Start the one DHCP server on the camera subnet, with the pool and lease sized for the cell.
4. Point the discovery configuration at hostnames, not addresses.
5. Rack the camera, power-cycle, then confirm the lease, the hostname ping and a live capture.

To choose the camera itself, the camera finder filters 3D sensors by type and resolution, the cable and connector choices that keep the link up are in the machine-vision cables range, and more capture set-ups are collected on the 3D camera topic page.