Camera static IP setup: reach a smart camera on the same subnet

A smart camera that will not answer is almost never a camera fault. The path from a PC to a network camera comes down to three checks: both devices hold addresses inside one subnet, the PC can ping the camera, and the camera's image service is up. Set them up in that order and the first image appears in minutes; skip one and you chase ghosts for an afternoon. This guide takes the bench case from bare cable to first image: fixed addresses on camera and PC, the subnet arithmetic that proves the pair matches, the ping test and its expected output, then the image request and the four failures that stop most first connections.

Fixed addresses on one subnet: the decision

Give the camera and the PC fixed addresses on a single /24 and stop negotiating. A fixed camera address survives power cycles, a fixed PC address does not quietly follow a Wi-Fi network somewhere else, and neither device waits for a lease before it answers. Use the mask 255.255.255.0: the network is then 192.168.1.0, addresses .1 through .254 are usable, .0 names the network itself and .255 is the broadcast. Put the camera at 192.168.1.10 and the PC at 192.168.1.100. Any free addresses inside the mask work, because only the mask decides reachability — the worked example below does that arithmetic. Leave the default gateway empty on a direct cable: there is no router to point at, and an empty gateway stops the PC from sending camera traffic off to the office network.

Every Ethernet part in smart cameras and vision sensors follows the same checks; GigE parts and Fast Ethernet parts differ only in link speed:

When a camera still refuses to connect after this plan looks right, the address and subnet mismatch list in Smart camera not connecting: fix IP and subnet mismatches clears most of the remaining causes.

What you need

• A PC with a spare Ethernet port; a USB-to-Ethernet adapter is fine on the bench.
• One Cat5e or better Ethernet cable, long enough for the run.
• The camera, powered, with its configuration tool installed on the PC.
• A small unmanaged switch when a third device — a PLC, a controller — shares the link.
• Fifteen minutes.

Where the cable moves with an axis, use a drag-chain-rated lead from the camera data cables; on a long fixed run, a locking connector holds the link through vibration:

Nothing in the address plan depends on which cable you pick. For a camera riding a robot wrist, the network half is identical and the motion half is covered in GigE camera on a robot wrist: network setup and image retrieval.

Set the addresses on both ends

1. Plan the pair. Camera 192.168.1.10, PC 192.168.1.100, mask 255.255.255.0 on both. Avoid .0 and .255, avoid any address another cell already uses, and write the plan down — a plan in the cabinet drawer beats a plan in someone's head.
2. Set the PC first. Open the wired adapter's IPv4 properties, choose fixed addressing, and enter the address, the mask 255.255.255.0 and no gateway. Run ipconfig afterwards and confirm the wired adapter shows 192.168.1.100.
3. Set the camera. Connect it, start its configuration tool, and change its address to 192.168.1.10 with the same mask; apply, and power-cycle if the tool asks. Vision sensors keep this setting inside their setup software in the same way — look for the network or address settings, not the image settings.

Worked example: camera at 192.168.1.10, PC at 192.168.1.100, mask 255.255.255.0

The inputs come from the bench plan above: camera address 192.168.1.10, PC address 192.168.1.100, mask 255.255.255.0 on both. The rule is the one IP delivery itself applies: a device sends a packet straight onto the wire when the destination address ANDed with the mask equals its own address ANDed with the mask; anything else goes to a gateway, and with no gateway set, nowhere. A /24 mask leaves 2^8 - 2 = 254 usable addresses.

The AND works octet by octet: 255 passes an octet through unchanged, 0 zeroes it.

camera: 192.168.1.10  AND 255.255.255.0
      = (192 AND 255).(168 AND 255).(1 AND 255).(10 AND 0)
      = 192.168.1.0

PC:     192.168.1.100 AND 255.255.255.0
      = (192 AND 255).(168 AND 255).(1 AND 255).(100 AND 0)
      = 192.168.1.0

Both sides AND to 192.168.1.0: same subnet, direct delivery, no router involved. On a direct cable the ping replies typically come back in under 1 ms; through a switch, expect 0–2 ms.

The decision follows from the threshold: equal ANDed networks means talk directly, gateway blank; unequal means no direct path exists. Change the PC to 192.168.0.100 and its AND gives 192.168.0.0 against the camera's 192.168.1.0 — a one-octet mismatch, and the PC answers a ping attempt with 'Destination host unreachable' because it refuses to send without a gateway. Fix it by matching the third octet, not by hunting a camera fault.

