GigE camera on multiple network interfaces: pick the right NIC

Four network interfaces, one GigE camera, and the SDK insists the camera is on a different subnet. The camera is fine: it lives behind one specific interface, and the software knocked on the wrong door. This guide gives you the rule that decides which interface owns which camera, the AND-mask arithmetic that settles it in seconds, a driver-side enumerate-and-test fix for code that always takes interface one, and the address layout that keeps a four-camera PC streaming. Work through it once and the symptom stops coming back.

The symptom: the camera lists, the open fails

The enumeration tool shows the camera with its display name and serial, but the open or Init call fails with an error about a different subnet. Ping answers. After a reboot the same camera sometimes appears under a different interface entry. On a PC with four NICs patched through switches and VLANs, the driver keeps walking the first interface while the camera is only reachable through interface three.

Nothing is wrong with the camera or the cabling. A GigE Vision camera is discovered by a subnet broadcast, not by ping, and that broadcast never leaves its own subnet — that is why ping passing proves so little. If nothing lists at all, start with the subnet and compliance checks instead; more interface-level faults sit on the systems topic page. The failure here is narrower: the camera is found, and the open is refused.

Why the rule is one subnet per interface

Each GigE Vision network adapter — and each port of a multi-port card counts as its own adapter — must have its own IP address on its own subnet. Discovery runs as a broadcast from every interface; a camera answers the interface that shares its subnet, and that reply is what the SDK turns into a camera entry.

A camera holding persistent IP 192.168.30.42 can only be opened cleanly through an interface that lives in 192.168.30.0/24. When a driver walks only the first interface and that interface sits on 192.168.10.0/24, the open ends in a different-subnet error even though discovery worked. A camera behind a router can be configured with forwarding at both ends, but the broadcast stops at the router and every stream then needs explicit relay work — a setup to avoid, not a setup to build. Keep the stream Layer-2-adjacent: one subnet, one interface, one camera group.

The arithmetic that decides an open

Worked example, four interfaces, one subnet each:

Camera A holds persistent IP 192.168.30.42 with mask 255.255.255.0. AND the address with the mask: 192.168.30.42 AND 255.255.255.0 = 192.168.30.0. Against NIC1 the results differ (192.168.10.0), so the open is refused with the different-subnet error. Against NIC3 they match, so the camera opens and streams through NIC3 — and only through NIC3. The whole test is one bitwise AND per interface, and it names the side to fix: the camera's address or the interface's.

The second number: payload per interface

The subnet rule decides whether a camera can open; the payload decides how many cameras may share the interface it opened on. The LS-CMR-0053 is a 12 MP GigE camera that streams 9 fps.

Take a 12 MP frame at 4000 × 3000 pixels and 8 bits per pixel (Mono8): 4000 × 3000 = 12,000,000 pixels × 1 byte = 12 MB per frame. At 9 fps the payload is 9 × 12 MB = 108 MB/s, and 108 MB/s × 8 = 864 Mbit/s. A gigabit interface moves 1,000 Mbit/s, so this single camera runs its link at 86% before any packet overhead. A second identical camera would demand 864 + 864 = 1,728 Mbit/s and cannot fit; frames drop or arrive incomplete.

Decision: one camera of this class per interface, or cut payload — lower frame rate, smaller ROI — until the per-interface sum stays under roughly 900 Mbit/s. The 900 figure keeps about 10% of the line for headers, trigger spacing and the display copy; jumbo frames raise the ceiling a little, many small devices on the same switch lower it. This division is the first step of a multi-camera GigE bandwidth budget, and the high-performance NIC driver buys back part of the overhead. When frames do arrive incomplete, shared-trigger cameras on one link are the usual place to look.

Test the causes in this order

1. Camera IP outside every interface's subnet. Run the AND test above. Fix: set the interface's address into the camera's subnet, or readdress the camera to match the interface — one write in the SDK's address tool, then the open passes.
2. The driver binds to the first interface only. Disable every interface except the one sharing the camera's subnet. If the camera now opens, the walk is the bug; apply the fix in the next section.
3. Two interfaces on one subnet. List the addresses: two interfaces with the same prefix split the discovery replies between them, and the SDK hangs or half-finds cameras. The repair is one subnet per interface, not a bigger switch.
4. The camera's address moved. An adapter swap or an earlier readdress can strand an IP the driver still expects; reassign it deliberately and update the runbook.
5. Firewall eats the broadcast reply. Ping passes, the list stays empty; open UDP on the vision interfaces as the firewall discovery check walks through.
6. Payload overflow. Sum the per-camera payloads per interface; near the line rate, frames arrive incomplete under load even though every open succeeded.

