The discovery tool opens, its broadcast goes out, and the device list stays empty — yet the camera answers a ping and the link LEDs are green. Before you re-flash the camera or swap the cable, check the PC side: one extra IPv4 address on the same network adapter is enough to hide every camera on the subnet, because broadcast discovery rides on the adapter's primary address only. In ten minutes you can confirm the cause with ipconfig /all, remove the second address, and bring the camera back with two netsh commands and a reboot.
The symptom: a working link, an empty device list
The tool starts, sends its broadcast, and the list stays blank — or it shows addresses from a subnet you never configured. A unicast ping to the camera still succeeds, which makes the fault look impossible. It is not: unicast and broadcast travel by different rules, and only one of the two is broken.
Ethernet-attached smart cameras and fixed code readers announce themselves through that broadcast, so one sick address on the PC hides the whole line. The same empty-list pattern on GigE Vision gear is why a ping proves nothing about discovery — GenICam discovery uses subnet broadcast: why ping is not enough covers that side in detail.
Why a second IPv4 address breaks UDP broadcast discovery
A UDP broadcast is one packet addressed to every host on a subnet: to that subnet's broadcast address, or to 255.255.255.255 for a global broadcast. Windows picks the sending interface from its route table, and the preferred route points at the adapter's primary address. A listening socket bound to one specific address no longer receives broadcasts, because they are addressed to the broadcast IP and not to it.
Put a second IPv4 on the same NIC and one wire now carries two subnets. The tool binds and listens on one address, the cameras live on the other, and any address the tool offers to connect to is a guess on the leftover subnet, where no device answers. Every packet is sent and received correctly; none of them meets. The cure is to make the adapter carry one address again — not to touch the camera.
Where the second address comes from
The most common source is an automation suite run in its direct-Ethernet connection mode. To reach a device whose fixed address sits outside your subnet, the tool appends a compatible address to the adapter, talks point-to-point, and leaves the entry behind when it closes. The next discovery scan inherits that leftover address. Static entries typed during an earlier rig on the same PC cause the same fault.
The pattern is not limited to cameras: a commissioning PC that talks to PLCs picks up the same double address, and fixing multiple IPv4 addresses on Windows for a PLC Ethernet connection walks through the identical repair from the controls side.
Worked example: a 192.168.23.0/24 vision LAN with a leftover 192.168.250.11
The inputs, with their origin:
- Primary IPv4 on the Ethernet adapter: 192.168.23.10, mask 255.255.255.0 — the address you set for the vision LAN.
- Secondary IPv4 on the same adapter: 192.168.250.11, mask 255.255.255.0 — appended by a direct-connection setup and left behind.
- Smart camera on the vision LAN: fixed address 192.168.23.55.
- Discovery traffic: GigE Vision control protocol on UDP port 3956.
The rule, in words: an interface's broadcast address is its own address ORed with the inverted mask, and a socket bound to one specific address accepts only packets addressed to that address.
The arithmetic lives in the last octet. On the primary address, 10 OR 255 = 255, so the vision LAN broadcasts at 192.168.23.255. On the leftover address, 11 OR 255 = 255, so the second stack broadcasts at 192.168.250.255. Two broadcast domains, one wire.
The camera hears a packet that reaches 192.168.23.255 and answers — but the tool's listener sits on 192.168.250.11, and a bound socket accepts only packets addressed to itself, so the reply is never delivered to it. The addresses the tool then offers to connect to sit on 192.168.250.x, where no camera exists. Meanwhile a unicast ping to 192.168.23.55 follows the normal route and succeeds. An empty list plus a passing ping is the signature of this fault.
The decision: keep exactly one IPv4 per physical NIC on the vision network. The moment ipconfig /all shows a second address under the adapter, delete it — the list refills on the next scan, no reboot needed. If the tool re-appends the address each time it runs, go to the stack reset below.
Likely causes, in the order to check them
An empty device list has five suspects. Work down the table; the top row is the one this page is about and the cheapest to test.
| Cause | Test in one step | Fix |
|---|---|---|
| Second IPv4 on the adapter |
ipconfig /all — count the IPv4 lines under each adapter |
Delete the extra address, or run the netsh reset below |
| Camera on a different subnet | Compare the camera's address with the NIC's, octet by octet | Align the subnets on the PC and the camera |
| Firewall swallowing the discovery port | Suspend the firewall rule for one scan | Allow the tool's discovery port inbound |
| Another tool holds the camera | Close every viewer and scanner app, then rescan | Release the exclusive session |
| Virtual adapter takes the broadcast | Disable VPN and virtual NICs for one scan | Raise the virtual adapter's interface metric |
The fix: remove the extra address or reset the IP stack
-
Record everything. Run
ipconfig /alland copy every IPv4 line under the adapter into a text file, masks and gateways included. - Delete the extra address first. Open the adapter's Internet Protocol Version 4 (TCP/IPv4) properties, then its advanced settings: the IP addresses list there carries every address bound to the NIC. Remove the entry you did not set, keep the primary, and confirm.
- Rescan without rebooting. Re-run the discovery tool. With the second address gone, the list normally fills on the first scan.
-
If the address keeps coming back, reset the stack. Open a Command Prompt as administrator and run
netsh winsock reset catalog, thennetsh int ip reset reset.log, then restart the PC. The reset rewrites the adapter's TCP/IP configuration, so type the primary address from step 1 back in before the next scan. -
Confirm one address.
ipconfig /allnow shows exactly one IPv4 line under the adapter. - Open the camera. The tool lists it with the address you set and opens a live image.
Checks before you call it fixed
-
ipconfig /allshows exactly one IPv4 address under each physical Ethernet adapter. - The discovery tool lists the camera with the address you set, for example 192.168.23.55 from the worked example.
- A unicast ping to that address still succeeds, proving cable and switch were never the problem.
- The tool opens the camera and a live image runs for a full minute without a stall.
- After the next session with any direct-connection automation tool, re-run
ipconfig /alland confirm the extra address did not return.
Prevention: one IPv4 per NIC on the vision network
- One subnet per NIC. Put the camera network on its own adapter and range — 192.168.23.0/24 with the cameras, plant and office traffic on another NIC. Two adapters must never share a subnet: that cousin fault ends in vision software hangs with two adapters on the same subnet.
- Prefer routed connection modes. When a commissioning tool and the discovery tool must coexist on one PC, set the commissioning tool's connection type to its routed or shared mode; direct-connection mode is the one that appends addresses.
-
Re-check after every install. A new automation tool earns one
ipconfig /alllook before the next production run. - Give the vision LAN enough ports. A multi-port vision controller keeps the camera subnet, the plant network and a service port apart; the MV-VC2140-128G40-1T lists 3-4 LAN ports.
Typical Ethernet-discovered gear on the camera side:
- Interface
- GigE
- Resolution
- 6-10 MP
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
And a controller that keeps each subnet on its own port:
- LAN ports
- 3-4 LAN ports
- USB 3 ports
- 2 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
If the camera side of a new station is still open, the camera finder filters smart cameras and code readers by interface and resolution in one pass.
When the usual answer is wrong
- A VPN or virtual adapter is active. Those create separate interfaces, not a second address on the same NIC, but a global broadcast can still prefer one of them when its route metric is lower. Disable the virtual adapter for one test, then set its interface metric higher in the adapter's IPv4 advanced settings.
- The camera holds a stale address, not the PC. After a network adapter or PC swap, the camera side is the one to reassign — camera IP assignment fails after a network adapter change walks that repair.
- The tool errors while applying settings. GigE configurator utilities that refuse changes with a rights message have their own fix: the admin-rights error in the GigE configurator tool.
- The list shows the camera but it will not open. That is exclusive control, not discovery: a camera that will not open because a second tool holds exclusive control.
- The extra address returns every session. One netsh reset loses to a tool that re-appends daily; switch that tool out of direct-connection mode, then reset once.
Once the list fills, freeze the working state: one address per NIC, the camera subnet written on the panel door, and ipconfig /all in the commissioning checklist. If the empty list survives all of it, send the adapter section of ipconfig /all and the tool's version through the contact page — that pair usually pins the cause in one reply. More PC-side networking fixes sit on the systems topic page.
Questions
Does a second IPv4 address break unicast traffic too?
Rarely at first. Unicast packets follow the route table straight to the camera's address, so a ping and even a live stream can keep running while discovery stays dead. It turns intermittent once a tool binds its data socket to the secondary address, because the camera has no route back to that subnet. Treat an empty discovery list as the early warning and fix it before streams start dropping.
Which UDP port does GigE Vision discovery use?
GigE Vision devices answer discovery on the GigE Vision Control Protocol, GVCP, at UDP port 3956: the application broadcasts one command there and every camera on the subnet replies with its MAC and current IP. A local firewall that swallows port 3956 traffic produces the same empty list as a double address, so after ipconfig /all, the firewall is the second thing to check.
Will netsh int ip reset erase my static IP settings?
Yes. The command rewrites the adapter's TCP/IP configuration, so static addresses, gateways and DNS entries are gone after the reboot. Copy every IPv4 line from ipconfig /all into a text file before you run the two netsh commands, restart, and type the primary address back in before the next scan. Run the reset on the vision PC only; other network software may need reinstallation after a winsock reset.
Why did an automation tool add an IP address without asking?
Direct-connection modes exist to reach a device whose fixed address sits outside your subnet. Instead of routing, the tool appends a compatible address to the NIC, talks point-to-point, and leaves the entry behind when it closes, so the next discovery scan inherits it. Choosing the tool's routed or shared connection mode, and checking ipconfig /all after each session, keeps the extra address from coming back.
Do USB3 Vision cameras fail discovery the same way?
No. USB3 Vision devices carry no IPv4 address at all, because the host enumerates them over the USB bus, so a second address on an Ethernet adapter cannot hide them. If a USB3 camera is missing from the device list, look at the USB controller, the cable run and port power instead; the broadcast fixes on this page do not apply.