Ping first, then ask for the image

4. Ping before anything else. From a command line: ping 192.168.1.10. Expect four replies in the shape Reply from 192.168.1.10: bytes=32 time<1ms and a 0% loss summary. That single reply is the whole network proof: cable, addresses, mask and switch all pass.
5. Ask for the image. Point the browser at the camera address. Many smart cameras run a small web interface on the HTTP port, so http://192.168.1.10 shows a status or live page; models with a snapshot service expose a deeper URL in the shape of http://192.168.1.10:8080/snapshot.jpg, with the exact port and file name coming from that model's interface documentation. If the ping replies arrive but the browser finds nothing, the network is not your problem — that camera is simply not running an HTTP service, and the image lives behind its client software or SDK. A failed URL proves nothing about the wire.
6. Wire the image into your tooling. Pull frames by URL when the camera offers one; the request-and-parse pattern is in Grab images from an IP camera over an HTTP snapshot URL. Otherwise drive the camera through its SDK. From there the usual next step is results over TCP to the PLC, covered in Smart camera to PLC over TCP: trigger and pass/fail.

The four failures, in order

1. The PC never got a fixed address. The camera sits at 192.168.1.10 while the PC still holds a DHCP lease on another network — 10.x.x.x or 172.x.x.x — so the ping dies. Run ipconfig, read the wired adapter's address and mask, and set the fixed pair from the plan. This is the most common miss on a first bench setup.
2. The corporate network isolates you. Both devices connect and even receive addresses, but the office switch or Wi-Fi blocks traffic between client ports, or splits the floor into VLANs. Cable fine, camera fine, path missing. Put the cell on its own small switch, or ask IT for a machine VLAN — then the plan above applies unchanged.
3. Someone else already owns the address. A fixed 192.168.1.10 that answers intermittently, or whose web page belongs to another device, means a conflict. Unplug the camera and ping 192.168.1.10 again: a reply proves another device holds it, so pick a different address. The symptoms and the web-page telltale are in Camera IP conflict: ping works but the web page is wrong.
4. A firewall or a stopped service. A PC network profile set to 'Public' silently drops ping replies, and a camera whose acquisition application is not running accepts pings while serving no image. Set the wired network's profile to private, and start the camera application before blaming the link. The discovery-side version — ping works, discovery fails — is in GigE Vision camera firewall: ping works, discovery fails, and the image-side version is in Timeout waiting for image buffer: ping works, no pixel data.

When DHCP with a reservation beats fixed addresses

On a managed plant network, inventing fixed addresses is how you collide with devices you cannot see; there, let the DHCP server assign and reserve. Reserve the camera's MAC address to one address inside the PC's own subnet, note the reservation in the cell file, and the camera keeps its identity through reboots and swaps. The bench rule still holds — one subnet — because discovery protocols announce cameras by subnet broadcast, and a broadcast stops at the subnet border even when routing between subnets works. That behaviour also trips GenICam discovery uses subnet broadcast: why ping is not enough, and it is the same reason UDP broadcasts on a Linux secondary subnet only reach the gateway.

When a deliberate split is unavoidable, crossing it becomes router configuration — the same job as reaching a PLC on a different subnet from an HMI — and pulling cameras across such a split is covered in Access GigE cameras from another subnet without direct cabling.

Checks before the line goes live

• Ping 30 times, demand zero loss — ping -n 30 192.168.1.10 on Windows, ping -c 30 on Linux. A cable that drops one reply in thirty will drop it mid-shift.
• Power-cycle both ends and ping again. Fixed addresses must survive a reboot; if the PC comes back on DHCP, the setting did not stick.
• Load the image with every other adapter disabled. Wi-Fi off, VPN off. If the image still arrives, the wired path owns it, not a leftover route.
• Record the plan where the cell lives: camera address, PC address, mask, and the MAC of the camera's port. The MAC is what a future DHCP reservation needs; the addresses are what the next engineer pings first.
• Repeat the ping under motion once the camera is mounted. A drag-chain cable that passes static and fails while moving gets caught now, not at sign-off.

Set the addresses, pass the ping, request the image — that order turns an invisible camera into a working one in one session. Pick the hardware in the camera finder or straight in the camera configurator; the rest of the network fixes sit on the systems topic page. If the cell must live on a network you do not control, bring the address plan to the contact page before you order.