Not every refused open is a subnet problem: a GenTL open that fails after discovery points at a driver-layer clash instead, with the same trigger point but a different repair.

The fix in the driver: walk every interface

Enumeration should not trust interface order. The walk treats the interface list as unknown and lets each camera prove where it lives:

cameraList_.Clear()
system_->GetInterfaces()                        // every interface the SDK can see
  iface->GetTLNodeMap()
    InterfaceType                               // keep interfaces that report a camera bus
    InterfaceDisplayName                        // logged next to the serial number
  iface->GetCameras()
    for each camera:
      try { ptrCam->Init(); ptrCam->DeInit(); }   // test-open on this interface
      catch { continue; }                         // wrong subnet: next interface
      cameraList_.Add(ptrCam)                     // keep only what opened

Three properties make the pattern safe. The test-open without acquisition holds the camera for a fraction of a second, so run the walk before production or between cycles. Keeping only cameras that open without error means no camera is ever half-bound to the wrong interface. And the log line — serial plus InterfaceDisplayName — hands you the serial-to-interface table the rest of the configuration should consume.

Run an open-source driver? Send the change upstream as a pull request against the branch you deploy, so the next update does not overwrite it. Bind camera selection to the serial number, never to an index: the same rule that stabilizes multi-camera depth hosts applies here, because the index follows enumeration order and the serial is printed on the housing.

The address plan that prevents the bug class

Give every interface a distinct private /24 — 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, 192.168.40.0/24 with the PC at .11 and cameras from .20 up. Set persistent addresses once, write the serial-to-interface table into the runbook, and the AND test passes by construction.

Switches stay simple: one unmanaged switch per subnet on the bench, with no configuration. If the cabinet also carries plant traffic on the same cabling, that is the four-NIC, four-VLAN layout described in the switch question above, and it behaves once every piece of software walks all interfaces.

Hardware: one port per camera

Multi-interface machines built for vision make this layout the default. A vision controller carries its LAN ports on board, so each camera gets a dedicated interface and its own subnet without expansion cards.

The MV-VC3301H-128G66 pairs 5+ LAN ports with 4 built-in light channels, so one box binds the cameras and drives the strobes.

Step up when the cameras should be powered over the cable or the light load grows: the MV-VC5525-256G70-NN adds PoE camera ports and 8 built-in light channels with 32 GB of memory.

The cameras on those ports come from the GigE area scan cameras range in the camera finder: the 2.5 MP global-shutter color MV-CU020-90GC opens on exactly one interface, and when you move a camera off Ethernet entirely, the 20 MP mono MV-CS200-10UM takes the USB3 route.

When the usual answer is wrong

Put everything on one big subnet. It breaks in both directions: multiple interfaces on one prefix split discovery, and a shared link overflows once the payload sum passes the line rate. Distinct /24s per interface cost nothing.

Route the camera subnet instead of adding a port. The broadcast stops at the router and the stream needs forwarding at both ends; one forced-IP reset strands the camera behind the relay. A second network port costs less than the integration time this consumes. The same explicit-bind discipline shows up outside vision too, wherever a service must listen on one chosen interface rather than on whatever answered — for example an OPC UA server configured to listen on a specific network interface.

All four ports of a quad-port card can share one subnet. Each port is its own adapter and needs its own subnet; a quad-port card on one prefix behaves exactly like the two-interface hang.

Checks before go-live

• Every interface carries a distinct private /24, and none touches the office or plant LAN range.
• Each camera's persistent address lands inside exactly one interface's subnet — the AND test confirms it in one line.
• The driver walks every interface and keeps only cameras that pass the test-open.
• Selection binds serial numbers, logged against InterfaceDisplayName.
• The payload sum per interface stays under roughly 900 Mbit/s.
• VLANs, if any, are presented untagged to the interface whose subnet they match.
• The firewall allows UDP discovery replies on the vision interfaces.
• The runbook records serial, interface, IP address and mask for every camera.

The decision, case by case

• One camera, spare ports: put the camera and one interface on a single private /24. Walk-all code stays harmless; the open can no longer refuse.
• Two to four cameras: one interface per camera, one /24 each, walk-all enumeration, serial binding. This layout never surprises you at reboot.
• Cameras share plant cabling: one untagged camera VLAN per interface with the subnet matched, and the stream never crosses a router.
• No free port: cut frame rate and ROI until two cameras share one interface under the 900 Mbit/s line, or move that camera to a USB3 Vision model and leave Ethernet addressing behind.

Map your own camera list to ports through the contact page — include the camera models, serial ranges and interface count, and the port-per-camera layout comes back sized to your payload numbers.