Two identical GigE cameras on one PC: fix duplicate names and IPs

Two identical GigE cameras, one PC, and the software talks to only one of them: discovery lists both, but opening the second fails with a connection error. This is a duplicate-identity fault, and it follows the cameras, not the PC. Same-model cameras leave the factory with the same user-defined device name and the same addressing defaults, so an application that binds cameras by name or by index cannot tell them apart. This guide gives the fault tree in order of probability, a test for each cause, a seven-step fix, an addressing plan that lets two identical cameras coexist, and the bandwidth arithmetic that decides whether one network card can carry both streams at your frame rate.

Symptom: discovery finds both cameras, only one connects

The signature is specific. A browser or configuration tool sees both cameras, each with an IP address, each on its own ethernet card. Your application opens one camera fine and throws an unable-to-connect style GenICam error on the second. Sometimes the application lists a single device; sometimes it lists the same device name twice. Both flavours point at identity rather than cabling: the cameras are on the wire and answering discovery, but the software has no way to say which camera it means.

Link lights are on and pings to one address work, which is exactly why this fault wastes an afternoon: everything looks connected because it is. What is missing is a unique identity per camera, and that is a short write in the vendor's configuration tool.

This behaviour comes from the cameras' factory defaults, not from any one brand: any two same-model GigE cameras collide the same way. The two GigE area scan cameras below are set up through exactly this procedure.

The four causes, most likely first

1. Identical device names. Same-model cameras ship with the same user-defined device name in non-volatile memory. Applications that enumerate by that name see one camera, or bind the first unit that answers and refuse the second. Test: rename one camera; if the software suddenly lists two, you are done.

2. Duplicate IP addresses. A configuration cloned from one camera to the other, or the same persistent address typed twice, puts two nodes on one IP. Test: unplug camera B and ping the shared address; if it still answers, camera A is holding it. A camera that lost the address cannot be opened, whatever the discovery list shows.

3. Subnet mismatch. Each camera must share a subnet with the network card that serves it: with a 255.255.255.0 mask, the first three octets of camera and NIC must match. The mirror mistake matters too - two host adapters on the same subnet make some discovery stacks hang, which the vision software hang with two adapters on one subnet article covers in detail.

4. A busy control connection. GigE Vision allows one control connection per camera. A browser tool left open holds camera B's connection, so your application gets the connect error until the tool closes and the camera's heartbeat times out, which takes a few seconds.

Fix it in seven steps

1. Connect camera A alone: one camera, one cable, one card, no ambiguity about which unit you are writing to.
2. Open the camera vendor's configuration tool - the GenICam browser or force-IP utility that ships with the camera's SDK.
3. Write a unique user-defined device name, cam-left for example, and save it.
4. Set a persistent IP address and subnet mask, 192.168.1.10 with 255.255.255.0 for example, and switch DHCP off when this card is dedicated to cameras. Store the values as persistent, not just for this session.
5. Swap the cable and repeat on camera B: cam-right, 192.168.1.11, same mask.
6. Configure the host card or cards to match - the addressing plan below.
7. Reconnect both cameras and power up: discovery should now show two distinct names and the two addresses you chose. In the application, open cameras by name or by address, never as the first device found.

If a camera is already unreachable because of a duplicate address, use the tool's force-IP function: it broadcasts a temporary address to the camera over the existing link so you can reach it once, then store the persistent values.

An addressing plan that works

These are example addresses on a private range; any consistent plan works while three rules hold. Every camera has an address no other node uses. Every camera shares a subnet with the card that talks to it. Two host cards never share a subnet with each other: in the two-card layout, NIC 1 at 192.168.1.1 serves cam-left at 192.168.1.10, while NIC 2 at 192.168.2.1 serves cam-right at 192.168.2.10.

The serial number and MAC address on each camera's label are the only identifiers the factory makes unique. Record serial, name, IP and mounting position in one table and keep it with the line documentation, so the name and address follow the position rather than the hardware.

Check the wire before you blame identity

Unique names and addresses are necessary but not sufficient: both streams must also fit the link. A gigabit ethernet link runs at 1,000 Mbit/s and delivers roughly 940-990 Mbit/s of application payload once ethernet, IP and UDP overhead are paid; jumbo frames recover most of that overhead and sit at the top of the range.

Worked example, one 6 MP camera streaming 3072 × 2048 monochrome 8-bit at 15 fps:

• 3072 × 2048 = 6,291,456 pixels, which is 6.29 MB per frame at 1 byte per pixel
• 6.29 MB × 15 fps = 94.4 MB/s
• 94.4 MB/s × 8 = 755 Mbit/s of payload, about 790-830 Mbit/s on the wire with per-packet overhead

Two such cameras need about 1.6 Gbit/s, so they do not fit through one gigabit card: give each camera its own NIC, or slow the frame rate down. At 8 fps each camera moves 6.29 × 8 = 50.3 MB/s, which is 403 Mbit/s of payload; both together draw about 805 Mbit/s, roughly 845-890 Mbit/s on the wire - inside one link's budget, and easiest to hold there with jumbo packets.

Set the packet size before acquisition starts: set the GigE packet size before starting acquisition shows the ordering, and packet-size errors when the link drops below gigabit is the classic downstream symptom. Frame drops that appear only when the second camera streams are a bandwidth answer, not an identity one; the multi-camera frame-drop checklist covers that side, and the NIC ports and bandwidth budget for two GigE cameras on one host works this arithmetic in full.

One card with a switch, or one card per camera

With a switch, every node sits in one subnet and the card reaches both cameras by their unique addresses. With two cards, separate subnets isolate each pair and keep discovery quiet.

On an embedded RTOS target, multi-NIC discovery is its own exercise: the GigE Vision RTOS port with multi-NIC discovery covers that side.

When the fix does not take

If names are unique, addresses are unique, subnets are right, and camera B still refuses to open, work down this list:

• Discovery lists a camera twice, or on the wrong adapter: mirrored or bridged interfaces confuse enumeration, and the duplicate camera discovery host-interface diagnosis walks the checks.
• The camera is not discovered at all: go back to the subnet and compliance checks for an undetected GigE camera. A firewall that blocks the UDP broadcasts, or a host NIC without a link-local 169.254.x.x address when the cameras fall back to auto-addressing, explains most of these.
• Frames blank out after acquisition starts: that is packet loss, not connection failure, and diagnosing blank frames from GigE stream packet loss is the read.
• The test packet fails after the link renegotiates: fixing test-packet-not-received through packet-size negotiation.
• Buffer timeouts and blank frames on embedded Linux: socket buffer tuning for GigE camera buffer timeouts.

Lock it in

• One camera, one unique user-defined name, stored in non-volatile memory.
• One camera, one persistent IP, and DHCP off on dedicated camera cards so no stray server re-addresses a camera mid-shift.
• An addressing table with serial, MAC, name, IP and position, taped inside the cabinet and kept in the line documentation.
• The application opens cameras by name or address, never by enumeration index: port order and power-on order are not stable.
• Cables labelled A and B at both ends.
• After a camera swap, give the replacement the failed unit's name and address so the recipe follows the position, not the part.
• If the pair is USB rather than GigE, the same identity problem returns as port IDs; the USB port ID fix for multi-camera identification is the equivalent read.

The decision in one line: unique name, unique persistent IP, one subnet per NIC-camera pair, open by name - and two identical cameras behave like two different ones.

Need the hardware for a two-camera station? Browse the GigE area scan cameras, filter the camera finder by interface and resolution, or start at the camera step of the configurator. More host-side and stream-side fixes sit on the systems topic page.