Vision software hang: two adapters on the same subnet

Your vision software lists the camera, you click connect, and the window stops responding. Close it, relaunch, same result. On a PC with two network adapters — the wired card cabled to the camera plus Wi-Fi for the office — the usual cause is both adapters sitting on one subnet: Windows holds two equal routes to the camera, sends the connect request out the wrong one, and waits for an answer that cannot arrive. The camera is fine. This guide follows the fault in the order you meet it: the mechanism, the ipconfig check, which adapter to re-IP, the settings to type, the other causes that hang a connect, and the subnet plan that keeps the cell clean. The addresses here — 192.168.10.10, 255.255.255.0 and the rest — are one worked example sized for a single camera link; swap in your site's plan.

Why does the vision software hang when connecting to the camera?

Two adapters on one subnet leave Windows with two equal routes to the camera, so the connect request leaves the wrong adapter, the camera never hears it, and the tool blocks on a reply that never comes.

The signature is misleading: the same tool on the same camera ran fine last week, and nothing in the vision project changed. What changed is the network. A wireless adapter on DHCP picked up an address inside the camera's range at lease renewal, and the overlap appeared with it. To the operator the failure looks like a camera fault; it is a host routing fault. Any camera shows it the same way — a GigE smart camera behaves no differently from a GigE area scan camera, because in both cases the packets never reach the camera.

The hang usually lands on the connect step rather than on streaming. Discovery broadcasts go out on every interface, so the camera still shows up in the device list — and dies the moment the tool opens a connection to it. Listed but frozen on connect is the fingerprint of this overlap.

What does Windows do when two adapters share one subnet?

Windows gives the subnet's route to the adapter holding the highest numeric IP address, so a Wi-Fi address handed out an hour ago can beat the wired card that is actually cabled to the camera.

That tie-break is documented Windows behaviour for two adapters on one network, not a bug in the vision tool. Follow the packets: the software wants the camera at 192.168.10.100. Windows holds two routes to 192.168.10.0 and picks the higher address, the Wi-Fi side at 192.168.10.47. The request that resolves the camera's MAC address goes onto the office wireless, where no camera exists. The camera, sitting on the switch behind the wired card, hears nothing and answers nothing. A connect call built on that exchange waits indefinitely, and a window that waits indefinitely reports Not Responding.

GigE Vision practice states the rule plainly: every adapter — and every port of a multi-port card — gets its own address on its own subnet. Larger plants learn the same lesson with recorders and cameras spread across buildings, where two gateways sharing one subnet create the same ambiguous routing.

How do you check the adapter subnets with ipconfig?

Run ipconfig from a command prompt and compare the IPv4 address and subnet mask of every adapter: when two adapters produce the same network value after the mask is applied, that overlap is your hang.

Apply the mask to each address and compare the results:

The AND runs octet by octet: 10 AND 255 stays 10, and the zero octet in the mask wipes the last number, so both adapters collapse onto 192.168.10.0. That single comparison — two adapters, one network — is the whole diagnosis. Read every adapter in the list, including virtual ones; a virtual host adapter counts exactly like a physical card. The goal state is one network per adapter: the wired NIC on 192.168.10.0, the Wi-Fi on 192.168.20.0 — a different third octet, a different /24, one route.

Which adapter should you re-IP, and to what address?

Re-IP the side you control end to end: put the camera NIC static on a reserved third octet — 192.168.10.10 with mask 255.255.255.0 — and leave the office or wireless side on a different octet.

If you administer the office router, move wireless users to 192.168.20.x and keep 192.168.10.x for imaging. If the router belongs to someone else, pick a third octet the office plan will never use and put the camera link there: with the office on 192.168.1.x, the camera NIC takes 192.168.10.10 and the camera 192.168.10.100. Imaging then sits wholly on 192.168.10.0 while the office stays on 192.168.1.0 — no shared network, no ambiguous route.

Two rules hold the plan together: the camera's address lives inside its NIC's subnet and nowhere else, and every adapter in the machine lands on a different network value. Write the plan on a label inside the cabinet door; the next integrator inherits it instead of rediscovering it.

How do you set the camera adapter to its own subnet?

Open the camera adapter's TCP/IP v4 properties, type a static address and mask, apply, re-run ipconfig to confirm one network per adapter, then reconnect — the fix takes about five minutes and no reinstall.

1. Open the Windows network connection list, right-click the adapter cabled to the camera switch, and open its TCP/IP v4 properties.
2. Choose the manual addressing option and type address 192.168.10.10 with subnet mask 255.255.255.0. Leave the default gateway empty.
3. Set the camera itself to 192.168.10.100 from its configuration tool, so it sits inside the NIC's subnet.
4. Apply, run ipconfig again, and confirm the wired NIC shows 192.168.10.0 while every other adapter shows a different network.
5. Close and reopen the vision software, connect, and let the cell run for ten minutes to catch any lease-driven change on the remaining DHCP side.

What else hangs a connect when the subnets are unique?

With one subnet per adapter confirmed, work the remaining causes in order of likelihood: the host firewall filtering the camera traffic, another tool still holding the link, a stale camera address after an adapter change, and the switch path itself.

• A firewall that passes ping but blocks the vision traffic produces a near-identical freeze. The GigE Vision camera firewall: ping works, discovery fails walkthrough isolates it quickly.
• Two instances of a configurator, or an SDK that subscribes and never releases, leave nothing for your application. See connect a camera only when subscribed to free the GigE link.
• A new or swapped card reorders addressing and can strand the camera on a stale address. Camera IP assignment fails after a network adapter change covers the recovery.
• Several cameras on one machine mix addressing faults with bandwidth faults. Network camera discovery troubleshooting for multiple cameras separates them, and vision camera network connection troubleshooting gives the wider checklist.
• Field reports also describe unmanaged switch ports locking up under sustained multi-camera streams; power-cycling the switch restores them, and moving heavy streams onto a switch sized for them stops a return.

A GigE area scan camera on a separated link connects immediately, so a long wait with clean subnets points at the path or the host, never at the camera. The vision systems hub collects the rest of these host-side faults.

How do you keep the subnets unique for good?

Write the subnet plan down, keep the imaging link static and gateway-free, and re-run ipconfig after every wireless, docking-station or DHCP change — the overlap then cannot come back unnoticed.

• One third octet per camera link, written on the cabinet label — the plan survives personnel changes.
• Static address on every camera NIC; DHCP only on the office side — removes the lease lottery.
• No default gateway on imaging adapters — one way out of the cell, no ambiguity.
• ipconfig after any adapter, dock or wireless change — thirty seconds that catches the overlap before the operator does.
• Wireless disabled during imaging where the cell has no other use for it — the fallback that always works.
• A smart camera that drops after days of running is a different fault with its own recovery path, not this hang.

Which fix fits your set-up?

Match your machine to the table and apply that row: Wi-Fi plus wired needs a new third octet on the wireless side, two wired cards need a static camera NIC, and multi-port cards need one subnet per port.

If you are specifying the cell rather than repairing it, plan the subnets with the parts: smart cameras and area scan cameras each hang the same way behind an overlapping NIC, and the camera finder prints the interface per model so every link gets its own subnet before the hardware arrives. Cells larger than one PC are worth a plan review — contact the applications team, and free expert support comes with every order. When a connect hangs, run ipconfig first: ninety seconds there beats an afternoon of reinstalls.