Connect a GigE camera on a different subnet: set remote and local IPs

A camera that answers ping but never appears in the camera list almost always sits on a different subnet, and re-plugging cables will not fix it. The fix is four concrete values: a persistent IP such as 10.10.4.50 with mask 255.255.255.0 and default gateway 10.10.4.1 on the camera, plus a host NIC at 10.10.9.20/24 that the router carries toward the camera's segment. GigE Vision discovery is a subnet broadcast on UDP port 3956, and a router does not forward broadcasts — but unicast discovery to the camera's remote IP crosses it, and routed IP carries the image stream both ways once the firewall allows it. This guide walks that sequence for a routed plant network — the subnet arithmetic, the firewall rules, the packet-size trade-off and the verification order — so you can commission the station once and leave it running.

Can a GigE camera work on a different subnet?

Yes — control, discovery and streaming all work across a router once you set addresses explicitly: broadcast discovery dies at the router, but unicast discovery on UDP port 3956 reaches the camera, and routed IP carries the replies and the image stream in both directions.

Two conditions decide it. The path between the subnets must be routed IP — a router or layer-3 switch forwarding the two segments — with no address translation in between. And both ends must know each other's addresses: unicast discovery targets the camera's IP, and the camera returns everything through its gateway.

GigE Vision splits the traffic in two. Control and discovery ride UDP port 3956 in both directions. Image data rides UDP from the camera's stream port to a host port that the acquisition library announces when it opens the stream. Both are plain routed UDP, so nothing in the protocol requires the two subnets to match. Any GigE area scan camera speaks this protocol, so the method below applies across resolutions and interfaces.

Why does discovery not list a camera that pings fine?

Discovery is a UDP broadcast to port 3956, and a broadcast stops at the first router, so a camera one subnet away never hears the question — a successful ping proves that routing exists, not that discovery can see the device.

The discovery packet asks every device on the segment to answer, and routers deliberately contain it; forwarding it would merge every device on one VLAN into every other. A camera two hops away never hears the question, so it never answers — even though ping, which is routed unicast, works perfectly.

Most acquisition libraries include the fix: a unicast discovery mode that sends the same question to one explicit address instead of the broadcast address. The reply returns as ordinary unicast UDP, follows the routes, and the camera appears in the list. Where the SDK has no unicast mode, use the connection methods that work without broadcast discovery or a temporary same-subnet hop during commissioning.

The deeper mechanics of that silence are in GenICam discovery uses subnet broadcast: why ping is not enough.

Which IP addresses go on the camera and which on the host?

Set four values, three on the camera and one on the host: camera persistent IP 10.10.4.50 with mask 255.255.255.0 and default gateway 10.10.4.1, plus a host NIC at 10.10.9.20/24 that the router carries toward the camera's segment.

The decision rule is one mask test on each side:

Worked through: the host masks the camera's 10.10.4.50 with 255.255.255.0, gets network 10.10.4.0 instead of its own 10.10.9.0, and sends the packet to its gateway 10.10.9.1, where the router delivers it. The camera runs the same test on 10.10.9.20, gets 10.10.9.0 against its own 10.10.4.0, and sends every reply and every image packet to its gateway 10.10.4.1. Both directions are explicit, which is all a routed link needs.

You never type the host address into the camera by hand. The camera learns where replies go from the gateway, and it learns the one address that matters for images — the stream destination — from the acquisition library, which announces it over the control channel when the stream opens. Check that the announced address is 10.10.9.20, the camera-facing NIC, not another NIC in the same host.

How do you set a persistent IP on the camera?

Connect the camera to a laptop or the host on one link, give it a temporary same-subnet address, then write its static network settings — IP, mask, gateway — through the SDK's transport-layer configuration so they survive every power cycle.

1. Wire the camera directly to a laptop or the host NIC. With no DHCP server answering, a GigE Vision camera comes up on a link-local 169.254.x.x address or its factory subnet, typically 192.168.1.x.
2. Put the NIC in the camera's current subnet — 192.168.1.20 with mask 255.255.255.0 covers the usual default — or run the tool's force-IP function to lend the camera a temporary address on yours. The dedicated walkthrough of forcing an IP assignment on a camera in another subnet covers that path.
3. In the camera's network settings, switch the address source from DHCP or link-local to static, then enter the production values: camera IP 10.10.4.50, subnet mask 255.255.255.0, default gateway 10.10.4.1.
4. Save and power-cycle the camera. Persistent values live in camera memory, so a reboot, a new switch port or a plant-wide power cut leaves them untouched.
5. Move the camera to its production port on the 10.10.4.0/24 segment, ping 10.10.4.50, then run unicast discovery from the host.

DHCP with a reservation is the workable alternative: the camera keeps asking, the server always answers with the same address, and discovery targets that address exactly as with a static one. The failure is operational — an edited scope or a deleted reservation silently breaks every client built around the old address — which is why production floors favor static.

How do you configure and bind the host NIC?

Give the camera-facing NIC a static address in a subnet the router carries toward the camera, strip the NIC's extra protocol bindings if your filter driver asks, and bind the acquisition library to that NIC so control and the announced stream destination both use it.

Concretely: 10.10.9.20 with mask 255.255.255.0 and gateway 10.10.9.1, nothing dynamic. Some packet-filter drivers want the NIC reduced to IPv4 plus their filter; unchecking the other bindings is part of each vendor's adapter guidance and takes a minute.

