GigE camera connection drops when a monitoring tool is connected

Your camera runs clean for weeks. Then the day you attach the robot programming environment's integrated vision view to debug a vision job, connection errors start appearing several times a day — and they vanish the moment the tool closes. Nothing about the camera, the cable or the switch changed; only the number of clients did. That pattern is not a coincidence and not a hardware fault: a GigE Vision camera is designed to be owned by one controlling application at a time, and a monitoring tool is a second application.

This guide is for integrators and robot-cell developers who need both a running vision process and a way to watch it. You will learn why the second client destabilises the link, how to confirm the mechanism with NIC counters and a packet capture, and how to structure development sessions so monitoring never competes with the stream.

Why does the camera drop only when the monitoring tool is connected?

GigE Vision gives one application control of the camera at a time: your robot's vision process owns the camera in production, and when the monitoring tool's integrated vision view attaches as a second client it competes for that control until the stream errors out.

In production, the vision process opens the camera, takes control and streams. When the development tool's live view attaches, it asks the same camera for access. Depending on the device and library, that request is refused, granted read-only, or accepted in a way that pulls control away from the running process. Each hand-off or refused attempt can stall the control channel long enough for the stream to time out, which the vision process reports as a dropped camera.

On one robot platform this surfaces as connection error 41784 in the integrated vision log, several times a day during development weeks and never in production weeks. The variable that changed is the second client, not the camera.

The benches that produce this look ordinary: a GigE camera such as the MV-CU020-90GC — a 2.5 MP model with a 1/1.7-inch global-shutter sensor and a C-mount — wired through a switch to the controller that runs the vision process.

For the controller side of the same story, this GigE Vision camera connection troubleshooting guide for robot controllers covers the checks that pair with this one.

Does GigE Vision allow only one client per camera?

The GigE Vision specification hands control of a device to a single primary application; a second connection is, at best, a monitor with reduced privileges, and many cameras do not implement secondary connections at all.

Two consequences follow. Opening a GigE Vision device is not a passive act: the second tool joins the control protocol, and there is one seat at that table. Monitor support is optional — the device reports during discovery whether it accepts secondary applications, and plenty of industrial cameras do not.

When the vision process and the monitoring tool both call the camera, one of three things happens: the second open fails cleanly, the second client gets monitor-only access, or the camera swaps ownership mid-session. The first case is annoying but harmless, and it is the subject of access a camera parameter tree over TCP from a second app, which shows how a second tool can read a camera's tree without stealing the stream. The third case is what produces intermittent mid-session drops instead of a clear error at open time. The same one-client rule sits behind the related failure where a camera works in the vendor tool but not in ROS; there the clash shows at open, here it shows hours into a session.

Why does a second client cause mid-session drops instead of a clean refusal?

Two things go wrong when the second client stays attached: it can pull the control channel out from under the primary application mid-stream, and a second live view can double the frame traffic on a link sized for one stream.

Three mechanisms cover nearly every case, in order of how often they turn up:

1. Control contention. The monitoring tool refreshes its live view, re-enumerates devices or re-opens its session, and each of those touches the control channel the vision process depends on. Control messages stall, the stream times out, and the vision process reports a dropped camera.
2. A second stream on a shared link. When the second client is granted streaming privileges, its pixels ride the same physical link as the first stream. A 1 Gbit/s link budgeted for one stream now carries two.
3. Register writes. A monitoring tool that adjusts exposure or gain writes to the camera while the primary application runs, which can abort a frame or force the stream to re-sync.

The first mechanism needs no bandwidth arithmetic at all — enumeration and parameter reads alone cause it, which is why drops cluster around moments when the IDE refreshes its view. The second is a numbers problem, and the next section puts numbers on it.

Keeping one long-lived session open instead of cycling open and close, the habit behind camera open/close cycles leaking handles, shrinks the surface for all three.

How much link bandwidth does a second live view cost?

A second live view doubles the pixel payload on the link: the worked example below starts at 602 Mbit/s for one 5 MP mono stream, fits inside a 1 Gbit/s link, and reaches about 1,203 Mbit/s with two viewers, which does not fit.

The decision number is the stream rate against the 1,000 Mbit/s line rate:

Worked example, for a typical 5 MP inspection setup of 2448 × 2048, mono 8-bit, 15 fps:

• Frame size: 2448 × 2048 = 5,013,504 bytes ≈ 5.0 MB per frame.
• Stream rate: 5,013,504 bytes × 15 fps = 75,202,560 bytes/s ≈ 75.2 MB/s.
• Link load: 75.2 MB/s × 8 = 601.6 Mbit/s, about 60% of the 1,000 Mbit/s link.

One stream fits with roughly 40% headroom. A second viewer pulling the same frames doubles the load to 1,203 Mbit/s, 20% over the line rate. UDP has no congestion control, so the NIC or switch discards packets, the stream stalls waiting for resends, and the vision process logs an intermittent failure that tracks exactly with the second viewer being open.

This is the same division-of-links arithmetic as the multi-camera GigE bandwidth budget guide, applied to one camera and two clients.

Two refinements move the numbers, not the decision. Packet overhead — UDP/IP, GigE Vision headers and inter-packet gaps — costs roughly 5% at a 1,500-byte MTU, so usable payload is nearer 119 MB/s than 125 MB/s. Jumbo frames cut both overhead and interrupt load: a 5 MB frame is about 3,340 packets at a 1,500-byte MTU versus about 560 at 9,000 bytes, six times fewer. When saturation is the mechanism, the failure looks like the missing-packet and buffer-overflow errors covered in this GigE camera buffer overflow troubleshooting write-up.

