GigE camera open fails in a second tool: exclusive control

Your GigE Vision camera shows up in discovery, its GenICam XML loads, and one tool streams it at full frame rate — but a second application reports "Failed to open camera" at its open call. This guide is for the integrator or controls engineer who has already checked cables and IP addresses. You will confirm from the numbers already in your capture log that the link is healthy, learn why the GigE Vision control channel allows only one client at a time, find which program holds the camera, release it in under a minute, and set the system up so the conflict does not come back.

The signature that means exclusive control

Start with the decision. If discovery lists the camera, the XML loads, and another tool is streaming it right now, then the IP addressing, the network card, the firewall on that path, the MTU and the packet size are all proven end to end. A network that carries one client's full video stream cannot be what stops a second client from opening the same camera.

What stops it is the GigE Vision access model: the specification allows one controlling client per camera and does not support two simultaneous control connections. The camera refuses the second client at the step where the SDK asks for control, which is why the failure lands on the open call — "Failed to open camera" from the camera_new or open_device step in a library such as Aravis — and never during discovery or the XML fetch. The fix is ownership, not networking.

The same fault wears a second face: your application runs all week, then refuses to open on Monday morning because a viewer left running over the weekend never let go.

Why the holder survives a crash

GVCP, the GigE Vision control protocol, rides on UDP port 3956. A client takes control privilege when it opens the camera and keeps it until a clean close releases it. Two properties follow from that, and both matter here.

First, there is no lease and no idle timeout: the specification defines nothing you can wait out. Second, UDP is connectionless, so the camera has no session through which to notice that the holder died. A viewer killed from the task manager, a terminal window closed on a running capture, or a host that lost power mid-session leaves the camera controlled by a ghost. Debug output shows the unclean stop: an aborted-buffer count — n_aborted in an Aravis stream summary — after Ctrl+C marks a session that bypassed the SDK's close path.

Rule the link out with three numbers

Spend one minute on the log you already captured before touching ownership. Three checks settle the network question for a camera that streams anywhere.

1. The packet-size check passed. Aravis prints the result of its automatic check — 1500 bytes in this session — and a pass means full-size packets cross the link in both directions.
2. The error counters sit at zero. In a stream summary, n_missing_packets, n_resend_requests and n_timeouts at zero across hundreds of buffers mean the link delivered everything without asking for a single resend.
3. The data rate fits the link with margin. The next section computes it from the same log.

When check 1 fails instead, the link is negotiating down or running below gigabit, and GigE Vision test packet not received: fix packet size negotiation is the next read, not this one.

Worked example: 1440 × 1080 mono at 60 fps on one gigabit link

The inputs, with their units and where each comes from:

• Payload: 1,555,200 bytes per frame, reported by the camera in its device information (1440 × 1080 pixels at one byte per pixel, mono).
• Frame rate: 60 fps, the value the stream statistics settle at.
• Packet size: 1500 bytes, from the automatic packet-size check in the same session.

The rule in words: video data rate equals payload times frame rate, and a gigabit link at 1500-byte packets carries about 952 Mbit/s of image data. Anything below roughly 900 Mbit/s leaves headroom for resends.

The arithmetic:

• 1,555,200 bytes/frame × 60 frames/s = 93,312,000 B/s ≈ 93.3 MB/s. The tool's rate display prints this as 93.3 MiB/s; the binary figure is 88.9 MiB/s, and the label does not change the verdict.
• 93,312,000 B/s × 8 bits = 746,496,000 bit/s ≈ 746 Mbit/s of image data.
• 746 / 952 = 78% of the ceiling, leaving 22% for resends, the packet delay and overhead.
• Cross-check: 1,555,200 / 1464 = 1063 data packets per frame — 1062 full packets plus a 432-byte remainder — or about 63,780 packets per second, matching the received-packet counters of a healthy session.

Decision: a camera that completed 179 buffers with zero missing packets at 78% of link capacity is being delivered perfectly. When that camera refuses a second client at open, the network is excluded; work the holder list below. If your own numbers land above about 900 Mbit/s with resends climbing, you have two faults — cut the payload or frame rate first, then come back to ownership.

Find the holder in order of likelihood

Work this list from the top and retry the failing open after each step. The step after which the open succeeds names your culprit.

1. Close every vision program on the host: the vendor's viewer, a configuration tool minimized to the tray, any earlier instance of your own application still attached to the session.
2. Check the owners that start themselves: services and daemons that attach to cameras at boot, containers with their own network stack, scheduled tasks. If the camera is held again right after a reboot, one of these is the holder.
3. Ask the subnet. Control is not bound to your machine — any host that can route to the camera can take it.
4. Read the access state. A tool that does open the camera usually displays its control status, and a read-only indication there means another client owns it. The same access state explains nodes that exist but refuse to write; see GenICam node not writable: check camera access state.

The hunt is the same discipline as reclaiming a frame grabber from a phantom process; Frame grabber in use: find the owner and release access works that variant.

Release control when the holder will not let go

An alive holder releases control through its own exit: close the viewer or stop the service properly, and the camera is free the moment the close command lands.

A dead or unreachable holder needs a power cycle, because control resets to open only at power-up. Pull the PoE connection or the camera's power input for about ten seconds, let the camera re-enumerate on its persistent IP, and run your open again. One walk to the camera covers the power pull and a spare-cable swap, so keep a 3 m high-flex drag-chain GigE cable such as the LS-CBL-0199 on the bench:

Bench stock for this fault is one known-good lead; the camera cables category lists the GigE lengths and connector types.

Checklist: one owner per camera

• One controlling application per camera, by design. Everyone else consumes a copy of the image the owner publishes; nobody else opens the device.
• Release on every exit path. Put the SDK's close call in a finally block and handle interrupts, so a Ctrl+C cannot end a session with control still held.
• Keep the vendor viewer shut during production. Open it for maintenance with the line stopped, and close it before the line restarts.
• Give the vision system its own network card and subnet, so only the intended host can reach the camera. That also prevents discovery contention in multi-camera systems; see Camera discovery startup contention in multi-camera systems.
• Set the packet size before acquisition in every client you write; Set GigE camera packet size before starting acquisition shows the ordering that keeps a session clean.
• Power-cycle the camera after any vision-client crash, before you debug anything else.
• Expect the same single-owner behavior on USB3, enforced by the host controller's interface claim; Two cameras interface claim conflict: diagnose USB access works that case.

The rule holds across the GigE area scan cameras range, from a 12 MP GigE model like the LS-CMR-0053 upward:

When the signature is different

Everything above assumes the camera streams in at least one tool. When it opens nowhere, the fault sits earlier in the chain, and the symptom picks the fix:

The decision by case: streams in one tool, open fails in another — close or power-cycle the holder, then open. Opens nowhere and discovery is empty — firewall first. Opens nowhere but discovery lists it — packet size, then IP configuration. Opens but nodes refuse to write — access state, as above. For the next station, the system configurator walks camera, cable and host choices in order, and the contact page puts the odd cases in front of our applications team.