You set a fixed IP on the camera, saved it, and closed the tool. Next morning, after the host PC rebooted during the night, discovery finds nothing — or finds the camera on the DHCP address you thought you had replaced. In most cases the setting never reached the camera's non-volatile memory, because the camera itself never lost power: a host restart and a dropped link are not power cycles. This page shows how to tell a failed write from a moved host adapter, how to commit the address so it survives every restart, and how to plan the cell so the problem cannot come back.
Why rebooting the host is not a camera power cycle
A GigE Vision camera holds its network configuration in two places. The working copy runs the camera right now. The saved copy sits in non-volatile memory and is loaded at every boot, before the camera tries DHCP or falls back to a link-local address.
When you enter a persistent IP in your SDK, the camera applies it to the working copy immediately, so the session keeps streaming and everything looks correct. On many cameras the commit to non-volatile memory only completes when the camera's power actually goes away — the power-down is the final step that makes the save real. Rebooting the host does not touch the camera's supply. The camera never reaches that step, and its next boot loads the old values.
The same commit rule explains other settings that behave badly across restarts: a camera keeps what was written before the power went, which is the story behind saving feature sets to a user set that survives power cycles.
The two power feeds that keep a camera alive
A camera is fully off only when every feed is broken. Most industrial rigs give it two:
- The Ethernet cable. With power over Ethernet, data and power share one cable. Unplugging it, or switching off the PoE port on the switch or injector, removes this feed completely.
- A GPIO or opto-isolated supply. A separate low-voltage DC feed wired to the I/O connector can also power the camera, independently of the network.
If the camera runs on PoE alone, pulling the Ethernet cable is a genuine power cycle. If a GPIO supply is fitted, the board stays alive through any Ethernet drop, and your restart never reaches the electronics. Disconnecting both the Ethernet feed and the GPIO supply is the reliable way to cold-start such a camera. For help choosing between power schemes on a new camera, see the camera power over Ethernet guide.
The four causes, tested in order
| Likelihood | Cause | Test | Fix |
|---|---|---|---|
| Most likely | The write never committed because the camera stayed powered | Redo the configuration, break both feeds for about ten seconds, re-read the announced address | Follow the commit sequence below |
| Common | The host adapter left the camera's subnet after the reboot | Run the subnet check in the worked example below | Give the adapter a static address on the camera's subnet |
| Possible | A dual feed kept the camera alive through your restart | Trace both power paths; watch the camera's status lights through the whole restart | Break every feed, not just the cable |
| Rare | A firmware defect reverts the saved address | Repeat the full procedure twice on a known-good network | Raise it with the manufacturer's support channel; install official firmware only |
Work the table top to bottom. The first two rows explain nearly every it-worked-yesterday report: either the camera never cold-started, or it cold-started fine and the host is the side that moved.
Worked example: camera saved at 192.168.1.10, host stuck at 169.254.42.7
The inputs, and where each comes from:
- Camera side: persistent IP 192.168.1.10 with mask 255.255.255.0. These are example values you would have configured; substitute your own plan.
- Host side: after a reboot with no DHCP server answering, the adapter self-assigns an address from the standard IPv4 link-local range 169.254.0.0/16. Take 169.254.42.7 with mask 255.255.0.0 as the example result.
- The rule: GigE Vision discovery uses subnet broadcasts, and routers do not forward broadcasts. The adapter finds the camera only when both sides sit in the same subnet: the camera's IP AND its mask must equal the adapter's IP AND its mask.
The arithmetic, written out:
- Camera: 192.168.1.10 AND 255.255.255.0 = 192.168.1.0
- Host: 169.254.42.7 AND 255.255.0.0 = 169.254.0.0
- 169.254.0.0 is not 192.168.1.0, so the adapter is outside the camera's subnet.
The result: this failure is on the host side. Even a perfectly saved address cannot be discovered from an adapter in the link-local range, so check the subnet before suspecting the camera's memory.
The decision, with its threshold: different network blocks mean you fix the host first. Set the adapter statically to 192.168.1.1 with mask 255.255.255.0 — any address from 192.168.1.1 to 192.168.1.254 works, except the camera's own and the 192.168.1.255 broadcast. Refresh discovery. If the camera answers at 192.168.1.10, the save survived and you are done. If it answers on a DHCP lease or a 169.254.x.x address, the save never landed, and the commit sequence below is the fix.
The commit sequence that makes the address stick
- Enter the settings. In your SDK's network or transport-layer section, set the persistent IP, subnet mask and gateway. On a camera-only subnet the gateway rarely matters; leave the default or reuse the adapter's address.
- Complete the write. Answer every confirmation the tool offers and wait for its completion message before closing anything. Some manufacturer utilities end with an explicit write confirmation; that step is where the change lands.
- Cold-start the camera. Unplug the Ethernet cable and disconnect the GPIO supply if fitted. Leave both off for about ten seconds; that margin lets supply capacitors discharge and gives PoE a clean renegotiation on reconnect.
- Read back the announced address. Reconnect, give the camera a few seconds to boot, and refresh your discovery tool. Note what it reports.
- Reproduce the original failure. Reboot the host once more and confirm the camera is still found at the saved address. That reboot is the acceptance test, because it is exactly what failed before.
If the camera is mounted where you cannot reach it by hand, check the SDK for a device reset function. Executing it restarts the camera's internals and usually commits pending settings without losing power. Prove that on a bench camera first; the physical power cycle remains the method that works on every GigE Vision camera.
When the address still will not stick
- A firmware defect. If the full sequence fails twice on a known-good network, stop re-entering settings and raise it with the camera maker's support channel. Firmware comes only from the manufacturer or its distributor.
- A duplicate saved IP. Two cameras configured with the same persistent address on one subnet fight over it, and both look unreliable. Give each camera its own last octet and keep the plan in writing.
- A DHCP dependency somewhere else. A swapped server or a changed scope can imitate a lost address on cameras still set to DHCP. The deterministic answer for a production cell is persistent IP plus a static adapter, which boots without any server.
- A 3D sensor with the same behavior. 3D cameras and laser profilers that connect over GigE carry the same settings, and the static IP address for a 3D camera firmware update guide shows why a server-dependent address also blocks firmware service.
- Recovery, not prevention. If you must reach a camera right now and all you know is its 169.254.x.x address, the GigE camera opened by IP on a link-local address from Linux guide gets you in.
Which cameras this applies to
The behavior described here belongs to GigE Vision: any camera with an Ethernet interface — area scan, line scan or 3D — carries the same addressing modes and the same commit rule. Area scan cameras with GigE interfaces are the most common case, and the models below are current examples; 3D sensors with a GigE connection behave the same way.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Sensor format
- 1"
- Lens mount
- C-mount
USB3 Vision cameras are the exception, and a welcome one: they have no network address to lose. The host enumerates them over the cable, so a restart cannot misplace an address. When a USB camera vanishes instead, the fault path runs through cables, hubs, host controllers and power delivery — the USB link checks after a cable swap guide and the USB versus external 5 V camera power comparison cover that ground.
Set the cell up so it never happens again
- Give the cameras their own subnet, or a dedicated adapter per camera group, and keep the adapter static. The worked example above is the pattern to standardize on.
- Prefer persistent IP over DHCP in production. The camera then boots to a known address with no server in the path, and a server swap cannot move it.
- Finish every network change with a cold start, and every commissioning with the host-reboot acceptance test. Other restart-sensitive settings behave the same way; the camera bitrate settings after a power cycle guide is the same story for stream settings.
- Keep the written map. One page listing camera, MAC, saved IP and adapter address answers every which-one-is-which question for the life of the cell.
If you are planning the addressing scheme for a new line, the camera finder filters by interface and resolution, and the configurator walks camera, lens and light in one pass; the cameras topic page collects the related guides. For a rig that keeps losing addresses after all of the above, describe its power topology through the contact page and we will help you trace it.
Questions
Does unplugging the Ethernet cable power cycle a PoE camera?
Yes, when PoE is the camera's only supply: the cable carries both data and power, so pulling it removes power completely. The exception is a camera that also has a GPIO or opto-isolated supply. That second feed keeps the board alive through the Ethernet drop, so no write is committed and the camera boots its old settings. Trace every power path before you trust a cable pull.
How long should power stay off before reconnecting?
About ten seconds is a comfortable working margin with every feed disconnected. The requirement is not a published hold-off time but that the camera's supply actually reaches zero; ten seconds lets supply capacitors discharge and gives the PoE negotiation a clean start on reconnect. It costs nothing in a maintenance window, so there is no reason to cut it shorter.
Why does the camera come back on a 169.254.x.x address?
That is a link-local address. When no DHCP server answers and no persistent IP was saved, a GigE Vision camera falls back to link-local addressing, and the host network adapter does the same. Seeing it after a cold start usually means the write never reached non-volatile memory. Redo the configuration, finish with a full power cycle, and check the announced address again.
Can I commit network settings without unplugging anything?
Often yes. Many SDKs expose a device reset function next to the network features; executing it restarts the camera's internal firmware and commits pending settings, which replaces the physical power cycle on cameras you cannot easily reach. Prove it works on a bench camera first. If the address still reverts after a reset, fall back to the physical power cycle.
Do USB3 Vision cameras have this problem?
No. A USB camera has no network address to lose: the host enumerates it over the cable, and its identity does not depend on stored network settings. If a USB camera disappears after a host restart or a cable swap, look at cables, hubs, host controllers and power delivery instead — that is a different fault path with different tests.
Which address should the host NIC use on a camera subnet?
Any fixed address inside the camera's subnet that is not the camera's own and not the broadcast address. With cameras planned at 192.168.1.10 onward and a 255.255.255.0 mask, put the adapter at 192.168.1.1 and keep a written list so cameras and adapters never collide. A static adapter removes the DHCP dependence that causes link-local fallback in the first place.