Camera connected to a vision controller will not open from your PC

The bench build works and the floor build does not: your inspection code runs on the office PC, the camera hangs off a smart camera or a vision controller on the machine, and the grab call that opened the device an hour ago now reports it missing. That is not a driver fault, and no camera-name string will fix it. A device cabled to a controller is owned by that controller's runtime, and a GigE Vision camera grants exactly one control connection at a time. This guide shows how to confirm ownership in four tests, how to choose between deploying your code to the controller and moving the camera to the PC, and how to move results across the plant LAN instead of pixels.

Why can't my PC open a camera that is cabled to a vision controller?

The device is already owned: a smart camera or vision controller enumerates the cameras cabled to its own ports, and its runtime holds the single control connection that a GigE Vision device grants, so your PC code is asking for a device another host has already taken.

Two layouts produce the same symptom. If the camera sits on a port that belongs to the controller - a dedicated camera LAN port, a USB3 Vision port, an internal frame-grabber link - the PC never enumerates it, and the device list comes back empty by design. If the camera hangs off a switch that both hosts reach, the PC lists the device but the open call fails as busy or in use, and every SDK words that error differently. If your stack goes through OpenCV, the failure happens before any SDK error appears; the guide on why OpenCV VideoCapture cannot open a GigE Vision camera follows that path in detail.

A smart camera removes the second host entirely. Sensor, illumination outputs and the inspection engine live inside the device, the Ethernet cable carries settings and verdicts, and there is no grab session for a PC to hold, because the device is not a peripheral - it is the computer.

How do I tell controller ownership from a cabling fault?

Test ownership before you blame hardware: open the camera list from the PC while the controller's runtime is running - if the device shows as busy or in use, ownership is the cause, and if it never lists at all, the camera is not on a network your PC can reach.

Run the tests in order; each one cuts the fault space roughly in half.

1. Ping the controller's IP. If the controller answers and the camera still will not list on the PC, the network path is healthy and the fault is ownership or subnet layout, not wiring.
2. Read the SDK's error class. Not found, on a device you can reach, means the camera is hidden by design or filtered by subnet; busy or access denied means another application holds the control connection.
3. Stop the controller's runtime, then refresh the PC's device list. If the camera appears and opens cleanly while the runtime is down, ownership is confirmed - and the camera itself is healthy.
4. Cable the camera straight to the PC as a bench check. If it opens and streams there, your code and the camera are fine, and the architecture is the fault - which is the decision at the end of this guide.

Listing failures on Linux have their own layer of causes - permissions, device rules, SDK access errors - worked through in the guide on camera SDK cannot find device: isolate Linux access errors.

Can two computers grab from one GigE camera at the same time?

No: the GigE Vision control protocol grants one primary application exclusive control, so a second computer sees the device as busy; some cameras accept a monitor-only secondary connection, but that carries status rather than pixels and will never feed a grab loop.

That exclusivity is why the fix is never a naming trick. A camera name selects between devices a host can already reach; it cannot create a path that does not exist. USB3 Vision is stricter still: only the host that owns the cable enumerates the device, and across a network switch there is no path at all.

If two stations genuinely need the same part in view, fit two cameras sharing one trigger, or give the single camera a single owner. A second camera is routine hardware; a race for one camera is a production stop that repeats at every restart.

Where should the acquisition and processing run?

Run the pipeline where the camera lands: a 5 MP frame at 24 frames per second is about 967 Mbit/s of raw 8-bit data - one entire GigE link - while the inspection result for the same part is a 64-byte string, roughly 12 kbit/s at the same rate.

Worked example: a typical 5 MP sensor at 2592 × 1944 pixels, 8 bits per pixel, inspected 24 times per second, with a 64-byte result (verdict, coordinates, part ID). Scale linearly to your sensor's real pixel count and frame rate.

The decision falls straight out of the numbers. Any camera above a few frames per second belongs on a controller port or inside a smart camera, and the plant LAN carries verdicts, never pixels. If the pipeline then outruns the processor, that is a separate frame-rate gap to close on the controller itself: the guide on acquisition faster than processing: fix the frame rate gap covers the diagnosis, offloading 3D inspection processing to a vision controller shows the deployment pattern, and image processing on a PLC: what a controller can realistically handle sets expectations before you write a line.

Vision sensors are built around exactly this split:

Its Fast Ethernet interface is the design rather than a bottleneck: the device inspects the 5 MP image on board and ships a verdict per part, so raw pixels never cross the network.

How do I get inspection results off the controller to my PC or PLC?

Ship the verdict, not the pixels: publish the result string on a TCP socket or the protocol your vision software already supports, and reserve a hardwired go/no-go line for the PLC when the cell must fail safe without Ethernet.

The payload is trivial: a verdict, a position and a part ID fit in 30 to 40 ASCII characters, which is kilobits per second at line rate. Send it over a TCP socket or the protocol your vision software already speaks - smart camera OCR string output over TCP: how to send it walks the string path end to end. Where the cell must fail safe without Ethernet, add a hardwired verdict line from the controller's I/O to a PLC input, and size it from the I/O listed on the model you order.

Strobing belongs on the controller too. The two models below drive lights straight from built-in channels, which removes a separate strobe box from the panel:

Two current controllers, side by side:

All 2 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-VC5525-256G70-NN adds PoE camera ports for power-plus-data cabling, and 8 built-in light channels cover the strobes. The MV-VC2140-128G40-1T runs the same pattern on smaller cells with 4 built-in light channels.

When should the camera stay on the PC instead?

Keep the camera on the PC when the PC must own the pixels - algorithm development, sensor characterization, training-data capture and one-off bench work - and move it back to the controller or a smart camera before the cell goes into production.

Development is the main case. Algorithm work, sensor characterization and training-data capture all want the workstation's memory and toolchain, so re-cable the camera to the PC for the bench phase - deliberately, with a label on the cable, and back again before the cell ships. If a deployed solution already owns the hardware and you still need code time, build against emulated devices: machine vision development without a camera: emulation options covers the no-hardware paths.

When the PC does own the pixels, a GigE camera behaves like any other network device on the workstation:

5 MP color with a global shutter covers label and surface work on the bench; put the same camera on a controller port later and every rule in this guide applies unchanged.

How do I set up the network so the split works every time?

Split the network by owner: give the camera-to-controller links their own private subnet on the controller's spare LAN ports - most models list five or more - and keep the plant LAN on a separate port for results only.

A busy plant LAN can starve a camera stream below its frame rate, and a camera that drops packets mid-scan looks like a flaky inspection, not a network fault. Keep the pixel path off the plant network - vision cell network isolation from a busy plant LAN gives the segmentation steps - and keep the runtime state clean: stop it before a PC grab test, restart it before you leave the machine, and start each session from a known state, because leftover debug settings are the classic cause of a test that passes on Monday and fails on Tuesday, as camera tests flaky on leftover settings: start from a known state explains.

For the controller side of the split, 5+ LAN ports and PoE camera ports turn the private subnet into a wiring plan rather than an add-on:

Work the prevention list into the handover:

• Name the owner of every camera in the panel drawing; drawings outlive memories.
• One owner per camera for the life of the cell; two views means two cameras.
• Keep camera links on a private subnet; the plant LAN carries results only.
• Stop the runtime before any PC grab test, and restart it before leaving the machine.
• Write the IP plan - controller, cameras, PLC - on the cabinet door.

Deploy to the controller or move the camera: which fix fits your case?

Decide by who must own the pixels: if the cell runs headless at line rate, deploy the code to the controller and let the PC stay a debug host and results client; if the workstation's toolchain is the point, move the camera to the PC and keep one owner.

Match resolution and interface in the camera finder, lay the whole chain out in the configurator, and if an ownership case still fights you, send the exact SDK error text and your layout sketch through the contact page.