GigE Vision camera connection without broadcast discovery: what works

Plant IT drops broadcast traffic, your vision host sits behind a corporate router, and the SDK that opened this camera yesterday now lists nothing — even though you typed the camera IP in by hand. That combination stalls more GigE Vision commissions than failed hardware does, and no camera setting fixes it. The answer is architectural: discovery is a UDP broadcast by protocol design, so you give it a segment of its own. Here is what the standard puts on the wire, why an open-by-IP call still fails without it, and the network design that satisfies a locked-down plant LAN — plus the point at which you should change the camera interface instead.

What the standard sends during discovery

GigE Vision control traffic runs in GVCP, a UDP protocol on port 3956. Before any feature is set, the host sends a DISCOVERY_CMD as an IP broadcast; every camera on the subnet answers a DISCOVERY_ACK carrying its IP, MAC address, model and capabilities. That exchange is the camera list your software displays, and in most runtimes it runs once, when the application context opens — re-scanning while frames flow is a separate operation, described in camera discovery after connection in a running application.

The intent is zero configuration: power a camera anywhere on the subnet and it appears. The cost is that discovery inherits broadcast's routing rule. The limited broadcast address 255.255.255.255 is never forwarded by a router — that is the IP protocol's own definition, not an IT policy — and subnet-directed broadcasts are filtered on routers as standard practice. After discovery, the SDK opens a control connection (a second GVCP exchange that takes exclusive access, held open by a heartbeat), then the stream protocol carries images on UDP channels agreed in that handshake. The same exchange also rebuilds the list after a camera reboot or a switch port bounce, which is why discovery is not a one-time rite: the host expects it to work whenever it rescans.

Why open-by-IP still needs the broadcast

Typing the IP changes the addressing, not the mechanism. A typical SDK resolves the ID you pass against the list built at startup; with discovery suppressed or dropped, that list is empty, so the call returns device-not-found even though the camera answers ping in under a millisecond. Ping is unicast ICMP and takes one path; discovery is broadcast and takes another — the split we explain further in GenICam discovery uses subnet broadcast: why ping is not enough.

The one-packet symptom has a mechanism too. Some stacks try a targeted unicast discovery to the address you supplied; the capture shows one clean request and reply, then the session dies at the lookup step because the enumeration result is still empty. The protocol itself is UDP, so a purely unicast open to a known IP is legal on the wire. Whether your runtime implements it without enumerating is an SDK detail to confirm once on the bench, not a design to build a production line on.

One confusion to close early: the Windows sharing setting called network discovery governs SMB and function-discovery protocols on the corporate side. It has no effect on GVCP, which is why toggling it never connects a camera.

The decision: give discovery a segment of its own

You cannot switch the broadcast off, so make it harmless. Four decisions define a design both IT and the protocol accept:

1. A segment of its own. A dedicated NIC or a camera VLAN keeps every discovery packet inside the cell. The corporate LAN never sees a camera packet, which is the containment IT actually wants. A VLAN gives the same containment when cabling is shared: camera ports in one VLAN, discovery never leaving it.
2. Capacity per port. A gigabit link carries 1000 Mbit/s ÷ 8 = 125 MB/s of line rate; with 9000-byte jumbo frames a streaming camera lands near 118 MB/s of image payload. Plan one full-rate camera per port and share only low-rate cameras, with the budget method from two GigE cameras on one host: NIC ports and bandwidth budget.
3. A persistent IP inside the subnet. Discovery then finds the camera at the same address on every boot — no DHCP race, no cross-subnet surprise after a power cut.
4. Firewall scoped per interface. Allow UDP 3956 in and out on the camera NIC only, nothing host-wide. If the list fills but frames go missing, work through GigE Vision firewall troubleshooting for missing images.

For the NIC itself, two catalog options cover most cells. The MV-GE2002P is a dual-port PoE NIC, full height, that puts two isolated ports into the host; the LS-FGB-0004 is a PCIe x4 card with four PoE ports. A four-camera cell fits with a port to spare.

Worked example: two NICs on a locked-down plant LAN

Assume a host with its corporate NIC at 172.20.31.40, mask 255.255.255.0, and a second NIC added for cameras on 10.62.7.0/24. The camera's persistent IP is 10.62.7.120.

Camera side: 10.62.7.120 AND 255.255.255.0 = 10.62.7.0, and 10.62.7.0 OR 0.0.0.255 = 10.62.7.255. Host side: 10.62.7.1 AND 255.255.255.0 = 10.62.7.0. The networks match, so the camera is on-link and needs no gateway entry. A /24 offers addresses .1 through .254, so the camera at .120 leaves well over a hundred addresses free for more cameras. Discovery goes out to 10.62.7.255 and to 255.255.255.255; the first stays inside the segment and the second stops at the first router — the containment policy asked for, working by construction.

Corporate side: 172.20.31.40 AND 255.255.255.0 = 172.20.31.0, a different network from the camera NIC. That separation is required, not stylistic: two adapters in one subnet on one Windows host send discovery out the wrong interface and the camera list stays empty. The failure pattern is described in vision software hang: two adapters on the same subnet.

Force IP, persistent IP and open-by-IP

Force IP is the standard's answer to a camera whose address landed in the wrong subnet: the host sends a GVCP command addressed to the camera's MAC and writes a temporary IP. It fixes addressing, not adjacency — the command is still GVCP on the local segment, so no force-IP tool crosses a router either. Use it once, write the same values into the camera's persistent-IP settings, and reboot; from then on discovery resolves at that address on every start. The full first-commissioning sequence, including the subnet checks that precede this design, is in GigE camera not detected: subnet and compliance checks first.

With the persistent IP in place, open-by-IP becomes ordinary: enumeration finds one camera and the call matches it. Runtimes that skip enumeration and open a direct address exist; treat that behavior as a bonus to demonstrate once on your bench, recorded against the SDK version, not as a design assumption. On Linux there is a middle path worth knowing: a camera left on a 169.254.x link-local address opens by IP once the host interface holds a link-local address too, as shown in GigE camera on link local address: open it by IP from Linux.

When no camera segment is allowed: change the interface

If policy forbids any broadcast-capable segment your host can reach, stop negotiating with the protocol and move the camera off Ethernet. Two routes work:

• USB3 Vision. A USB3 camera enumerates over the bus: no broadcast, no subnet, no firewall rule, so plant network policy never applies. The trade is reach — a passive USB3 run stays in the meter range against 100 m for gigabit Ethernet — which suits bench cells and short risers. The camera finder filters area scan cameras by interface, USB3 included.
• Frame grabber. A CoaXPress or Camera Link card speaks no network protocol at all, so broadcast rules are irrelevant by construction. An octo CXP-6 frame grabber such as the MV-GX1008 takes a whole camera cell off the plant LAN in one move. Each CXP-6 connection carries up to 6.25 Gbit/s over coax, several times one gigabit port. Compare the interfaces in the frame grabbers category.

Keep the camera segment cabling plain: matched camera cable of the right length, high-flex types only on motion axes. The cables category sorts them by type and length.

Checks before you sign off the design

Run these checks before the cell ships:

• Camera IP and host NIC pass the AND test into the same network, and the camera's gateway field is empty — discovery is local by construction.
• The camera subnet is unique on the host; no second adapter shares it.
• UDP 3956 passes both ways on the camera interface only; test with the camera list empty and again populated.
• The persistent IP is set and written on the install sheet, with the DHCP and link-local fallbacks noted.
• Stream packet size is negotiated to the largest the path allows — 9000-byte jumbo frames against the 1500-byte default. A link that falls below gigabit otherwise produces packet-size errors, as in GigE camera packet size error when your link drops below gigabit.
• The camera NIC runs the accelerated driver where one exists; the measured gain is in GigE Vision high performance NIC driver: how much you gain.
• One full-rate camera per gigabit port; multi-camera switch budgets come from GigE camera network planning: switch ports and bandwidth.

The end state to aim for: camera and host on one contained segment, persistent IP matching the arithmetic above, one narrow firewall rule — and a plant LAN that never sees a discovery packet. Map the camera, interface and NIC choices for your cell in the configurator, which starts at the camera step: