Vision software can't find your camera: the missing driver layer

You install the vision package, wire the camera, open the acquisition example — and the device list comes back empty, with a message about driver software that cannot be found. Nothing is broken. A machine-vision package never talks to cameras directly: it enumerates through a driver layer that speaks the camera's interface standard, and that layer installs separately from the application. This guide shows you how to read the standard off the camera, install the matching acquisition driver from the software vendor, check enumeration below the SDK, and tell a missing-layer failure apart from the bandwidth problems that look similar once the camera is listed.

The symptom and the three layers

The report always has the same shape: the application starts, every editing and analysis feature works, and acquisition fails for every camera you plug in — often with the same message whichever acquire button you press. Three layers have to line up before a camera appears in a device list:

• OS enumeration. The NIC shows a link light, or the USB device shows in Device Manager or lsusb. On its own this proves nothing about the SDK.
• Transport driver. The OS-level component for the interface standard: the GigE Vision filter driver bound to the network adapter, the USB3 Vision transport, or a frame grabber's PCIe board driver.
• The package's transport module. The GenICam/GenTL producer the software loads at runtime, which asks each installed transport what devices it sees.

An error naming driver software that cannot be found is layer two or three speaking. The camera never reached the software, so no camera setting can fix it.

Why installing the application alone never works

Vision software ships as two separate installs: the application (IDE, tools, runtime libraries) and the acquisition package (transport drivers plus the GenICam runtime). The split exists because each interface needs OS-level code — a network filter driver, a USB transport, a PCIe board driver — and because the transports come from the software vendor even when the camera comes from someone else.

The device list is built by polling each installed transport. With none installed, the list is empty no matter how many cameras are plugged in, which is also why reinstalling the application changes nothing: the repair never touches the driver component. How the integration options differ, and what each one requires, is compared in the guide to camera acquisition software compatibility and integration options.

Match the driver layer to the interface standard

One rule decides the fix: read the interface standard off the camera's spec row, then install the acquisition component from the software vendor that names that standard. The spec row is unambiguous:

GigE Vision and USB3 Vision exist for exactly this: a conforming application can discover and control a conforming camera — what that compatibility guarantees — but the transport still has to be on your PC first. If enumeration then misbehaves, the GigE Vision software compatibility checks cover the next suspects.

The standard is chosen per model, not per series. The LS-CMR-0053 is the 12 MP GigE model in the range; the LS-CMR-0166 covers the same 12 MP, 1/1.7" format over USB3. Two interfaces, two driver stacks: the GigE camera wants the GigE Vision runtime and a network port, the USB3 camera wants the USB3 Vision transport. Installing one does not make the other appear, which is why "but the driver is already installed" so often means the sibling interface's driver.

Every interface in the table is stocked as an area scan camera — the card below opens the range, filterable by interface, resolution and sensor format.

Likely causes, in order of probability

Cause 3 has its own walkthroughs: the camera visible in lsusb but not detected by the vision SDK and isolating Linux access errors when the camera SDK cannot find the device.

The fix: install, reboot, enumerate below the SDK

1. Read the interface standard off the spec row — GigE Vision, USB3 Vision, CoaXPress, Camera Link or plain USB — and note the camera's MAC or serial for matching later.
2. Run the software vendor's installer and tick the acquisition component for that standard. Component names vary by package; the generic kinds are a GigE Vision filter driver or network service, a USB3 Vision transport, or a GenTL producer entry.
3. Reboot when asked. Transport drivers bind into the OS network and USB stacks at boot.

4. Check below the SDK. Ping the GigE camera, confirm the USB device in the OS, and look for the grabber board in Device Manager before the package starts — a board that will not appear has its own frame grabber driver installation walkthrough.
5. Enumerate in the package's transport layer. The camera should list with no acquisition configured and no settings touched.
6. Only now set exposure, gain and packet size. Values the module rejects after discovery are a different failure class, covered in checking GenICam enumerations before you set them.

Worked example: can one GigE link carry a 12 MP camera at 9 fps?

Inputs, with their sources:

