Change a camera IP address and update tools stuck on the default

Changing a camera's address should be a five-minute job: write the new IP, re-plug, grab an image. Instead, the ping answers and the SDK tool still times out — often with a message that asks whether you can ping the sensor. You can. You pinged the new address, while the tool called the old factory default. The camera side of an address change is half the job; every client that stores a target address is the other half. The steps below cover both halves: pick a safe address, write it to the camera, re-point each tool, and prove the result with one real frame instead of one ICMP reply.

Why ping succeeds and the tool still fails

A camera holds one address, and every client holds its own idea of that address. Vendor tools ship knowing a factory default — 192.168.0.69 is a common one — and use it whenever you give no override. Change the camera to 192.168.0.5 and three things are true at once: the camera answers at the new address, the tool still calls the old one, and the timeout message blames your ping.

Ping proves exactly one thing: the host and the device share a link and the device's IP stack answers echo requests. It says nothing about the session the tool needs — the control channel, its ports, the stream. Device discovery is a separate UDP broadcast, and discovering the camera at its new address does not rewrite the address written in a project file. That is why the fix is always two-sided: one new address on the camera, and the same new address in every client that talks to it.

What you need

• The vendor's address tool. For a GigE Vision camera that is the configuration utility shipped with it, which writes a static or forced address into the device; many 3D cameras expose a web page or an SDK command for the same job.
• The cell's network plan: host address, netmask, gateway, and the DHCP pool range you must stay out of.
• A free address, decided before you start. Silence on ping is the acceptance test that it is free.
• The production client itself — the tool that must grab frames at the end, not a demo viewer.
• One power cycle: you will reboot the camera to prove the address persisted.

Worked example: moving a camera from 192.168.0.69 to 192.168.0.5

The bench case, with real inputs:

• Camera factory default: 192.168.0.69 — the address the SDK tool assumes when nothing overrides it.
• New camera address: 192.168.0.5 — written to the camera with the vendor tool.
• Host adapter: 192.168.0.10 with netmask 255.255.255.0 — a typical bench PC on the same link.
• Tool target: 192.168.0.69 — unchanged, because no flag, environment variable or config value was ever set.

The rule: a client connects to the address it is configured with, not the address the camera now has. Two devices exchange traffic directly when their network addresses match, and the network address is the IP ANDed with the netmask:

Per octet: 192 AND 255 = 192, 168 AND 255 = 168, 0 AND 255 = 0, and the last octet ANDs with 0, so both 5 and 10 vanish into the network address. Both sides sit on 192.168.0.0/24: the physical network is correct, and ping 192.168.0.5 confirms it. The failure sits on the client side:

The tool opens its control session to a silent address, waits, and reports a timeout that suggests pinging the sensor — the sensor you already pinged, at a different address.

Decision: the network needed nothing further; the client configuration had everything still to do. Set 192.168.0.5 at every layer the tool reads — the one-off flag, the environment variable for shells and services, the project or config file for the application. The stopping threshold: once target and camera address match and ping answers, re-addressing is cleared as the suspect; if frames still fail, the cause is firewall or transport, not the address.

Change the address end to end

1. Book a safe address. Stay in the host's subnet, outside the DHCP pool; skip the gateway, the network address (192.168.1.0) and the broadcast (192.168.1.255 on a /24). Test that it is free: ping 192.168.1.50 must stay silent. An address that answers belongs to something already, and a duplicate makes the link drop in and out as ARP flip-flops between two devices.

2. Write the address to the camera as a static setting. Run the vendor's configuration tool, choose the static or forced-address mode — not a temporary profile — enter address and netmask, and apply. Power-cycle the camera and ping again: a setting that does not survive a reboot was never saved. Persistence matters beyond convenience, because a firmware update on some 3D cameras refuses to start while the camera sits on DHCP (Static IP address for a 3D camera firmware update: why DHCP blocks it).