On a multi-NIC host the library must use the right one. Most libraries list the interfaces and let you pick; if it picks the wrong NIC, it announces that NIC's address as the stream destination, and you get the mixed symptom — controls answer, the frame counter stays at zero. Pin the interface in the library settings; picking the right NIC on a multi-interface host gives the systematic method.

Binding matters across reboots too: cameras must map to ports deterministically or the software opens the wrong device after a power cut, and assigning cameras to ports reliably in a multi-camera system shows the MAC-based way. Throughput across a routed hop also improves when the NIC hands packets to the SDK through the vendor's high-performance packet filter; what a high-performance GigE driver actually gains puts numbers on it.

The same address discipline applies when the host is not a PC: a walkthrough of configuring a GigE Vision camera on a robot controller shows the camera port, address and I/O settings a controller-based host must get right.

A standard PC grows the second segment with an add-in port. Hardware that fits the two-segment host:

The MV-GE2002P is a dual-port PoE NIC with two GigE ports, so a tower PC runs two camera segments, one per port, with power on the camera cable. The MV-VC3301H-128G66 is a vision controller in the same role at larger scale: a bank of LAN ports (5+ on this model), four built-in light channels, and the vision runtime included under license.

Which firewall ports must be open for control and streaming?

Open UDP port 3956 in both directions between the host and camera addresses for discovery and control, then add an inbound rule for the image stream: UDP arriving from the camera's address to the destination port your acquisition library announces.

Port 3956 carries the GigE Vision control protocol: discovery questions and answers, force-IP, and the heartbeat that keeps an open control session alive. Scope both rules to the two addresses — host 10.10.9.20, camera 10.10.4.50 — rather than to the whole VLAN. On a Windows host that is one inbound and one outbound UDP rule with the camera's address as the remote scope; on Linux, the same two lines in firewalld or ufw.

The image stream is the second rule. The library announces a host UDP port when it opens the stream, and packets arrive at that port from the camera's address. Either scope an inbound UDP rule to the camera's address and the library's stream port, or allow the acquisition application itself — the application-level rule survives a change of stream port.

How do you verify the path and size the bandwidth?

Test in order — ping, unicast discovery, control open, then streaming — and set the camera's packet size to the smallest MTU on the path, 1500 bytes, unless you have confirmed jumbo frames survive every switch and the router between the two subnets.

1. ping 10.10.4.50 — routing exists. If this fails, fix routing first; nothing after it can work.
2. Run unicast discovery against 10.10.4.50 — UDP 3956 now passes both ways.
3. Open the camera in the SDK and read a register such as device temperature — the control channel holds its heartbeat.
4. Grab 100 frames and check that none are short or missing. Partial frames point at packet size, and incomplete frames from a driver and NIC MTU mismatch is the dedicated diagnosis.
5. Set the camera's packet size to the path's smallest MTU — 1500 bytes unless every hop is jumbo-capable.
6. Measure throughput at the production frame rate and keep about 20 percent headroom; planning switch ports and bandwidth for a GigE camera network extends the budget to multi-camera layouts.

Then check the arithmetic against your own camera:

A 2448 × 2048 mono 8-bit sensor delivers 2448 × 2048 = 5,013,504 bytes per frame. At 20 fps: 5,013,504 × 20 = 100,270,080 bytes/s, and 100,270,080 × 8 = 802,160,640 bit/s ≈ 802 Mbit/s of payload. A GigE port yields roughly 950 Mbit/s of practical payload — 1000 Mbit/s of line rate less framing and inter-packet gaps — so this camera consumes 802 / 950 ≈ 84 percent of a port and fits with about 16 percent headroom. Two such cameras on one port would need 1604 Mbit/s and do not fit.

Packet size decides how much line those bytes survive on. Ethernet framing plus inter-packet gaps cost 38 bytes and UDP/IP headers 28, about 66 bytes per packet: at a 1500-byte payload that is 66 / 1566 ≈ 4.2 percent of the line, at 9000 bytes only 66 / 9066 ≈ 0.7 percent. The same camera that streams comfortably on a direct jumbo link can drown in resends at 1500 bytes across a router — the cure is frame rate or windowing, not a bigger NIC.

When should the camera stay on its own subnet instead?

Keep a fixed machine's cameras on a private subnet per NIC: no router hop, broadcast discovery keeps working, and plant IT changes cannot touch the camera addresses. Reserve the cross-subnet design for cameras that must genuinely live on the plant network.

The decision by case:

• One camera beside the host: direct cable, private 192.168.1.0/24, static addresses both ends, no gateway, no firewall work. Done in minutes.
• Several cameras at one station: one subnet per port on a multi-port PoE NIC or on vision controllers; each camera keeps a full port of bandwidth and one segment's fault stays contained.
• Cameras on the plant network — remote enclosures, shared cable runs: the persistent IP, gateway, unicast discovery and scoped firewall design of this guide.
• Service laptops: move the laptop NIC temporarily into the camera's subnet rather than re-addressing the camera.

Static persistent addressing beats DHCP for production lines; reserved leases are acceptable where the IT department owns the addressing.

To choose hardware: the area scan camera finder filters by interface and resolution, the frame grabber category lists the PoE NICs and capture cards for the host side, and the system configurator walks camera, lens, light and controller in order. The systems topic page collects the rest of the networking guides, from discovery failures to bandwidth budgets.