• Camera rate: 12 MP at 9 fps over GigE — the catalog row for the LS-CMR-0053.
• Pixel depth assumed: 8-bit mono, 1 byte per pixel, the common output for geometry and code reading; 10-bit scales the demand by 1.25, 12-bit by 1.5.
• Link capacity: one GigE port, 1 Gb/s ÷ 8 = 125 MB/s raw; usable stream payload runs about 90-115 MB/s with jumbo frames, lower on a default 1500-byte stack.

The rule in words: required stream rate equals pixels per frame, times bytes per pixel, times frames per second, compared against the link's usable ceiling.

Arithmetic: 12,000,000 px × 1 B = 12 MB per frame. 12 MB × 9 frames/s = 108 MB/s. Margin: 108 ÷ 125 = 0.86, so 86% of the raw ceiling — above the ~85% point where an untuned link starts discarding. Switch the output to 10-bit and demand rises to 12,000,000 × 1.25 × 9 = 135 MB/s, past the 125 MB/s raw ceiling: that format cannot run at 9 fps on one GigE link at all.

Decision: at 86% of raw, this camera lists correctly and streams only after tuning — jumbo frames first, then the high-performance NIC driver: how much you gain, then a faster interface such as 5GBASE-T: bandwidth, cables and distance. Note what the case proves diagnostically: a camera that enumerates and then drops frames has a working driver layer. If the device list is empty, none of this tuning applies — go back to the fix steps.

The same trap on USB3, at higher speed

USB3 Vision cameras enumerate only through the package's USB transport, and bandwidth bites sooner because "USB is fast" hides the port question. The LS-CMR-0166 streams 4000 × 3000 at 30 fps over USB3. Working the numbers in 8-bit mono: 4000 × 3000 px × 1 B = 12 MB per frame, and 12 MB × 30 fps = 360 MB/s — close to a USB 3.0 port's practical ceiling of roughly 400 MB/s of real payload.

So the camera needs its own root-controller port, not a hub or a front-panel USB 2.0 socket. On a USB 2.0 link the same stream caps near 40 MB/s, and the failure shows up mid-acquisition as timeouts, not as an empty device list. Linux makes the port visible: if lsusb -t shows 480M, the camera negotiated USB 2 speed, and the negotiated-USB2 walkthrough explains how to chase it.

When the camera is listed but the frames stop

Order the levers by cost. First, packet size to jumbo (typically 9000 bytes) on both camera and NIC. Second, NIC driver tuning, which recovers real margin on GigE Vision. Third, the interface upgrade. Missing frames that follow a pattern — every camera, same interval — usually point at the host side, and the GigE Vision firewall walkthrough for missing images covers the discovery and streaming ports. The worked example gives the threshold: plan tuning before any stream exceeds about 85% of the link's raw rate.

The same rule outside machine vision

Industrial software always acquires through a named, installed layer, and the error messages are the same shape. HMI platforms integrate vision cameras through their own driver module — how an HMI integrates vision cameras through its software — and the camera stays invisible until that module is installed. PLC programming tools behave the same with interface drivers: a settings dialog lists the available transports, and a missing TCP/IP entry in the interface settings means the driver was never installed, not that the hardware failed. When an error names a driver, treat the name as the instruction: install that component from the tool's own vendor.

Prevention: keep the layer from breaking again

• Record the interface standard next to the model number when you order; the spec row, not the series name, decides the driver.
• Build the station PC image with every SDK's acquisition component included before any application is configured.
• After a software update, re-run the full installer with driver components ticked; a partial update leaves the app mismatched with the transport.
• Give GigE Vision cameras a NIC of their own, or a firewall rule set, at commissioning; check enumeration below the SDK before blaming your code.
• Keep driver versions in the station file next to the camera list, so a mismatch is visible at a glance.

Get the layer matched and the rest of the integration is ordinary engineering: one camera, one transport, enumeration you can test below the SDK before a line of your own code runs. If you are choosing the camera as well as the driver, the camera finder filters area scan cameras by interface, resolution and shutter, and more acquisition-side fixes are collected on the systems topic page. For a new station, the configurator builds the chain starting at the camera: