GigE camera on a different subnet: force the IP assignment

The camera answers discovery and the tool even lists it, yet every attempt to set its IP hangs the console and the device stays flagged inaccessible. The cause is almost always one line in the camera's transport layer: a persistent IP address left over from another cell, sitting in a different subnet than the adapter it now hangs on. You do not need to guess at it. Disable the discovery subnet filter, force a valid address onto the camera, and open the device only once camera and adapter share a subnet. This guide gives the subnet arithmetic, the exact transport-layer settings, a five-step procedure and the verification list that keeps the fault from coming back.

Why the tool lists the camera but cannot open it

GigE Vision discovery is a UDP broadcast on the local link. Every GigE camera that hears it replies with its MAC address, IP address and subnet mask. The tool that sent the broadcast then applies a guard of its own: it compares the camera's network address with the adapter's, and on a mismatch it hides the device, greys it out or lists it as inaccessible. The camera is healthy — it answered. What fails is the guard against a configuration the driver cannot stream to. The mechanism is the same across the GigE area scan cameras range: the interface, not the sensor, decides it.

The comparison is one AND operation per side, byte for byte:

Two other addresses produce the same symptom. A DHCP camera that finds no server times out into the 169.254.x.x link-local range, which has its own walk-through for opening a link-local camera by IP from Linux. And a camera that worked until the host's network hardware changed is the adapter-change case: the camera kept its address, the adapter changed its network. The procedure below fixes both the same way.

The hang has a mechanical cause too. An IP-assignment dialog opens a control channel to the camera before it writes the address; across a mismatch that open waits for a reply that never comes, the console blocks until a timeout, and some tools then drop the window entirely. Removing the mismatch from the discovery path clears the dialog as well.

Choose the subnet before you touch the camera

Decide the network first; it saves a second power cycle. On a dedicated vision link the common plan is a private /24: the adapter takes the first usable address, the camera any address above it, the gateway stays empty. With 192.168.10.x and mask 255.255.255.0, the adapter takes 192.168.10.1 and the camera 192.168.10.12, leaving 192.168.10.2 to 192.168.10.254 — 253 usable addresses — for more cameras or a switch. If the camera must keep a plant address because a machine controller already expects 192.168.1.x, move the adapter to that subnet instead. Whichever side moves, both ends must compute the same network address.

A robot controller's built-in camera port follows the same rule: the port owns its subnet and the camera must take an address inside it. This walk-through of a GigE Vision camera on a robot controller's camera port shows the complete set-up.

Keep one subnet per adapter. Two adapters of one host on the same network make the operating system route packets out of the wrong port, which is the two-adapters-on-one-subnet hang. Hosts built for that layout are vision controllers with a LAN port per cell: the MV-VC3301H-128G66 carries 5+ LAN ports, 4 built-in light channels, an Intel Core i3 processor and 8 GB of memory.

Force the IP on the camera in five steps

Work with administrator rights on the host and the camera powered with its link LED on. Everything below happens before any acquisition open.

1. Confirm the mismatch. Read the camera's IP and mask from the greyed device entry, and the adapter's from the operating system (ipconfig on Windows, ip addr on Linux). Run the AND test from above. If the two network addresses differ, continue; if they match, the cause is elsewhere — firewall or exclusive access, both under common mistakes below.

2. Enumerate at interface level with the filter relaxed. On the adapter's transport-layer interface, before any device search, set DisableSubnetMatch = 1 — the tool skips its subnet comparison — and AllowBroadcastDiscoveryResponse = 1, which lets the camera answer with a broadcast reply, the only kind it can send when it cannot address the adapter directly. Choose discovery flags that stop at interface level, ignore the camera's stored transport settings and include inaccessible devices. Vendor browsers and SDKs expose the same two switches as checkboxes such as "ignore subnet mismatch" and "show inaccessible devices"; the names above are the GenICam transport-layer ones those settings map to.

