GigE camera not detected: power, link speed and IP checks

Your acquisition software lists every camera on the bench except the GigE one. Before reinstalling anything, read the camera itself: the two LEDs on its RJ45 jack, the port it occupies on the switch, and the addresses on the host adapter tell you which of three classic faults you have. This page walks the sequence an integrator uses daily — power, link speed, IP addressing, then the software layer — with the numbers that decide each step. It ends with a bench checklist and a decision at every fork, written for anyone commissioning or rescuing GigE Vision area scan cameras on a Windows or Linux host.

Which check comes first: power, link or IP?

Start with the two LEDs on the camera's RJ45 jack: both dark means no power, a flashing yellow with a dark green means the link settled below 1 Gbps, and both LEDs lit with no camera in software points at addressing or the driver layer.

The LED pair at the jack does the triage in seconds, and the order falls out of how GigE Vision works: a discovery packet is under 1,500 bytes, so a camera with power and any live Ethernet link answers the software's broadcast even when its address is wrong. That puts power first, link second, addressing third and the software stack last. Color layouts differ slightly between camera families, so treat the manual's LED table as the authority for your model; the three states below hold across most industrial GigE cameras.

Both LEDs are dark — how do I power the camera?

Power the camera from a PoE injector, a PoE switch, or a 12 V DC supply on the camera's auxiliary power connector; when both LEDs light, the camera is booting and the power fault is closed.

Three supply paths exist and any one of them is enough. A PoE injector sits between the host NIC and the camera and feeds power down the same patch cord; a PoE switch does the same from the port itself; a 12 V DC adapter connects to the auxiliary power connector, Hirose-style on most industrial GigE cameras, with the pin assignment given in the camera manual's connector table.

Size the PoE budget in switch-side terms. IEEE 802.3af reserves up to 15.4 W per port at the injector and guarantees 12.95 W at the camera; 802.3at lifts this to 30 W per port and 25.5 W at the camera, delivered at roughly 37-57 V. A 30 W four-port injector therefore feeds two af-class ports, since 30 ÷ 15.4 ≈ 1.9 — add up the camera draws before trusting a printed budget. A camera drawing more than its port's class allows can enumerate and then reset the moment the sensor starts streaming.

If both LEDs stay dark on a known-good injector and a known-good 12 V adapter, the camera's power input has failed and the camera moves to the replacement list, not the troubleshooting list.

Why does the camera drop out the moment live video starts?

A camera that enumerates and then vanishes when live mode starts is on a link that never reached 1 Gbps: the yellow LED flashing with the green LED dark means the port fell back to 100 Mbps, which carries about 12.5 MB/s — enough to enumerate, never enough to stream.

Discovery survives a slow link because a broadcast packet is tiny; a video stream is not. Set the expectation with two numbers: a gigabit link moves 1000 ÷ 8 = 125 MB/s on the wire, of which roughly 112 MB/s reaches pixels after GigE Vision overhead, while a 100 Mbps link moves 12.5 MB/s.

Worked example: the LS-CMR-0053 is rated 12 MP at 9 fps. Assume mono 8-bit, one byte per pixel: 12 × 9 = 108 MB/s of payload. On a healthy gigabit link the budget is about 112 MB/s (1000 ÷ 8 = 125, then 125 × 0.9 ≈ 112), so the stream fits with roughly 4 MB/s to spare. On the 100 Mbps link the budget is about 11 MB/s (12.5 × 0.9 ≈ 11), and 108 ÷ 11 ≈ 10 times more than the cord can carry — so the camera answers discovery all morning and drops the second live mode opens. An RGB pixel format triples every payload figure.

Fix the physical link before touching a single setting: fit a new Cat5e or Cat6 patch cord, reseat both connectors, confirm the switch port shows 1 Gbps, and leave the host NIC on auto-negotiation, which 1000BASE-T requires. A cord dragged through a machine frame often has one damaged pair that renegotiates at 100 Mbps while the switch itself looks healthy. When the link is gigabit and frames still vanish mid-stream, GigE camera packet size error when your link drops below gigabit covers the next suspect, and GigE camera network planning: switch ports and bandwidth covers the shared-switch case.

If you want a stream-rate reference for what one healthy gigabit link carries, this is the camera used in the example.

What IP addresses should the camera and the adapter have?

Give the network adapter and every camera on it addresses inside one subnet — adapter 192.168.1.1 with cameras at 192.168.1.2 and 192.168.1.3, mask 255.255.255.0 — because a camera addressed outside that block streams nothing even with perfect power and link.

