GigE camera not discovered on startup: fix the boot order

You power the panel, the cameras blink ready, your vision application starts, and the camera list comes up empty. Ten minutes later the same software finds every camera on the first try, which is the tell: this is a startup-order problem, not a wiring problem. Most GigE Vision runtimes scan the network once when their service starts and repeat the discovery broadcast about once a second after that; any camera that boots late, or any broadcast that leaves through the wrong network adapter, stays invisible. This page gives you the boot sequence that works on a single-NIC bench PC and on a multi-NIC controller, the two checks that prove discovery ran, the Windows binding-order fix, and a prevention checklist for your golden image.

What discovery actually does

Discovery is a broadcast, not a wiring test. When the vision runtime enumerates devices, it sends a UDP discovery request on port 3956, and every GigE Vision camera that hears it answers with its MAC address, IP, model and serial. Routers do not forward broadcasts, so only cameras on a subnet your adapter reaches can answer. Three consequences follow:

• The scan runs when the runtime initializes, before your application draws its first window.
• Most drivers repeat the request about once per second while idle, so a camera that boots a few seconds late is caught by a later cycle; a stack that scans exactly once needs a manual refresh.
• With two or more adapters, Windows decides which one carries the broadcast. If that adapter has no camera on it, the reply list is empty while the network itself is healthy.

Watch it directly in a packet capture: filter for the GigE Vision Control Protocol (GVCP) and you see one request line per scan cycle, one reply line per camera. A capture separates a timing problem from a routing problem in under a minute.

Every GigE area scan camera answers the same request the same way; the MV-CU020-90GC, a 2.5 MP GigE camera with a 1/1.7" sensor, a C-mount lens mount and a global shutter, is a typical example.

Why the list is empty: causes in order of probability

Work down this list; the first three explain most cold boots that lose cameras.

1. The application started before the runtime finished discovery. Your software's device list was filled by the runtime's scan, not by a new search. If the application auto-starts at login while the runtime is still scanning, the list arrives empty. Test without rebooting: open the runtime's device window and refresh — cameras appear, so order is the fault.
2. The camera powered after the scan. A PSU that ramps up late, or a PoE port that energizes after login, puts the camera behind the scan. Test: power the cameras, wait for the link LEDs, then start the software.
3. The broadcast left through the wrong adapter. With several NICs, Windows sends from the adapter highest in the binding order, often the office LAN. Test: capture with the gvcp filter; if no request appears on the camera NIC, fix the binding order.
4. A subnet mismatch. The camera sits on 192.168.10.x while the adapter stayed on 192.168.0.x, so no reply is possible. Test: the AND check in the worked example below.
5. The runtime has no license. Some runtimes enumerate nothing when their GigE license dongle or activation is missing, and the failure looks exactly like a network fault. Test: the license line in the runtime's debug window.
6. A deeper enumeration fault: a red X in the software, a link that fell to 100 Mbit, or a driver mismatch. Start from the GigE camera red X fix plan.

The startup order that works

Fix the sequence once and the fault stops coming back on every cold boot:

1. Power the cameras first and let them finish booting: at least five seconds, or until each link LED is up and steady.
2. Let Windows finish bringing up every adapter; no "identifying" state, link LEDs on.
3. Start the vision runtime service, not the application.
4. Open the runtime's device or debug window and confirm two lines: the license is detected, and one entry per camera shows an IP address and serial.
5. Start the application; it inherits the already-enumerated list.
6. If a camera is missing, use the runtime's refresh or re-enumerate command instead of rebooting. With the repeat broadcast running, a late camera answers within a few seconds of being up.

Prove it in the runtime's debug window

Two lines decide where you debug next. The license line says whether the runtime may touch GigE at all; a missing dongle keeps the camera table empty no matter how good the wiring is. The camera table says the scan worked: one entry per camera with its IP address and serial. License present and table full means launch the application — if the application still reports nothing after a refresh, the fault is in the application's own enumeration settings, not the boot order. If the runtime itself fails to start, that is a different problem; the vision application startup guide covers missing components.

Move the camera adapters to the top of the binding order

Windows keeps network adapters in an order, and some enumeration stacks simply use the first adapter with a route out. Office LAN first means the discovery broadcast walks toward the corporate router and dies there. Put the camera NICs at the top:

