Smart camera not connecting: fix IP and subnet mismatches

You press Connect, the dialog opens, the progress bar sits there and nothing happens. Or the camera appears in the device list but greyed out, unselectable — and the next morning it is gone from the list completely. Both symptoms nearly always live in the network layer, not in the vision software: the camera's IP address and the host adapter sit in different subnets, the address changed over the weekend, or another application already holds the camera's control session. Reinstalling the software fixes none of these. The sequence below separates the three failing layers — link, address and control — gives a quick test for each, and ends with an address plan that keeps a station connecting on the first try, on smart cameras and GigE vision sensors alike.

Which layer is failing

A connection attempt passes through three layers, and each fails with its own pattern:

• Link — cable, connector, switch port, speed negotiation. Pattern: no link LEDs, or the camera missing from discovery entirely.
• Address — IP address and subnet mask. Pattern: the camera was listed yesterday or still is, but the connect attempt stalls and the camera answers nothing at its old address.
• Control — the session lock. Pattern: the camera lists normally and answers ping, but the software refuses it or shows it busy.

Discovery and control are separate conversations. Vision software finds cameras by sending a UDP broadcast on the control protocol (GigE Vision for GigE and Fast Ethernet devices alike), and the camera replies with its current address even when the PC could never open a control session to it. That is why a tool can list a camera greyed out: the entry is information, not a fault — the camera is alive but unreachable at the address or control layer.

Likely causes in order of probability

Work down the list and stop when a test clears a cause:

1. Host adapter and camera in different subnets — the most common cause by a wide margin, and one PC setting to fix.
2. The camera's address moved — a DHCP lease followed the server to another subnet, or the camera lost settings and fell back to a link-local 169.254.x.x address. This is the worked-Friday, gone-Monday pattern.
3. Two host adapters on the same subnet — packets route down the wrong interface; discovery works but sessions hang.
4. Another application holds the control session — GigE Vision grants one controlling client per camera; a second attempt is refused or greys the entry out.
5. A strict firewall profile — discovery arrives but the control channel is dropped, so every connect stalls at the same point.
6. Speed negotiation — a switch port forced to 1 Gbit/s full duplex never links a Fast Ethernet camera; forced duplex on a linked port stalls sessions.
7. Marginal cable or connector — link flaps, intermittent discovery, a camera that drops off the list during the day.

Vision sensors usually carry Fast Ethernet interfaces, which negotiate 100 Mbit/s and run fine on gigabit switch ports as long as both ends stay on auto-negotiation. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor on Fast Ethernet, and the HK-TD032-12-WBN a 1.6 MP mono sensor on the same interface.

Smart cameras built on GigE need a switch port that links at 1 Gbit/s. The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with a GigE interface and an M12-mount lens.

Worked example: a camera at 192.168.1.10 and a host adapter at 192.168.10.20

Inputs: the camera holds a static 192.168.1.10 with mask 255.255.255.0, the factory-default style setting most vision sensors ship with; the PC adapter holds 192.168.10.20, mask 255.255.255.0, left over from another line. Discovery still lists the camera; the connect dialog never finishes.

The rule: two devices on the same cable talk directly only when their network addresses match, and the network address is the IP address ANDed with the mask, octet by octet.

With a 255.255.255.0 mask, only the first three octets count. Octets one and two agree: 168 AND 255 = 168 on both sides. The third octets disagree — the camera's 1 and the host's 10 each AND with 255 to give 1 and 10 — so the network addresses come out 192.168.1.0 against 192.168.10.0. Different networks: the host hands the camera's packets to its default gateway instead of putting them on the local link, ping times out, and the connect dialog stalls indefinitely.

The fix: set the host adapter to 192.168.1.20 with mask 255.255.255.0. Both sides then compute the network address 192.168.1.0, and ping to 192.168.1.10 replies in well under a millisecond.

The same /24 holds 254 usable addresses, .1 through .254; .0 and .255 are reserved as network and broadcast. Plan cameras at .10, host adapters at .20, and leave .1 for the switch. Decision rule: with a 255.255.255.0 mask, camera and host must share the first three octets — for a second camera subnet, add a second adapter instead of widening the mask.

Five checks in order