3. Write the address. Force IP is a one-shot broadcast aimed at the camera's MAC address — immediate, forgotten at power-off, right for bench adoption. The persistent IP settings — address, subnet mask, gateway — survive every boot and are right for an installed cell. With the adapter at 192.168.10.1/24, write 192.168.10.12, 255.255.255.0 and gateway 0.0.0.0.

4. Power-cycle the camera. The persistent address loads at boot on most cameras, so cycle power even when the write reported success.

5. Restore the filter and re-enumerate. Set DisableSubnetMatch back to 0 and search normally. The device must now list as accessible; open it and grab one frame before production software touches it. If the open fails while another tool holds the camera, that is exclusive control, not subnet.

On Linux hosts, discovery adds its own quirks of interface binding and broadcast routes; the Linux GigE discovery walkthrough covers them. For a concrete example of the camera side, the MV-CU020-90GC is a 2.5 MP GigE camera with a 1/1.7" sensor and a global shutter.

The same steps from your own code

When the fix belongs in your application rather than a browser tool, the sequence is identical. The listing below is illustrative pseudocode: only the two feature strings are fixed GenICam names, and you map discovery, feature write and register write to your SDK's equivalents.

# illustrative pseudocode — the two feature names are GenICam transport-layer names
nic_ip      = "192.168.10.1"    # adapter address, static (string)
camera_ip   = "192.168.10.12"   # address to write (string)
camera_mask = "255.255.255.0"   # mask to write (string)

interfaces = discover(up_to = INTERFACE_LEVEL)               # list of interface handles
iface = interfaces[0]
iface.set_feature("DisableSubnetMatch", "1")
iface.set_feature("AllowBroadcastDiscoveryResponse", "1")
devices = discover(on = iface, include_inaccessible = True)  # now lists the off-subnet camera
devices[0].write_persistent_ip(ip = camera_ip, mask = camera_mask, gateway = "0.0.0.0")

The test that proves the result: set DisableSubnetMatch back to 0, enumerate again, and require the device to report accessible before you open it. Opening while the mismatch stands is exactly what hung the console.

Verify the fix and size the link

• Enumerate with the subnet filter restored: the device lists as accessible. A camera that only answers ping has not passed — ping is routed unicast, discovery is a subnet broadcast your tool filters.
• Open the device and grab one frame at a low frame rate.
• Set the packet size before production rates; the packet-size-first guide shows the order.
• Check bandwidth. A GigE link carries about 118 MB/s of image data once protocol overhead is paid. A 5 MP mono 8-bit camera produces 2448 × 2048 = 5.0 MB per frame, so 30 fps needs 150 MB/s and overruns the link, while 20 fps needs 100 MB/s and fits with roughly 15% headroom. Beyond that, 5GBASE-T hardware is the next step, and the high-performance NIC driver shows what a driver change gains on a saturated link.

Common mistakes that look like this fault

• Routing around the mismatch. A static route or a second adapter on the plant network makes ping and a browser session work, but enumeration and streaming are built for one subnet, and cross-subnet GigE Vision is generally not recommended. The symptom returns under load.
• Fixing the gateway instead of the mask. The mask defines the network; the gateway never corrects it. Keep camera and adapter masks identical and the gateway empty on a dedicated link.
• Skipping the power cycle. A persistent-IP write sits idle until the camera reboots; the address loads at boot.
• A host firewall dropping broadcasts. The enumeration list comes back empty even on a matching subnet — the ping-works-discovery-fails pattern.

Force once, then keep it static

In a fixed cell, force once: write the persistent address, leave the adapter static, and record both addresses on the cell drawing. On a bench that sees cameras from many cells, leave DHCP or link-local in place and adopt each camera per session; forcing addresses there creates tomorrow's mismatch. If two hosts must reach one camera, put them on a switch inside the camera's subnet rather than routing.

To size the camera and host together, start at the camera configurator or the camera finder; more network-side fixes live on the systems topic page. Every order includes free expert support, so the subnet plan can be checked with an engineer before you order.