Camera detected but not in acquisition tool: fix the adapter layer

You connected the camera, opened the vendor's hardware detection application, and it listed the camera with every supported format. Then you opened your acquisition tool and the device list was empty. The camera is almost never at fault: the vendor utility enumerates through the vendor SDK, while your tool enumerates only the adapters installed into it — a DirectShow list, a GenTL producer, a frame grabber SDK. This guide works the fault in probability order: see what each side actually enumerates, clear the holders and stale state, load the matching transport layer, and when no adapter will ever list the camera, bridge the SDK through its documented interfaces. Ten minutes of ordered checks beats an afternoon of cable swapping.

Two enumeration layers, one camera

Every path into a camera enumerates its own device list. The hardware detection application that ships with the camera enumerates through the vendor SDK — that is the one list guaranteed to show it. The OS device list proves only that a driver bound: on Windows, an entry under Imaging Devices; on Linux, a line in lsusb. Your acquisition tool reads neither of those. It reads the adapters registered inside it, and a camera that lives on a vendor transport is simply not on those lists yet.

That is why the symptom splits so cleanly. If the vendor tool streams, sensor, power and cable are proven good, and the empty list in your tool is a routing fact, not a hardware fault. The same layered gap explains vision software that cannot find your camera and why one viewer works while another fails on the same PC.

Which list does your tool actually read?

In a MATLAB-type tool the queries are explicit: imaqhwinfo with no arguments returns the adapters installed, and imaqhwinfo('winvideo') returns what that one adapter enumerates. If the adapter list is shorter than you expected, the camera was never going to appear in it, whatever the OS says.

The diagnosis, in probability order

1. Stream in the vendor's own viewer. A live preview with the formats listed proves camera, cable and power. Everything after this step is software.
2. Query the tool, not the OS. An empty result from the tool's own enumeration, while the vendor viewer streams, is the adapter gap. Stop debugging hardware.
3. Confirm the OS layer once. An Imaging Devices entry or an lsusb line next to an empty tool list is the classic signature of this fault — the same split as a USB camera visible in lsusb but not the vision SDK. Embedded boards fail the same way: a camera module a board-level probe cannot detect is a stack problem, not a dead sensor.
4. Close every holder, then reset once. Machine-vision drivers grant exclusive control, and the vendor viewer from step 1 is the first suspect. Close it, close OEM demos, close browsers. Then reset the tool's acquisition layer — imaqreset in a MATLAB-type tool — and re-query. If only repeated resets make the camera appear, something is leaving handles behind: close applications in reverse start order and reboot once. The holder pattern is covered in GigE camera open fails in a second tool.
5. GigE: check the transport layer, not ping. GenICam discovery rides subnet broadcast, so a camera that pings can still be invisible when the transport layer is not loaded or the subnets differ. See ping works, zero cameras and why ping is not enough for discovery. The host firewall must pass the discovery traffic or the list stays empty — GigE Vision firewall troubleshooting.
6. USB3 Vision and GenTL: point the tool at the producer. The tool enumerates through a GenTL producer; a missing producer, a wrong path or a version mismatch all present as zero devices. Start with GenTL transport layer startup and GenTL producer version compatibility.
7. Match bitness. A 64-bit tool cannot load a 32-bit SDK DLL or adapter, and the adapter fails quietly, so the list comes back short. The same mismatch breaks wrappers in other languages — fixing SDK bitness in a Python wrapper shows the pattern.
8. Swap the cable once. A marginal USB3 lead renegotiates to a slower link, which shows up as slow streaming rather than an empty list, so it is the last check, not the first. Keep spare machine-vision cables on the bench for exactly this test.

Worked example: 12 MP frames at intervals through a USB3 bridge

The camera for the arithmetic is the LS-CMR-0166, a 12 MP USB3 area scan camera with 4000 × 3000 resolution at 30 fps.

The task is one saved frame every 2 s at a microscope station — an illustrative interval, since the interval, not the camera, sets the load. The link is USB 3.0 at 5 Gbit/s. Assume 3 GB/s of host copy bandwidth for one memcpy thread.

Work through it:

• Frame size: 4000 × 3000 pixels × 1 byte per pixel = 12,000,000 bytes, about 12 MB for a mono 8-bit frame.
• Full-rate streaming: 12 MB × 30 fps = 360 MB/s. USB 3.0 carries 5 Gbit/s = 625 MB/s raw; 8b/10b encoding keeps 80 % of that, 500 MB/s, and protocol overhead leaves roughly 350-450 MB/s usable. 360 MB/s fits, with little headroom and only on an otherwise idle link.
• Interval capture: 12 MB ÷ 2 s = 6 MB/s. Any bridge, any link.
• Host copy: 12 MB ÷ 3 GB/s = 4 ms per frame. The frame period at 30 fps is 33 ms, so the copy is about 12 % of the period.

The decision: below roughly 10 ms of copy per frame — 4 ms here — the copy is not worth optimizing; the display path is the slow step. Let the SDK draw into a native window through its own display function, add overlays there, and copy frames into arrays only when you process them. At one frame every 2 s, the bridge choice is purely a maintenance question, never a bandwidth one. When you do need every frame at full rate, 360 MB/s on one USB3 link leaves no room for a second camera on the same controller. When frames outgrow a single camera link, the frame grabber becomes both the bandwidth path and the enumeration layer:

Bridging the vendor SDK when no adapter will ever list the camera

If the tool has no GenTL support and the camera exposes no DirectShow filter, no setting will make it appear in the device list. Bridge instead. Three routes, ranked by maintenance cost:

1. The .NET assembly. The SDK ships as a managed assembly; load it through the tool's .NET interface and the full feature set — parameters, capture, display — stays callable. Handle pointer-returning calls through the assembly's own types rather than raw pointers. A version bump re-links without re-declaring anything.
2. A MEX wrapper. Compile a C or C++ MEX-file against the SDK and return each frame as a native array. Tightest per-frame timing, at the cost of a compiler toolchain and a declaration for every function you call.
3. A C wrapper with loadlibrary. Declare the prototypes, load the SDK DLL, call init, open, capture. Right for three or four calls; painful beyond that, because every buffer return becomes manual pointer marshaling.

The decision: take the .NET assembly if the vendor ships one; take the MEX route when you cannot use .NET or need deterministic per-frame timing; take loadlibrary only for a handful of calls. The pattern is identical in every host language — calling a camera SDK DLL from LabVIEW and driving camera registers from your own control code walk it end to end.

When it is not the adapter

• Enumerated, then no image. The backend, not the list. A viewer missing its decode plugins shows a connected camera with no video — GStreamer missing plugins.
• Visible in one tool, invisible in another on the same PC. Adapter support differs per tool, not per camera — camera acquisition backend compatibility.
• Appears, disappears, reappears. An exclusive holder or a crashed session leaving handles behind; run the reset routine in step 4.
• Listed but every open fails. Exclusive control again, or the bitness mismatch from step 7.

Order the fault this way: missing from the list is the adapter, present but silent is the backend, intermittent is a holder. More systems integration troubleshooting follows that same split.

Choosing hardware that enumerates everywhere

Prevention costs less than bridging. A camera that speaks GigE Vision or USB3 Vision lists in any tool that loads a GenTL producer — one code path, two cable types — and what GigE Vision guarantees for tool compatibility is worth reading before the next purchase. Start from the area scan cameras finder or the camera finder and filter on the interface your tool actually enumerates.

The LS-CMR-0053 is a 12 MP GigE area scan camera that streams at 9 fps.

Twelve megabytes a frame at mono 8 bit puts 108 MB/s on the wire at that rate, inside what a gigabit link carries with jumbo frames — a streaming rate, not a burst. On the host side, a dedicated PoE card settles the power and driver questions in one part:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Browse frame grabbers when the camera links through a card, and let the system configurator chain camera, cable and host so the enumeration path matches the tool from day one.

Checklist before you escalate

• Vendor viewer streams the camera: hardware proven, nothing gets returned yet.
• Tool adapter list queried by name: you know exactly which adapters the tool has.
• Every holder closed, acquisition layer reset once, query repeated.
• GenTL producer path set and its version matched to the tool.
• Bitness of tool, SDK and runtime identical.
• Subnet and firewall cleared on GigE; producer loaded on USB3 Vision.
• Cable swapped once, same result.
• Decision recorded: GenTL enumeration, SDK bridge, or camera swap.

If the list is still empty after those eight checks, the shortest path out is a standards camera plus a GenTL-capable tool. Run the camera finder for the interface your tool supports, or send the setup to us and we will size the swap with you.