GigE camera not detected: subnet and compliance checks first

A GigE camera that its vendor's own utility finds but your acquisition software does not is one of the most common calls on a vision bench. The camera is almost never at fault: the cause is network configuration — usually a subnet mismatch, sometimes a firewall, occasionally a camera built before the GigE Vision standard that can never enumerate in a GenICam library. This guide gives you the triage order, the arithmetic that proves the subnet fix, and the one test that separates a configuration problem from a protocol problem.

Two failure families, and why the vendor tool can lie to you

A GigE Vision library discovers cameras by sending a UDP broadcast to port 3956, the control-protocol port the standard reserves. A broadcast reaches only devices on the same IP subnet as the interface that sends it; it never crosses a router. That single fact explains most "camera not detected" tickets.

Vendor utilities often cheat. Many scan below the IP layer, ignore your subnet entirely, and can send a command that rewrites the camera's address to match the host NIC. So the camera working in its own tool proves power, link and cable — and nothing about your network configuration. Every check below assumes the standard discovery path, because that is what GenICam software uses.

Cause 1: camera and NIC on different subnets

This is the most common cause by a wide margin, and the fix takes two minutes: NIC 192.168.1.10 and camera 192.168.1.20, both with mask 255.255.255.0. Prove it with the AND operation the IP stack itself performs:

Under a 255.255.255.0 mask (a /24) the first three octets must match and the last must differ, which leaves 2^8 − 2 = 254 usable addresses. Note the trap: a camera at 192.168.2.20 can still answer a ping from a NIC at 192.168.1.10 across a router, and discovery still fails. Routing success is not discovery success.

Apply the fix in either direction: move the NIC into the camera's subnet, or write the camera into the NIC's subnet as a persistent address with any GigE Vision configuration tool. Do the second on an isolated bench switch, because an address changed on a shared plant network can collide with a device you cannot see from where you sit.

Cause 2: use link-local fallback on purpose

When a camera gets no DHCP lease, the standard address order — persistent address, then DHCP, then link-local — leaves it on 169.254.x.x. Set the host NIC to obtain an address automatically and it lands in the same 169.254.0.0/16 range, which offers 2^16 − 2 = 65,534 addresses. Both ends are now one subnet and discovery works with no planning at all.

Link-local is the right answer for a single-camera bench, a demo case or a service visit. It is the wrong answer for production: addresses are unpredictable, nothing can be written down, and a second camera makes cabling records worthless. Move fixed addresses onto one planned /24 before the machine ships.

On Linux the same behaviour holds. The Linux GigE Vision camera discovery troubleshooting guide walks the command-line checks, and the link-local address guide shows how to reach a fallback camera directly by its raw address.

Cause 3: the firewall eats the discovery broadcast

The discovery broadcast arrives at UDP 3956 on the host, and host firewalls routinely drop unsolicited inbound broadcasts. The thirty-second test: on a bench machine, disable the firewall, rescan, re-enable it. If the camera appears, filtering was the cause — keep the firewall on and add an inbound rule for UDP 3956, plus any ports your acquisition suite lists for its device service.

Watch the second hop: after enumeration, the streaming channel runs over a separately negotiated port, so a policy that admits discovery can still block video. That presents as a camera that enumerates and then times out on frames. The GigE Vision camera firewall guide lists the rule set that keeps both paths open.

Cause 4: discovery leaves through the wrong NIC

On a multi-NIC host the library can bind to an adapter the camera is not on. Disable every adapter except the camera's, rescan, then re-enable the others one at a time; most acquisition suites also let you select the interface in their settings.

Never give two adapters on one host the same subnet. That configuration does not fail politely — it can hang the discovery stack entirely, and the two adapters on the same subnet guide covers that failure. For hosts moving to several cameras, budget bandwidth per port before you add anything; the multi-camera discovery guide covers the enumeration side of that job.

The fatal cause: a camera that never spoke GigE Vision

GigE cameras existed before the GigE Vision standard was first published in 2006. Early models carried proprietary control and streaming protocols inside their interface engines, and such an engine talks only its own SDK — a GenICam library will never enumerate it, on any subnet, with any firewall setting. Some engines offered compliance as a firmware option, and vendors occasionally issued standard firmware later, but many did not.

The test isolates the protocol question from the network question. Put a second, current GigE Vision camera on the same port and cable:

If the second camera enumerates immediately while the first still does not — with the subnet arithmetic above confirmed and the firewall disabled for one scan — the first camera's interface engine is the suspect. Ask its vendor, with the exact model and engine revision in hand, whether GigE Vision firmware exists. A firmware upgrade is the only fix that is not a replacement; if none exists, replace the camera, because no network setting changes what protocol a camera speaks.

Triage order and the decision for each case

Run the checks in this order — each step either fixes the camera or proves the next step is the right one:

1. Confirm power and link LEDs, and that the switch port shows a gigabit link.
2. Read the camera's address in the vendor tool and AND it with the mask against the NIC's address. Different first three octets under 255.255.255.0 is the fault — fix it and rescan.
3. Still invisible: set the NIC to automatic addressing so both ends land on link-local, and rescan.
4. Still invisible: one scan with the firewall off on the bench, then open inbound UDP 3956 and leave the firewall on.
5. Multi-NIC host: disable all other adapters and rescan.
6. A known-good camera works on the same port and cable while the original does not: request GigE Vision firmware from the vendor or order the replacement.

Decision per case: write the persistent address in after a subnet fix so it survives reboots; treat a link-local fix as bench-only; pair a firewall fix with the streaming rules; and end a protocol failure in firmware or replacement — nothing else exists.

Prevention: an address plan and two bench habits

Write the plan before the first cable: one private /24 per bench or machine, NICs in the .10–.19 range, cameras from .20 upward, switch infrastructure at .1, all of it recorded on the panel drawing. Use persistent addresses at both ends so a headless boot finds its camera without a DHCP server and without link-local luck.

Keep two bench habits. First, commission with one camera per NIC, then consolidate — the network planning guide budgets bandwidth per port, and the high-performance NIC driver guide shows what a filter driver adds once frames flow. Second, expect the failure modes to move downstream once enumeration succeeds: a link that falls below gigabit breaks large packets, which the packet-size guide explains, and bursty transfers exhaust host buffers — the GigE camera buffer overflow walkthrough covers that symptom. A camera that enumerates and then delivers grey frames has a different cause set; start at the grey-image guide.

What to order when the answer is replacement

A pre-standard camera is a dead end worth ending quickly. Every GigE camera in the current area scan cameras range speaks GigE Vision and enumerates in any GenICam library:

Size the replacement in the camera finder, resolution and interface first; the camera step of the configurator walks sensor, mount and bandwidth in one pass. If the old camera is a rare spectral variant worth saving, contact us with its exact model and engine revision and we will help you word the firmware question to its vendor. The systems topic page collects the rest of the network troubleshooting guides.