Any GigE area scan camera takes this same path — the MV-CU020-90GC, a 2.5 MP color GigE model, is a typical example.

3. Re-point every client. Check all four places a target address hides:
   • the command line, where a flag such as --ip=192.168.1.50 overrides everything for that one run;
   • the environment, where many SDK tools read an override variable at startup — set it in the shell profile or the service definition, not just the open terminal;
   • the project and config files: search the whole project for the old address as a plain string; one hardcoded 192.168.0.69 in a launch file defeats everything else;
   • the runtime screen, where vision software with a camera-address field stores it per station.

3D and ToF cameras follow the same two-sided rule. A ToF sensing camera such as the MV-DT01WMU receives its address from the vendor's tool, and its SDK then needs the matching target like any other client.

4. Restart the clients. A tool reads its target once, at startup. A long-running service keeps calling the old address until you restart it — the classic reason a fix works in the terminal and fails in production.

5. Prove a frame, not a ping. Ping the new address, then grab one image in the production tool and confirm it contains scene content. If ping answers and pixels never arrive, work through Timeout waiting for image buffer: ping works, no pixel data; if the tool finds zero cameras, suspect the host-side transport (Ping works, zero cameras: GigE transport layer not loaded). 3D cameras add one quirk: the first capture after a parameter change can still carry the old state, so capture twice before you judge (Why a 3D camera needs two captures after a parameter change).

6. Record the address. Put it in the cell's network drawing and the vision project notes, and label the camera. Nothing on the housing prints it, and the next firmware update or camera swap will need it.

Verify it worked

• The new address answers ping; the old default no longer does. If both answer, another device holds the old address, or the camera never applied its change.
• The production tool connects with no command-line override — proof that the persistent setting took, not just the terminal session.
• One saved frame shows the scene, not zeros.
• Power-cycle camera and host, then grab again. A setting that survives one reboot but not two was never written to the device.
• A tool that connects from one PC and times out from another points at the workstation firewall, not the camera (GigE Vision camera firewall: ping works, discovery fails).
• If the host adapter changed networks as well — a laptop moving between office and cell — the host side has its own stale addresses; Camera IP assignment fails after a network adapter change covers that case.

Common mistakes

• Re-addressing only the camera. This is the worked example's failure; the client default survives until you edit it.
• Assigning a live address. Ping first; silence is the requirement.
• Mask mismatch. A camera set to 255.0.0.0 while the host uses 255.255.255.0 fails the AND test, and traffic tries to route through a gateway with no route back. Keep both sides on the same mask unless the cell design says otherwise.
• DHCP in production. The lease can move the address between shifts; use static, or a reservation, always.
• Editing the config without restarting the service that reads it.
• Changing the address mid-shift while the robot program calls the camera by that address. Stop the program, change both sides, restart.

Static or DHCP: the decision

Use a static address, or DHCP with a reservation, whenever any client stores the camera's address — which is nearly every production cell. Plain DHCP belongs on a development bench, where the discovery tool, not a stored target, finds the camera each run. A /24 subnet offers 254 usable addresses, from .1 to .254; keep the low numbers for infrastructure — controller, gateway, switch — and reserve a camera block such as .50 to .99, so the next camera's address is predictable before the box is open. Resolution plays no part in this choice: a 12 MP GigE model such as the LS-CMR-0053 is addressed exactly like any other camera, and bandwidth planning is the separate job.

From network plan to working cell

With addressing settled, the rest is catalog work: the area scan cameras category for GigE, USB3 and 10GigE models, 3D sensors for laser profilers, stereo and ToF devices, and the camera finder to filter by interface, resolution and shutter. The configurator below builds the chain — camera, lens, light, controller — and keeps the parts that must share one network in one place. More network-side fixes, from discovery failures to buffer timeouts, live on the systems topic page. If a frame still will not cross after both sides of the change are done, send the timeout text and your network plan through the contact page and we will work the path with you.