GigE Vision discovery is a UDP broadcast on port 3956, so the IP configuration utility that ships with the camera SDK hears every camera on the adapter — including cameras whose address is wrong. That makes the utility a detector, not the fix. To stream, the camera and the adapter must share a subnet; most utilities then apply a new address in two steps, a temporary address first and the fixed address once the camera reappears in the list. Three arrangements cover every installation: fixed addresses, set once and never changed, for a host with several adapters; DHCP where a server already runs; and link-local for a single-adapter bench with no server. The surrounding compliance checks — driver versions, firewall rules, packet size — are walked through in GigE camera not detected: subnet and compliance checks first.

How do I plan addresses across two or three network adapters?

With two or three network adapters, give each adapter its own /24 subnet and keep its cameras inside it: 192.168.1.1 on adapter one with cameras at 192.168.1.2 and 192.168.1.3, 192.168.2.1 on adapter two with 192.168.2.2, 192.168.3.1 on adapter three with 192.168.3.2.

One adapter, one /24 subnet, its own cameras — the plan that keeps discovery and streaming unambiguous:

Two cameras can share one adapter while their combined payload stays inside the link budget; beyond that, add adapters instead of squeezing the frame rate. Server-class NICs absorb GigE Vision's burst pattern far better than onboard desktop ports, which is why multi-camera hosts get one good NIC per camera. Two GigE cameras on one host: NIC ports and bandwidth budget works that arithmetic in full, and GigE camera on multiple network interfaces: pick the right NIC covers hosts where cameras share the box with the office network.

Can I run a GigE camera with no DHCP server on the bench?

Yes: set the adapter and the camera to DHCP with no server on the network, let the DHCP timeout expire, and both self-assign inside 169.254.0.0/16 with mask 255.255.0.0 — the simplest working arrangement for a bench with one adapter.

With nothing to answer the DHCP request, the adapter and the camera both wait out the timeout and self-assign from the 169.254.0.0/16 block — link-local addressing. Discovery works, streaming works, and no addressing decision is ever made or forgotten. Keep it on the single-adapter bench: two adapters both on link-local cannot tell the software which camera belongs to which NIC, and a production cell deserves fixed addresses so a reboot changes nothing. To open a camera at its self-assigned 169.254.x.x address from Linux, GigE camera on link-local address: open it by IP from Linux gives the commands.

Power, link and IP are right — why is the camera still not in my software?

Then the fault sits in the software stack: a firewall dropping UDP 3956 discovery on that adapter, a missing or disabled filter driver or GenTL producer, or another process holding the camera in exclusive access — and each has a test that takes about two minutes.

1. Firewall. Disable the host firewall for one enumeration attempt. If the camera appears, re-enable the firewall and add a rule allowing UDP 3956 on the camera adapter — never leave the port open to the whole plant network.
2. Driver layer. Acquisition software reaches the camera through a filter driver or GenTL producer installed with the camera SDK. The IP utility seeing the camera while the acquisition program does not points squarely here: reinstall the SDK's GigE component and confirm the producer is enabled on the adapter that holds the camera.
3. Exclusive access. GigE Vision grants one controller per camera, so close every viewer, demo tool and second instance; multiple vision software instances: one camera per process explains the locking.
4. The enumeration chain. If those three check out and the list is still empty, follow GigE Vision camera not detected in software: fix the enumeration chain from its first step. A camera that appears and then errors mid-stream has moved to the transport layer, which GigE camera red X error in your vision software: a fix plan addresses.

What order do I follow on the bench?

Follow the LED tree every time: both LEDs lit, then the green gigabit LED, then a shared subnet, then the software — a routine that separates a dead supply from a blind driver in under five minutes on any bench.

• Power: both RJ45 LEDs lit — a dark pair sends you to the supply path, not the software: injector, PoE switch port or 12 V adapter, in that order.
• Link: the green gigabit LED lit — yellow-only means 100 Mbps, so renew the patch cord before touching a setting.
• Address: adapter and every camera inside one subnet per the table above.
• Software: camera listed in the SDK's IP utility, then in the acquisition program; if only the utility sees it, run the firewall and driver-layer tests.
• Replacement: dark LEDs on every known-good injector and adapter mean the camera's power input has failed — stop swapping cords.

The decision at each fork is mechanical: dark pair, feed the camera; yellow-only, renew the physical link; both LEDs and still blind, align the addresses then clear the software stack. And when the fault follows the camera instead of the bench, replace it — the three GigE models below cover the usual resolution bands:

Pick by the pixel count, shutter and sensor format your inspection needs, then let the camera finder or the camera step of the configurator do the filtering; the area scan cameras range spans GigE, USB3, 10GigE and CoaXPress. More enumeration and bandwidth checks live on the systems topic page, and if a fault survives this whole sequence, the contact page reaches the applications team.