Camera not found: make sure the API matches the camera interface

Your camera is configured correctly — the driver's own tool lists its interface name, serial number and model — yet the enumerate call in your application returns an empty list, and opening the camera by the name you copied from that tool fails with a camera-not-found error. In most such cases nothing is wrong with the camera, the cable or the configuration: the application is calling the enumeration function of one driver stack while the camera lives on another. Frame grabber stacks for Camera Link, CoaXPress and analog cameras, and GenICam network stacks for GigE Vision and USB3 Vision, never list each other's devices. This guide shows how to tell which stack owns your camera, run one test per likely cause, and choose host hardware so the API and the camera agree from the start.

What an empty camera list actually tells you

An empty result from an enumerate call is a statement about that call, not about the camera. Every driver stack enumerates only the devices its own driver manages. When the vendor's configuration tool lists the camera — interface name, serial number, model — the camera and its driver are healthy, and the application is asking a different stack.

The classic case is a Camera Link camera on a PCI frame grabber, configured with the correct camera description files. The application calls the network-camera functions of the driver — in one common vision driver family those are imaqdx.EnumerateCameras and imaqdx.OpenCamera — and both come back empty or with a not-found error. Those functions enumerate FireWire, USB and GigE Vision devices; they never scan a Camera Link board. The board's own acquisition API — the IMAQ routines, without the dx — is the one that owns that camera. Switching the call, not the camera, is the fix.

That split is not unique to one vendor. Any stack built around GenICam enumeration behaves the same way: it lists network-attached and USB cameras, and frame grabber boards stay invisible to it.

Two driver stacks, two device lists

Machine vision hosts carry two families of acquisition software, and the two never share a device list.

The GenICam network stack covers cameras that connect like peripherals: GigE Vision over Ethernet ports, USB3 Vision over USB 3.0 host controllers, plus the older FireWire cameras. Enumeration walks the network or the USB bus and finds devices that announce themselves on it. The cameras also describe themselves: when software connects, the camera serves its own GenICam feature description, so there is no per-camera file to install or maintain.

The frame grabber stack covers cameras that connect to capture cards: Camera Link, CoaXPress, Camera Link HS and analog. The card's driver owns the camera. For Camera Link, the sensor's timing and tap layout live in a camera description file (.icd, paired with a .iid interface file), and the enumerate call lists the boards it finds and the cameras configured on them.

The split catches adapters too: an analog camera wired into a Camera Link grabber generally enumerates as nothing at all, because the adapter fails on signaling grounds long before any API is involved — see analog camera on a Camera Link frame grabber: why adapters fail.

Trace the cable to pick the right stack

The cable's far end decides which stack owns the camera, so trace it before touching any code.

The decision follows directly from the table. Camera on an Ethernet or USB port: call the GigE Vision or USB3 Vision enumeration on the specific NIC or controller the camera uses. Camera on a capture card: call that card's acquisition API and open the interface name it reports. If you are choosing parts rather than debugging, filter the area scan cameras by interface and match the card from the frame grabbers page; the systems topic page collects the driver-level guides behind each row.

Likely causes, one test each

Work down the list in order; the first cause covers most cases where the configuration tool still shows the camera.

1. Wrong API family for the interface. The camera sits on a frame grabber while the code calls the network stack's enumerate, or the reverse. Test: trace the cable, then run the other stack's enumerate and print everything it returns. Fix: switch to the owning stack and open the name or serial that stack itself reports.
2. The device is already claimed. Enumeration succeeds but open fails, or a second process of yours lists nothing. Test: close the configuration tool and any service that holds the camera, then open once and release the handle in a finally block. Two processes fighting over one camera look exactly like this; the two cameras interface claim conflict: diagnose USB access and camera device already in use error: one object, two buttons cases show both shapes.
3. Driver or runtime mismatch after an upgrade. Your build links one driver version while the installed runtime is another, so the enumerate layer comes up empty. Test: run the driver's own example application; if it sees the camera and your build does not, compare versions. Fix: align them — frame grabber driver mismatch after a vision software upgrade covers the board side and camera driver package not configured: restore camera detection the camera side.
4. The board enumerates but the camera does not. Test: grab a single frame with the card driver's own tool. If that also fails, the camera description file is missing or wrong for a non-standard camera — see frame grabber camera config file for a non-standard camera — or the cabling is, per camera connected but no image: check the frame grabber cable wiring.
5. The card is missing from the host itself. No stack can enumerate a board the host has not detected. Test: confirm the card's own driver lists it before any camera software runs; acquisition card runs in code, not detected in configuration software walks the mirror-image case.
6. A GigE camera on the right stack with a degraded link. Enumeration and streaming both suffer when a port falls back to 100 Mbit/s. Test: read the negotiated link speed on the NIC; the fix path is the same as for the packet size error when your link drops below gigabit.

Worked example: the interface also sets your frame rate

Matching the API is free; matching the data rate is physics, and it decides which interfaces are even candidates. Take a concrete camera: the LS-CMR-0166, a 12 MP USB3 camera rated 4000 × 3000 at 30 fps.

Mono 8-bit output gives 4000 × 3000 × 1 B = 12,000,000 B ≈ 12 MB per frame. At full rate the stream is 12 MB × 30 fps = 360 MB/s.

A single gigabit link tops out at 1000 Mb/s ÷ 8 = 125 MB/s, of which about 118 MB/s survives as payload after GigE Vision overhead. That link carries 118 ÷ 12 ≈ 9.8 fps — about a third of what the sensor does. No software change recovers the rest; the port is the limit.

A USB 3.0 port signals at 5 Gb/s: 5 ÷ 8 = 625 MB/s on paper, with roughly 400 MB/s reaching the application after encoding and host overhead. The 360 MB/s mono stream fits, with (400 − 360) ÷ 400 = 10% headroom. The colour variant writes 3 B per pixel: 12 MB × 3 = 36 MB per frame and 36 × 30 = 1080 MB/s — that needs 10GigE, where 10 ÷ 8 = 1250 MB/s and about 1100 MB/s practical gives 1100 ÷ 36 ≈ 30 fps, just enough.

The practical payload figures are typical host results — roughly 94% of the ceiling on clean gigabit Ethernet with jumbo frames, 60-65% on USB 3.0, 85-90% on 10GigE — so budget with the lower end and measure on your own host. Frame grabbers earn their keep at the top of the scale: Camera Link Full moves up to 680 MB/s into a card, and CoaXPress scales further per link. When several cameras share one host, divide the bandwidth per port before buying; the multi-camera GigE bandwidth budget method keeps that arithmetic honest, and the measured GigE Vision high performance NIC driver gains show what the right host driver adds to the payload fraction.

Host hardware so the stack question answers itself

Keeping Camera Link. A current PCIe frame grabber does what the older PCI boards did, with driver support for modern hosts. The Hikrobot MV-GC1102IOL is a Camera Link frame grabber: Camera Link cameras enumerate and open through its driver, exactly as the API-matching rule requires.

If the legacy card was analog rather than Camera Link, replacing an obsolete analog NTSC frame grabber with USB3 Vision is normally the cleaner path than keeping it alive.

Network and USB cameras. GigE Vision and USB3 Vision cameras need no frame grabber; they enumerate on ordinary host ports. What matters is clean ports and, for GigE cameras that take power over the cable, PoE. The MV-GE2002P dual-port PoE NIC streams and powers two GigE cameras; the MV-GU2204 quad USB3.0 adaptor adds four USB3 ports where a host runs short. Check the camera's own power draw first: a camera that draws more over the cable than the port can deliver will enumerate and then drop during streaming.

When the rate outruns the port. Move the interface, not the API: faster Ethernet over copper, or a capture card with the bandwidth to match.

The MV-GT2104 is a quad-port copper 10GbE NIC; the MV-GS1104F-DF fronts XoFLink cameras across four SFP+ ports with 40G total bandwidth. To have the whole chain matched for you, start at the camera configurator or the accessories finder.

Prevention: set the stack choice in the design

Put the decision into the system so it never turns into a debugging session.

• Store the interface type and serial number of every camera in your system configuration, and resolve each camera through its own stack. Never open by list index; assign cameras to ports reliably in a multi-camera system shows the mapping that survives reboots and port reordering.
• Enumerate at start-up and log model and serial for every device found, then assert the expected count before opening.
• Give every device one owner: release handles in a finally block and keep configuration tools closed on production cells.
• Pin driver and runtime versions together and rerun the enumeration check after every upgrade, before the line runs.
• Recompute the bandwidth per port whenever you add a camera; an interface change ordered today beats a frame-rate ceiling discovered on Monday.

The decision, case by case

Trace the cable once and the decision is made.

• Camera on a frame grabber (Camera Link, CoaXPress, analog): call the frame grabber's own acquisition API and open the interface name that stack reports. The network enumeration will never list it, on any driver version.
• Camera on an Ethernet port: enumerate through the GigE Vision stack on that NIC and open by serial or address. No frame grabber needed; pick a PoE port if the camera takes power over the cable.
• Camera on a USB 3.0 port: enumerate through the USB3 Vision stack on that controller.
• Rate outruns the link: change the interface — 10GigE, Camera Link or CoaXPress — and the NIC or card that goes with it, sizing the move with the worked example's arithmetic.

If enumerate and open still disagree with the configuration tool after these tests, send us the camera model, the port or card it sits on and the driver versions through the contact page, or let the configurator assemble the acquisition chain the right way round from the first click.