A camera may appear in discovery yet reject a new IP address immediately after you change the host network adapter. That does not automatically mean the camera, cable, or software installation is faulty. The configuration utility may still be using interface information collected before the change.
For commissioning and maintenance teams, the fastest useful test is to finish the host configuration, close and reopen the utility, and select the camera's physical adapter again. Then separate temporary connectivity from settings that must survive a camera restart.
Start with the configuration sequence
Suspect stale interface information when assignment worked previously, the host address changed while the utility remained open, and the next assignment attempt reports a subnet mismatch. This sequence supports a hypothesis; it does not prove that every utility caches adapter addresses.
Use the symptom to choose the next test:
| Observation | First check | What the result tells you |
|---|---|---|
| Utility shows the host's previous address | Close and reopen the utility | A refreshed address supports the stale-interface explanation |
| Several adapters appear | Match the selected interface to the connected port | Automatic selection may have chosen another interface |
| Camera is discovered but cannot be opened | Compare host and camera subnet settings | Discovery alone does not establish usable image connectivity |
| Assignment works until camera power is removed | Read the documented startup address configuration | The change may have affected only the current address |
| Addressing works but acquisition fails | Troubleshoot discovery, control, and streaming separately | The remaining fault may not involve IP assignment |
For failures without a clear connection to an adapter change, start with vision camera network connection troubleshooting. The sequence below targets the narrower case where host configuration changed during commissioning.
Record the current state before changing anything
Place the inspection station and downstream actions in their documented maintenance state. Coordinate address changes with whoever manages the network, especially when the adapter also carries other machine traffic.
Record these details before another assignment attempt:
- The physical adapter name and hardware address.
- Its current IPv4 address, subnet mask, and gateway setting.
- The camera's hardware address, current address, and subnet mask.
- The interface and host address displayed by the configuration utility.
- The requested camera address and the complete error message.
- Whether the utility was opened before or after the host address changed.
Use the camera's hardware address to distinguish it from other discovered devices. An IP address is less reliable as an identifier while you are actively changing it.
Do not immediately reinstall software, reset the camera, or change several adapters. Those actions erase useful comparisons and introduce additional variables. First establish whether the operating system and utility agree about the connected interface.
Refresh the utility after completing host changes
Run this controlled sequence using the manufacturer's supported configuration utility:
- Close acquisition applications and configuration utilities. Stop image acquisition through the normal application controls. Check that another viewer is not still accessing the camera.
- Complete the host adapter configuration. Apply the intended address and mask through the operating system's supported network settings.
- Confirm the operating system's current values. Reopen the adapter properties or network status view rather than relying on a previously opened dialog.
- Launch a fresh instance of the configuration utility. Rescan and inspect its interface information, if that view is available.
- Select the connected adapter explicitly. Match its hardware address and current IPv4 address, not just a familiar interface label.
- Retry the documented address-assignment procedure. Record whether the assignment succeeds and whether the error changes.
A refresh button may rescan devices without rebuilding the utility's interface list. Closing and reopening the utility is therefore a useful diagnostic comparison, although refresh behavior depends on the software.
If a documented background service owns discovery or configuration, follow the vendor's restart procedure during the maintenance window. Do not terminate unrelated services or alter transport components experimentally.
If the fresh utility now displays the correct interface and assignment succeeds, retain the sequence as the corrective action. A reinstall is not needed merely to explain that result.
Verify the adapter and subnet with actual numbers
Automatic interface selection can be ambiguous when a host has several Ethernet ports, virtual adapters, or multiple configured addresses. Select the adapter physically connected to the camera and compare its actual settings with the proposed camera settings.
For an ordinary directly connected subnet, calculate each network address:
The following is an illustrative commissioning plan, not a setting for any particular product:
| Item | Example setting |
|---|---|
| Host address | 192.168.40.10 |
| Camera address | 192.168.40.20 |
| Subnet mask for both | 255.255.255.0 |
| Network address | 192.168.40.0 |
| Broadcast address | 192.168.40.255 |
With this mask, the first three octets identify the network. The host and camera therefore share the network address 192.168.40.0, while their device addresses remain different.
The mask leaves 8 host bits. The conventional usable-address calculation is 2^8 - 2 = 254, excluding the network and broadcast addresses. That is an address-space calculation, not permission to choose an arbitrary address on an existing network.
If the host instead has 192.168.41.10 with the same mask, its network is 192.168.41.0. Changing only the camera's final octet will not correct that mismatch.
Check address availability against the approved network plan. A failed ping does not prove an address is unused: another device may be powered off or configured not to answer. A gateway is not normally needed for direct communication within the same subnet; routed arrangements need a separate network design.
Separate temporary assignment from persistent settings
Treat these as two distinct commissioning outcomes:
- Current connectivity: the camera has an address that the host can use now.
- Startup configuration: the camera obtains the intended address after its next restart.
A utility may provide a temporary assignment mechanism to make a discovered camera reachable. That does not, by itself, establish what the camera will do after power returns. Some utilities offer a separate persistence prompt; others expose startup settings elsewhere. Follow the product documentation rather than assuming that one successful dialog performs both operations.
First establish current connectivity. Read back the camera's address and open it through the intended adapter. Only then configure the documented startup addressing mode and any required persistent address, mask, and gateway values.
Read those settings back before restarting. Distinguish a stored persistent address from an enabled startup mode that actually uses it. Where dynamic addressing is involved, coordinate reservations or address allocation with the network administrator.
Finally, perform a controlled camera power cycle and rediscover the device. Closing a viewer is not equivalent to restarting the camera and cannot prove persistence.
If a documented configuration feature is unavailable or inaccessible, use the checks in GenICam feature access troubleshooting. Do not assume that every camera exposes identical feature names or access conditions.
If refreshing the utility does not fix assignment
Work through the remaining causes without changing several variables together.
The utility still shows the wrong interface
Compare its selected adapter with the operating system again. Check for disconnected interfaces, similarly named ports, and overlapping subnets across multiple adapters. A utility restart cannot correct a genuinely wrong interface selection.
Discovery works, but control access fails
Some discovery mechanisms can report a camera before normal IP communication is established. A discovery entry therefore does not prove that its current address is usable from the selected host interface.
After confirming addresses, follow GigE Vision firewall troubleshooting. Use approved, scoped network rules rather than disabling protection across a production host.
The utility reports an ownership or access error
Close other viewers through their normal controls and inspect the documented access status. Do not try to override another application's control of a camera that may still be participating in production.
The failure is repeatable only with a particular installation
Record the utility, runtime, transport component, and operating-system architecture. If a version comparison is necessary, use vendor-supported packages obtained from the manufacturer or its authorized distributor. Keep host settings, cabling, and camera state unchanged between comparisons.
Do not copy individual driver files between installations or update firmware solely because an assignment dialog failed.
Keep hardware selection separate from this diagnosis
A software interface-refresh problem is not a reason to replace a working camera. If you are also specifying a new station, use the area scan cameras category and camera finder to narrow the interface and imaging requirements separately.
The LS-CMR-0053 is a GigE area scan camera. Its catalog interface makes it relevant to camera selection, but does not establish how a particular configuration utility handles adapter changes.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 12 MP
The MV-CU020-90GC is a GigE color area scan camera. Confirm the supported configuration workflow in its documentation rather than transferring menu instructions from another device.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
GigE, USB3, 10GigE and CoaXPress
1,287 models · from $149.00Choose replacement hardware only after identifying an unmet interface, imaging, or application requirement. Address assignment and persistent configuration remain commissioning checks for the selected device.
Verify recovery and capture useful escalation evidence
Before returning the station to service, complete this checklist:
- Interface agreement: the operating system and freshly opened utility show the intended adapter address.
- Device identity: the discovered camera hardware address matches the intended unit.
- Address agreement: current camera and host settings match the approved subnet plan without duplicating an address.
- Acquisition: the intended application opens the camera and receives fresh images.
- Persistence: a controlled camera power cycle produces the expected startup address.
- Application restart: the production application reconnects through the intended interface.
- Change record: the final addresses, addressing mode, and working startup sequence are documented.
If assignment still fails, provide support with the exact error, the before-and-after interface values, software versions, and the smallest repeatable sequence. State explicitly whether closing and reopening the utility changed its displayed interface address. Redact unrelated network details before sharing screenshots.
When assignment succeeds but streaming remains unreliable, move to machine vision network congestion troubleshooting rather than repeatedly changing IP settings.
For an unresolved commissioning fault, send the recorded evidence through technical support. For a new station, use the camera configurator after the network requirements are defined.
Questions
Why does camera IP assignment fail after changing the host address?
Some configuration utilities retain interface details collected when they start. If you change the host address afterward, assignment may use outdated information. Compare the utility's displayed interface address with the operating system, then reopen the utility and repeat the same assignment test.
Does discovering the camera prove its subnet is correct?
Not necessarily. Discovery and normal camera communication can use different mechanisms, so a listed device may still have an address outside the host's subnet. Confirm the selected adapter, address, and mask, then verify that the application can open the camera and acquire images.
Will an assigned camera IP address survive a power cycle?
Treat persistence as a separate verification task. Check the documented startup addressing mode and read back any stored address settings. Then restart the camera under controlled conditions and inspect the resulting address. A successful temporary assignment does not establish restart behavior.
Should I reinstall the runtime before testing the network settings?
Start with a controlled utility restart and explicit adapter selection. Reinstallation becomes a reasonable investigation only when the simpler checks fail and installation evidence supports it. Use supported manufacturer or authorized-distributor packages, and avoid mixing transport components from different releases.