Access GigE cameras from another subnet without direct cabling

Factories rarely cable every camera to one switch. The layout in front of you is common: acquisition PCs, each with its own adapter and its own camera subnet, and a central server on a different subnet that must configure every camera and view every image. That last hop is where it fails, because the broadcast that lists GigE Vision cameras stops at the first router. What follows is the reason, the fix — a GigE Vision server re-publishing each camera onto the uplink subnet — the addressing plan that keeps it stable, and the bandwidth arithmetic that decides whether the uplink can carry the pixels.

Why can't the server see cameras on another subnet?

Because GigE Vision discovery is a limited broadcast to 255.255.255.255, and routers do not forward limited broadcasts — a camera on 1.0.0.0/24 will never answer a discovery sent from 192.168.1.0/24, no matter how correct its IP settings are.

Your camera settings are correct — inside 1.0.0.0/24. The server's discovery request is correct too — inside 192.168.1.0/24. The router is also behaving normally: forwarding a limited broadcast is not what routers do. The cameras answer their local PC, and the central server's device list stays empty. Streaming is a different matter: once a session exists, image packets are unicast and routable like any other UDP traffic. Discovery is broadcast-only, and that asymmetry is the entire problem. It is also why a camera that answers ping can still be missing from the device list; GenICam discovery uses subnet broadcast: why ping is not enough covers that mechanism in detail.

How does GigE Vision discovery actually work?

The host broadcasts one discovery command on the local subnet; every camera that hears it replies by unicast with its identity — device name, serial number, current IP, subnet mask and gateway — and the host builds its device list from those replies.

The discovery command is a limited broadcast on UDP; the replies come back as unicast. Force-IP — the broadcast mechanism that pushes a new address into a camera — is trapped the same way, so re-addressing a camera from another subnet is no easier than discovering it. After discovery, the host opens a control channel over UDP and a streaming channel for the image data, both unicast and both routable. A few stacks also accept a discovery command sent unicast to a known address; where yours does, you can reach one camera by typing its IP, but that is a per-camera shortcut, not fleet management.

Can routing alone fix it?

Partly: a routed network can carry the unicast control and streaming traffic once a session exists, but it cannot carry the broadcast that creates the session — so routing alone never makes a remote camera appear in a discovery list.

Four conditions must all hold: the camera has a default gateway pointing at the router on its subnet, the server has a route back, the firewall between the zones passes both the control and the streaming UDP traffic, and your software can open a device by explicit address without a broadcast hit. Arrange all four on a clean industrial network and a scripted capture such as Command a GigE Vision camera over Ethernet: capture and save images crosses the router without complaint. In practice, most management front ends are built around the discovery list, and most plant firewalls do not open negotiated high UDP ports between zones. When either is true, routing alone stops being the answer and the proxy takes over. The plain single-subnet case, for contrast, is in Connect a GenICam camera to an industrial controller over Ethernet.

What does a GigE Vision server do?

It is a small service on the camera-side PC that enumerates the cameras on its local adapter and re-publishes each one as a GigE Vision device on the uplink adapter, so the central server discovers the proxy and opens it exactly like a local camera.

The proxy holds both roles at once: a GigE Vision client on the camera subnet, and a GigE Vision device on the uplink subnet. Control passes through with the pixels, so the central server sets exposure, trigger source and region of interest as if the camera were local. Most vision platforms ship such a server; in your software it is called a GigE Vision server or a device server, and it must be running before the central side discovers anything. The camera itself keeps its address, its cable and its driver — any camera the local PC already enumerates can be re-published. The card below is a representative C-mount GigE camera of the kind this works for:

On the camera side nothing changes: same address, same cable, same driver.

How do you set it up step by step?

Give every camera a static address in its PC's camera subnet, put a second adapter on each camera-side PC into the uplink subnet, run the GigE Vision server there, then discover from the central server — the eight steps below.

In this example the uplink is 192.168.1.0/24; the camera subnets are 10.10.1.0/24 and 10.10.2.0/24.

1. Write the address plan down first: uplink 192.168.1.0/24, camera subnet 10.10.1.0/24 on the first PC, 10.10.2.0/24 on the second. Every camera subnet must differ from the uplink and from each other.
2. Set each camera to a static address in its subnet — 10.10.1.11 upward — and give that PC's camera adapter 10.10.1.1 with mask 255.255.255.0.
3. Leave the camera adapters without a default gateway, so the operating system never routes camera traffic anywhere else.
4. Give each camera-side PC its second adapter on the uplink — 192.168.1.21 and 192.168.1.22 — with the router as gateway.
5. On each camera-side PC, confirm the discovery list still shows every camera after adding the second adapter. Multi-adapter hosts sometimes bind to the wrong NIC; select the camera adapter explicitly, as GigE Vision camera RTOS port: cross-compiling and multi-NIC discovery explains.
6. Start the GigE Vision server on each camera-side PC: capture side on the camera adapter, publishing side on the uplink adapter.
7. From the central server, run a discovery on 192.168.1.0/24; every camera from both PCs appears. Open one, change an exposure value, power-cycle the camera, reconnect and read the value back.
8. Stream all cameras at production frame rate for several minutes, watch the resend and drop counters, then record the firewall rules you opened between the two subnets.