1. Read both addresses. The discovery list gives you every address you need, so write down the camera's address and mask and the host adapter's address and mask before touching anything. How to get them when the list stays empty is covered in the FAQ below.
2. Compare, then ping. Apply the AND rule from the worked example. If the networks match, ping the camera with ping 192.168.1.10; a reply confirms the address layer and moves the fault to control. If they differ, fix the address first — no ping test needed. A timeout on a matching subnet is not yet a verdict: the PC's firewall can drop the echo request, so relax that network profile's rules and test again before condemning the camera.
3. Check the link. Look at the RJ45 LEDs on camera and switch port, and read the negotiated speed from the switch. Both ends belong on auto-negotiation: a Fast Ethernet camera linking at 100 Mbit/s on a gigabit switch is correct, while a port forced to 1000 full against it shows no link at all.
4. Check for a second client. Close every other vision application, configuration page and utility on any adapter, then retry; power-cycle the camera if a crashed client left the session lock stuck.
5. Swap the cable. Link flaps and intermittent discovery point at the cable or connector, and one known-good patch cable settles that question.

Worked in order, the sequence clears one layer per step and takes about ten minutes on a bench.

The fix for each cause

Different subnets. Move the host adapter into the camera's subnet, or move the camera into the plant's. The camera side runs through the vendor's IP configuration utility — the same workflow as changing a camera IP address when the update tool sticks on the default: change one address, re-discover, connect, then write it down.

Address moved. Reserve the camera's address in the DHCP server or set a static one outside the pool. Static settings carry one trap: some firmware updates refuse to run against a static camera — the situation behind why DHCP blocks a static IP for a firmware update — so record which mode each station uses. A camera showing a 169.254.x.x address fell back to link-local; give that adapter an address in 169.254.0.0/16, or follow opening a GigE camera on a link-local address from Linux.

Two adapters on one subnet. Give each adapter its own subnet and cable each camera line to its own; the discovery-works-sessions-hang signature is worked through in the vision software hang caused by two adapters on one subnet.

Duplicate addresses. Two devices answering one address drop off the list alternately; check whether a second host interface claims the camera's address, following diagnosing duplicate camera discovery across host interfaces.

Control lock. Close the second client. The session releases shortly after the holding application stops, and a power-cycle forces it.

Firewall. If the camera pings and lists but every connect stalls at the same point, allow the vision application through the firewall for the camera adapter's network profile and retry.

Cabling. Set both link partners to auto-negotiation and replace any unseated connector. For a cabinet run, a locking RJ45 camera data cable such as the 15 m LS-CBL-0117 keeps the plug seated through vibration.

When it is not the network

If no entry appears at all — nothing on any adapter, on a known-good cable, with the camera powered — the fault sits below IP: the packet filter the vision software listens through, the interface binding, or software that does not support the camera family. Work through the missing driver layer behind a camera the software cannot find, and check the software build against smart camera software compatibility before reinstalling anything. Reinstalling the application changes no camera address, no mask and no session lock, so it rarely repairs a stalled connect.

One boundary to keep in mind: once the connection holds but frames arrive broken or the stream stalls mid-run, the diagnosis moves to acquisition settings and bandwidth — recovering an out-of-sync camera image stream picks that up.

Prevention: an address plan that survives the weekend

• Fix the addresses. Static outside the DHCP pool or DHCP reservations, labeled on the camera and the patch panel.
• One subnet per adapter. Camera traffic on its own adapter or VLAN, separate from office and PLC networks; the switch-port and bandwidth side of that split is laid out in GigE camera network planning: switch ports and bandwidth. The same arithmetic governs PLC and HMI networks on shared plant switches — a controls-side walkthrough of resolving IP subnet mismatches in plant networks applies it device for device.
• Record the mode. Note which stations run static and which run DHCP, because firmware updates behave differently between them.
• Watch the link. A scheduled ping or a switch link-state alarm turns Monday's surprise into an e-mail; the recovery side of a failure that surfaces after days of running is covered in smart camera network failure recovery after days running.

For a new station, match interface and cabling from the start with the camera configurator, or browse the camera finder and the camera and power cables. The systems articles collect the rest of the network playbook.