How do you confirm the second client is the cause?

Run the four checks in order — camera alone for a day, monitoring tool alone, both together with NIC counters open, then a packet capture — and the counters will tell you whether control contention or link saturation is dropping the camera.

1. Baseline, tool disconnected. You probably already hold it: weeks of clean logs with the tool closed. Note the exact error text and code for comparison.
2. Tool alone. Stop the robot's vision process, connect the monitoring tool, and open the camera from it for an hour. Clean operation here clears the tool, cable, switch and NIC — the failure needs both clients present.
3. Both together, counters open. Re-attach both clients and watch the NIC receive counters while the IDE's live view is open. On Linux, ip -s link reports per-interface drops and errors; Windows Performance Monitor shows the same counters. Drops advancing exactly while the second view is attached point at contention or saturation.
4. Packet capture. A short capture with Wireshark on the camera's link separates the two mechanisms: repeated control-channel opens from a second source mean contention; long bursts of discarded UDP packets mean saturation.

The result decides the fix. A second control connection in the capture means the one-owner rule in the next section applies. Two streams with packet loss means the bandwidth arithmetic applies — or both do.

What is the fix while you are developing?

Adopt a one-owner rule for every development session: the robot's vision process keeps the camera, you watch images through that process's own live view, and any tool that must open the camera directly runs only after the first owner has released it.

Four implementations, in order of preference:

1. Watch through the owner. Most robot vision processes can display or log images from their own session. Get your live view there and never open the camera with a second tool. Before you debug, read why vision locate works in teach but fails at run time: teach-time viewing is already a different acquisition mode from production.
2. Hand over, then open. When you must inspect with the desktop tool, stop the robot's vision job, open the camera from the tool, close it, then restart production. A clean hand-off beats a contested one every time.
3. Use a monitor connection when the camera offers one. Check the camera's GenICam feature list for secondary-connection support; where it exists, the second client is read-only by definition and the primary keeps streaming. Where it does not exist, no client setting will create it.
4. Give the second client its own interface. If development traffic cannot stay off the camera, put it on another NIC — next section.

Which hardware keeps monitoring traffic off the camera's link?

Put the camera on its own NIC and the monitoring traffic on another: one GigE port carries one full-rate camera stream with roughly 125 MB/s of line rate, and a second interface keeps your robot and monitoring sessions from ever touching that budget.

This is the same split used to put two GigE cameras on one host: each port serves exactly one stream. On the development bench, the camera's NIC carries camera pixels only, and IDE, robot and monitoring traffic run on the second interface or the plant network.

To make the split permanent in the cell, choose a machine-vision controller with more ports than streams: the MV-VC3301H-128G66 carries 5+ LAN ports, 8 GB of memory and 4 built-in light channels, so camera, monitoring and controller traffic each get their own interface.

Two limits keep this honest. A switch between camera and host adds no bandwidth — a 1 Gbit/s switch port forwards 1 Gbit/s, no more — so switching is not the fix for saturation; a managed switch earns its place only for port mirroring during the capture test. And the dedicated NIC does not relax the one-owner rule: interfaces separate traffic, but the camera's control channel still seats exactly one primary application. If you run several cameras plus monitoring on one host, the budgeting in multiple GigE cameras on one computer applies unchanged.

When is the monitoring tool not the cause?

If the camera also drops with every monitoring tool closed, work down the link itself: auto-negotiation falling back to 100 Mbit/s, a marginal cable or connector, or power-saving Ethernet features produce the same intermittent symptom with one client attached.

Three checks cover most of the alternatives. Link speed first: a port negotiating 100 Mbit/s instead of 1,000 Mbit/s cannot carry a real stream, and the resulting packet-size and bandwidth errors are catalogued in GigE camera packet size errors below gigabit. Exposure second: longer exposures cut the achievable frame rate and can push a marginal stream over its timeout — the frame-rate drop at longer exposure times guide gives the arithmetic. Leftover state third: a camera that kept settings from a crashed session behaves unpredictably until you restore a known state, the same starting point as the flaky test from leftover settings fix.

If the drops survive all three checks with a single client attached, the second-client theory is wrong for your cell — and the NIC counters from the confirmation section, run once more with nothing else changed, are still the evidence that decides it.

How do you stop the drops coming back?

Prevention is a four-line policy that fits on the cell's commissioning sheet: one named owner per camera, monitoring through the owner, development traffic on its own interface, and a known-good configuration restored before each session.

• One named owner per camera. Write the owning application into the cell documentation; anyone opening the camera from another tool stops the owner first.
• Monitoring through the owner. Debug images come from the owning process's own view, never from a second open.
• Development traffic on its own interface. IDE, monitoring and robot traffic on a second NIC; the camera's link carries camera pixels only.
• A known-good configuration before each session. A saved settings file means a crashed tool leaves nothing behind.

If you are specifying hardware for a new cell, pick interfaces with room to spare: the area scan cameras category and its camera finder filter by interface, the vision controllers category groups the multi-port machines, and the camera configurator walks the choices in order. The systems troubleshooting guides collect the rest of the acquisition-side failure modes, and the contact page reaches the applications team when your cell's behaviour fits none of the above.