• Windows 10: open Network Connections (ncpa.cpl), press Alt to show the menu bar, then Advanced > Advanced Settings, and move the camera adapters to the top of the Connections list.
• Windows 11: Settings > Network & internet > Advanced network settings, then reorder adapters on the advanced adapter settings page.

Re-check the order after every NIC driver or Windows update, because updates can reset it. Binding order also decides which adapter carries the jumbo-packet setting, so set the packet size before starting acquisition on the same adapter you just moved up. A sturdier alternative on multi-NIC PCs: give each camera NIC its own subnet and, if your software offers it, restrict enumeration to that adapter's address so the office LAN never enters the path.

One subnet per NIC, and a firewall rule for port 3956

• One subnet per adapter. Two NICs both on 192.168.1.x make routing unpredictable and can separate a request from its replies. Give each camera NIC its own /24 — 192.168.1.x on the first, 192.168.2.x on the second — and keep each camera on its adapter's subnet. If an address change stranded a camera, the camera IP assignment recovery guide walks the fix.
• The firewall must pass the runtime's UDP traffic on port 3956, including broadcasts. Windows asked for permission the first time the runtime ran; a declined prompt stays declined until you add the rule. Cameras cannot answer a request that never reaches them, and the capture described above shows the silence directly.

Worked example: subnet arithmetic and the five-second wait

The subnet check is one AND per address. Camera at persistent IP 192.168.10.20, adapter at 192.168.10.1, netmask 255.255.255.0:

During a cabinet rebuild the adapter moves to 192.168.0.1: 192.168.0.1 AND 255.255.255.0 = 192.168.0.0, which no longer matches 192.168.10.0. No broadcast reaches the camera and no reply can return, so the empty list is arithmetic, not hardware.

The timing side works the same way. The repeat broadcast cycle is about one second; a camera answers within a second of being up; camera boot after power takes roughly five seconds on typical models. Waiting five seconds between runtime start and application start covers three scan cycles with margin, and a single refresh covers a straggler. If a capture at that point shows requests but no replies, stop adjusting software: the fault is address, mask or firewall.

When the usual answer is wrong

Some empty lists have nothing to do with boot order:

• The link fell to 100 Mbit: enumeration can then fail or acquisition breaks right after; the symptom and fix are in the link below gigabit article.
• Several vision packages on one PC each run their own discovery and contend at startup; the discovery contention guide shows how to spot it and schedule around it.
• Many cameras behind a switch: capacity and bandwidth belong in the network planning guide.
• The camera is USB3, not GigE: its enumeration is local to the port, so no network fix applies.

If the debug window lists every camera and the application still shows none after a refresh, stop reordering adapters and check the software's enumeration settings — most packages can restrict discovery to a chosen adapter, and that selector is the next thing to look at. For the full cause-by-cause walkthrough with captures, see network camera discovery troubleshooting.

Prevention checklist

Bake the fix into the panel image so a rebuilt PC inherits it:

• Cameras powered before the runtime starts; late boots miss the scan.
• Runtime service starts automatically; the application starts only after the debug window shows license and cameras.
• Camera NICs at the top of the binding order; re-check after driver and Windows updates.
• One /24 subnet per adapter; camera addresses match their adapter's subnet.
• Firewall rule for UDP port 3956 saved in the image.
• Jumbo-packet setting applied to the camera adapters only.
• After every Windows update, run the 60-second check: debug window, license line, camera table, one gvcp capture.

Controllers that make startup order boring

On a single-NIC office PC you fight the binding order every time Windows updates. On a machine-vision controller you do not: the vision controllers carry several built-in Ethernet ports, so each camera gets its own NIC and its own subnet and the office LAN never enters the discovery path. The MV-VC3301H-128G66 vision controller ships with five or more LAN ports, an Intel Core i3 processor, 8 GB of memory and four built-in light channels.

All 2 share: Humidity 20% RH to 95% RH (no condensation); Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-VC5525-256G70-NN adds PoE camera ports, so each camera draws power over its data cable and the cabinet loses the camera PSUs. Keep the five-second habit: PoE cameras still boot after the ports energize, so the refresh command stays part of the routine.

Where to go next

Sequence the boots once and the empty list shrinks to a five-second wait. To spec the hardware, start at the camera finder or go straight to the system configurator and pick a chassis with one LAN port per camera; free expert support comes with every order, so send the camera list and let us match the controller and light channels. For more like this, the systems topic page gathers the GigE and integration articles. Request a quote when the parts list is settled, or use contact when a capture shows something this page does not.