Mechanical links fail more often than network logic, so lock the camera-side connectors and keep the uplink in solid-conductor runs through conduit. The accessories finder lists data and power cables, and GigE cables covers the shop's range:

How much bandwidth does the uplink need?

Sum every stream the uplink will carry and keep the total under the link rate with headroom — one 6 MP camera at 25 fps in 8-bit mono already needs about 1.3 Gbit/s, so two of them saturate a 1 Gbit link.

Take a 6 MP camera: 3,072 × 2,048 pixels, 8-bit mono, 25 fps. One frame is 3,072 × 2,048 = 6,291,456 bytes. Per second: 6,291,456 × 25 = 157,286,400 bytes, × 8 = 1,258,291,200 bit/s ≈ 1.26 Gbit/s; add about 5 percent for packet headers and resends and one camera stands at ≈ 1.32 Gbit/s. Two cameras ≈ 2.6 Gbit/s, so the uplink is a 5GBASE-T or 10 GigE link, full stop. On 1 Gbit, the same camera tops out near 15 fps: 6,291,456 × 15 × 8 = 754,974,720 bit/s ≈ 0.75 Gbit/s, 0.79 with overhead, leaving real headroom.

Pixel format moves the number fast. Color at 8 bits per channel runs 3 bytes per pixel — triple the sums. 10-bit data is 1.25 bytes per pixel packed and 2 unpacked; 12-bit is 1.5 packed and 2 unpacked. The camera-side PC carries every stream twice — in on the camera adapter, out on the uplink — so budget both links and its CPU. When the uplink crosses shared switches, strain shows as resends before anything else; troubleshooting multi-camera frame drops lists the counters to watch. For copper links above 1 Gbit, 5GBASE-T camera interface: bandwidth, cables and distance covers cable classes and reach.

What breaks these setups most often?

Three faults cause almost every failure: the proxy bound to the wrong adapter, firewall rules that pass discovery but block the streaming ports, and an uplink that fits on paper but drops under burst — check them in that order.

• Adapter binding. The proxy captures on the camera adapter and publishes on the uplink adapter; swap the two and the central server sees nothing. Check both settings first.
• Firewall asymmetry. Discovery replies pass, so the device lists, then the stream stalls because the negotiated streaming ports are blocked. Open the control and streaming UDP ports between the two PCs in both directions.
• Jumbo frames. Camera subnets often run 9,000-byte frames; the proxy re-packets, so leave the uplink MTU at 1,500 unless every device on the path supports more.
• Address collisions. Two teams both choosing 192.168.1.0/24 — one for cameras, one for the uplink — is the classic. The plan in step 1 exists to prevent it.

For faults that predate the proxy — a camera the local PC cannot see either — GigE camera not detected: subnet and compliance checks first is the closer match. Ethernet light controllers discovered by broadcast hit the same wall; give them uplink addresses, as lighting controller Ethernet not connecting: fix IP and firewall describes, and the light controllers category shows which units are networked.

When is a proxy the wrong answer?

When the central server can sit on the camera subnet, when a Layer 2 bridge can merge the camera subnets into one broadcast domain, or when only results — not pixels — need to reach the server, a proxy adds cost without benefit.

• One camera subnet, one switch: re-address everything into a single subnet and put the server on it. No extra software, native discovery, problem gone. If every camera can hang off one switch, this is the answer.
• Policy requires the separation: keep the proxy. Segmented camera networks exist for traffic and security reasons, and the proxy was built for exactly this shape.
• The center needs results, not pixels: run the inspection on the camera-side PC and send pass/fail with coordinates over the uplink. Load drops from gigabits per second to bytes per second.
• A Layer 2 bridge is allowed: one managed switch or VLAN trunk merging the camera subnets into a single broadcast domain restores native discovery without extra software — acceptable only while that domain stays off the office LAN.

Which option should you choose?

Choose the proxy when several camera subnets must be managed from one central seat; choose re-addressing when everything can share one switch; choose explicit-IP routing for one scripted camera; choose results-only when nobody needs to watch pixels at the center.

Before you commit, run this list once:

• Address plan on paper; every camera subnet unique and distinct from the uplink.
• Camera adapters gatewayless; uplink adapters gatewayed.
• Proxy bound correctly on both sides and set to start at boot.
• Sustained load test passed with resend counters at zero.
• Firewall rules between the subnets written down.
• Light controllers and any other broadcast-discovered devices given uplink addresses.

For hardware, the camera finder filters GigE area scan cameras by interface and mount, and the system configurator walks a station from camera to trigger. If you want a second pair of eyes on the subnet plan and uplink budget, the contact page reaches the applications team.