Link LEDs glow, the operating system shows the network adapter, the camera's status LED is lit — and your acquisition software's device list is still empty. That combination almost never means a broken camera. It means the enumeration chain is broken at one of four layers: the physical link, the IP subnet, the transport layer your software loads, or the firewall. Work through them in that order and the camera appears; this page gives the exact settings, the swap tests, and the packet arithmetic that keeps a found camera streaming.
Why can't my software list a camera the network can see?
Because a GigE Vision camera reaches your application through four layers in a fixed order — a 1000 Mbps link, a matching IP subnet, the GenICam/GenTL transport layer, and the firewall — and the device list stays empty when any single layer in that chain fails.
What the operating system tells you is limited. Device Manager proving the NIC exists, a glowing link LED, even a successful ping: none of those runs the discovery transaction your software depends on. Enumeration sends a UDP broadcast, the camera answers, and the transport layer hands the result to your application. A failure anywhere in that hand-off looks identical from the outside — an empty list.
So read the symptom as a chain, not a mystery. Four checks, in the order below, isolate it in minutes. If you have already worked through the first-response subnet and compliance checks for an undetected GigE camera, use the rest of this page to close the link, driver and firewall layers.
What do I check on the cable and link first?
Confirm the adapter negotiated 1000 Mbps full duplex before you open any software, because GigE Vision cameras stream only at 1 Gb/s, and one damaged wire pair silently drops the negotiation to 100 Mbps, a speed most acquisition programs refuse to enumerate on.
Open the adapter's status page in your operating system and read the link speed. It must show 1000 Mbps, often written as 1.0 Gbps, full duplex. If it shows 100 Mbps, stop there: gigabit ethernet needs all four wire pairs, and a nicked or mis-terminated pair falls back to the two-pair 100 Mbps mode, which passes a casual cable test but cannot carry a GigE Vision stream.
Then fix the cable. Use Cat 5e or better, rated for a 100 m channel, and replace any home-made patch lead with a purpose-built camera cable. Continuous-flex cable goes on a robot arm or drag chain; for a fixed 15 m run, a 15 m RJ45 camera data cable with locking stud keeps the connector seated. Also set both ends to auto-negotiate — a port forced to 100 Mbps on either side produces the same symptom as a bad cable.
A 3 m screw-locked, high-flex lead is the standard bench swap part:
Which IP settings let the camera be found?
Leave the camera on its link-local address in 169.254.x.x with subnet mask 255.255.0.0 and set your network adapter to a free address in that same range, for example 169.254.10.5, or give both sides static addresses in one private subnet.
A camera that gets no DHCP lease and holds no persistent IP falls back to a link-local address inside 169.254.0.0/16, the range the GigE Vision standard sets aside for exactly this case. Your adapter must sit in the same subnet, and with mask 255.255.0.0 the first two octets decide: 169.254.12.5 and 169.254.200.9 are the same subnet; 169.254.12.5 and 192.168.1.5 are not. Set the adapter's IPv4 address, leave the gateway empty, and let the camera keep its fallback.
On a machine with two network adapters, give the camera its own adapter: two adapters sharing a subnet make discovery results unpredictable, and the two-adapters-on-one-subnet fix shows what that looks like. If you prefer fixed addresses on the factory network, give camera and adapter a static pair in one private subnet — 192.168.1.10 and 192.168.1.11, for instance — and keep DHCP off that link. From Linux you can also skip discovery and open the camera directly by its link-local IP.
Which driver does the software need before it lists the camera?
Install the camera maker's GigE Vision filter driver or GenTL producer from its official support download, because your application never reads the NIC itself; it asks a transport layer to enumerate, and with that layer missing or unbound the list stays empty no matter what the network does.
This layer is the one people skip. The NIC driver your operating system installs is not it; the vendor's packet filter driver on Windows, or the GenTL producer your SDK loads, is. Two symptoms tell you where you stand. If no tool on the machine lists the camera, the vendor layer is missing or unbound: reinstall the driver package from the camera maker's official download site and reboot. If the maker's own tool lists the camera but your application does not, the two programs load different transport layers — point your application at the producer that matches the camera and restart it so it enumerates fresh.
Re-check this layer after an operating system update, which can silently drop the filter binding after months of working. The driver-layer walkthrough for software that cannot find a camera covers the whole stack in depth.
Can the firewall really block a camera?
Yes — discovery travels as a UDP broadcast on port 3956, the port the GigE Vision standard reserves for camera control, so a firewall that passes ping but drops UDP 3956 keeps every camera off the list while every other network test looks clean.
Discovery is a broadcast your application sends out and an answer the camera sends back, both as UDP datagrams on port 3956. Firewalls commonly pass the outbound broadcast and drop the inbound answer, especially while the adapter's network profile is set to Public. Ping works the whole time because ping is ICMP and needs no port — that is the signature of this failure, and the diagnosis for ping working while zero cameras appear starts here.
The test takes a minute: allow the acquisition application through the firewall, or add inbound and outbound rules for UDP port 3956 on the camera's adapter, set that adapter's network profile to Private, and re-enumerate.
How much bandwidth does a GigE camera need once it is found?
A full 1 Gb/s link moves about 122 MB/s of image data as roughly 81,300 packets per second at the standard 1500-byte frame size, and about 124 MB/s as roughly 13,800 packets per second with 9000-byte jumbo frames.
Run the budget before you add a second camera to the link. Gigabit ethernet moves 1 Gb/s, which is 125,000,000 bytes per second. Every frame on the wire carries fixed overhead: 8 bytes of preamble, 14 bytes of ethernet header, 4 bytes of frame check, and 12 bytes of inter-frame gap — 38 bytes in total. Fewer packets per second means less interrupt and buffer work on the host, which is what keeps a busy machine from dropping a camera it had already found.
Worked example, at the standard 1500-byte frame: 1500 + 38 = 1538 bytes on the wire; 125,000,000 / 1538 ≈ 81,300 packets per second; 81,300 × 1500 ≈ 122 MB/s of payload. With 9000-byte jumbo frames: 9000 + 38 = 9038 bytes; 125,000,000 / 9038 ≈ 13,800 packets per second; 13,800 × 9000 ≈ 124 MB/s. The camera's own protocol headers ride inside that payload, so read the payload numbers as ceilings.
This belongs in a not-detected article because a saturated adapter is how a camera that enumerated at boot disappears mid-shift. Set the packet size to the largest the whole path accepts before acquisition starts: the packet-size-before-acquisition procedure, the test-packet failure fix, and the MTU cap for oversized packet-size settings cover the three ways that step goes wrong.
Give each camera its own port rather than a shared link — a dual-port PoE NIC does that and powers the cameras over their data leads. For capture cards and multi-port adapters, see the frame grabbers category, and for the per-port arithmetic, the bandwidth budget for two GigE cameras on one host.
The NIC that carries the stream:
- Interface
- GigE
- Ports
- 2 ports
What order should I run the checks in?
Run the five checks in chain order — link speed, cable, subnet, transport layer, firewall — about ten minutes end to end, and stop at the first layer that fails, because a later layer cannot compensate for an earlier one.
- Link speed. Read the adapter status: it must say 1000 Mbps full duplex. If not, fix the cable or port before anything else.
- Cable swap. Replace the cable with a known-good, screw-locked lead and re-read the link speed; this clears the most common hardware cause in two minutes.
- Subnet. Adapter IPv4 at a free 169.254.x.x address with mask 255.255.0.0, or a static pair in one private subnet; gateway empty.
- Transport layer. Vendor filter driver or GenTL producer installed and bound; restart the application so it enumerates fresh.
- Firewall. Allow the application, or open UDP port 3956 in and out on the camera's adapter; network profile Private.
If all five pass and the list is still empty, the remaining suspects are a second adapter shadowing the first and, rarely, the camera itself. The next section decides that.
How do I tell a broken camera from a broken network?
Only the swap test decides it: if a second computer with a known-good gigabit link, cable and subnet still cannot list the camera, the camera's network port or board has failed, while any computer that lists it proves the camera is fine and the first host carries the fault.
Before swapping, rule out power. A PoE-fed camera needs its full budget: an 802.3af port supplies up to 15.4 W, roughly 13 W of which arrives at the camera, while a weak passive injector or an overloaded switch port can leave the network chip half-alive — LEDs on, no discovery. Match the camera's status LED pattern against its manual, and seat the RJ45 firmly; a hanging cable works the latch loose over weeks.
Then swap. Move the camera to a second computer with a known-good gigabit adapter, a short known-good cable, and an adapter address in 169.254.x.x. That machine listing the camera within a minute sends you back to the five checks on the first host. No machine listing it, across two hosts, is the signature of a failed port or board, and the camera needs service rather than configuration. A basic global-shutter model such as the MV-CU020-90GC 2.5 MP GigE camera is a useful bench reference to keep for exactly this test.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
That is the whole chain: gigabit link, matching subnet, vendor transport layer, open UDP 3956, then packet size once it streams. If you are building the host side from scratch, start in the area scan cameras category or configure a camera step by step, and pick cabling with the link and flex ratings above. For hands-on help with a stubborn unit, use the contact page. More enumeration and acquisition fixes sit on the systems guides page. If the host at the end of the cable is a robot controller rather than a PC, the same layers apply through its own network stack — the GigE Vision camera connection troubleshooting guide for a robot controller walks that variant.
Questions
Can two GigE cameras share one network port?
Budget one gigabit port per camera. A single 1 Gb/s link tops out near 122 MB/s of useful stream, so two cameras streaming at full rate share roughly 61 MB/s each and both drop frames. A dual-port PoE NIC such as the MV-GE2002P gives each camera its own port and its own power over the data lead. The bandwidth-budget article on two GigE cameras on one host runs the complete math.
Does a USB-to-Ethernet adapter work for GigE cameras?
For a bench test, often; for a machine, no. USB adapter chipsets vary in sustained throughput and in how well a vendor filter driver binds to them, and an adapter that enumerates the camera can still drop packets once the stream runs at full rate. Use an onboard or PCIe gigabit port on the host, and keep a USB adapter for temporary diagnosis only.
The camera appears in the maker's tool but not in my application — why?
Each program enumerates through its own transport layer. The maker's tool loads the producer it ships with, while your application may point at a different GenTL producer or at none — GenICam-based applications select producers by a .cti file in their configuration. Set that path to the producer matching your camera, then restart the application so it enumerates fresh.
How do I find the camera's IP address when nothing lists it?
Use the camera maker's configuration utility, which shows every camera's IP, MAC address and subnet even when acquisition fails, or read the lease in the DHCP server's table. A camera that lost both its persistent IP and its DHCP lease falls back to a random address in 169.254.x.x, which is why the host adapter must sit in that subnet for discovery to work.
Should I leave the firewall off so the camera stays visible?
No. Re-enable it and add one rule instead: allow the acquisition application, or open UDP port 3956 inbound and outbound on the adapter the camera uses, and scope the rule to that adapter or subnet. A permanently open host on a factory network is a far bigger risk than thirty seconds spent writing a correct rule.