Frame grabber not detected: diagnose the card before the driver

You have fitted the frame grabber, installed the acquisition stack — maybe more than once — and the software still lists no device. Before you reinstall anything, read what 'not detected' actually tells you: the vision software cannot list a device the operating system never saw. This page gives you the order that finds the fault: confirm enumeration in Windows Device Manager or in lspci, bind the vendor driver, rule out the slot and its resources, and only then touch camera files and acquisition settings. Five checks, about ten minutes, and you will know which layer to blame instead of guessing.

What 'not detected' means: three different failures

Three separate layers sit between the card's edge connector and a live image, and each fails differently. Enumeration is the PCIe link training and the host writing the board into its hardware tree; it happens with no driver at all. Binding is the vendor driver claiming that enumerated device. Discovery is your vision software finding the bound device through its transport layer — for GenICam-based software, the GenTL producer. Camera configuration files sit above all three and can do nothing until enumeration and binding succeed. The decision rule for the whole page follows from that stack: if Device Manager or lspci does not list the card, no amount of work in the software layer will help, so start there.

Step 1 — confirm enumeration before anything else

On Windows, open Device Manager with the card fitted and the machine cold-booted. Any new entry counts: the card under its own category, or an unknown 'PCI Device' with a warning mark under Other devices. Reseat once and run 'Scan for hardware changes'. On Linux, run lspci -nn and look for the new line; the switch prints the vendor:device ID you will quote to support. If nothing new appears in either place, the fault is below the driver: reseat the card, clear dust from the connector edge, move it to another slot, and check the UEFI setup screens for an option that disables PCIe slots. A card invisible in two slots and a second PC is a service case, not a software problem.

Step 2 — enumerated but unbound: bind the vendor driver

An unknown 'PCI Device' is good news: the link trained, and only the binding is missing. Install the driver package from the card vendor, then in Device Manager choose update driver on the unknown entry and point it at the extracted package folder; Windows binds it and the entry moves to the vendor's category. Restart afterwards, because most acquisition services re-scan only at boot. Two situations produce this state predictably: a card moved from an old PC into a new one with a newer chipset, and a vision-software upgrade whose bundled driver no longer matches the one installed in Windows. Both have their own pages: the frame grabber driver manual installation fix and the driver mismatch that follows a vision software upgrade.

Step 3 — the slot: lanes, risers and UEFI options

PCIe negotiates downward: a x4 card fitted in a x1 slot enumerates and runs, at the slot's width. That makes slots a detection fault only when the link fails entirely — poor seating, a dead riser or extender board, or a slot disabled in UEFI. Riser and extension boards are the most common cause in compact machines; a card that vanished after a machine rebuild is often sitting on one. Reseat, then swap to a slot wired to the CPU rather than the chipset where one exists. The lane and chipset budget a grabber needs is set out in PC requirements for a frame grabber, and the same logic for network cameras in PCIe slot compatibility for GigE cameras.

Worked example: feeding a four-port Gigabit card from a x1 slot

The inputs: a four-port Gigabit Ethernet card on a PCIe x4 edge connector — the class the LS-FGB-0004 belongs to. Gigabit Ethernet runs at a 1 Gb/s line rate per port, which is 125 MB/s of payload per port; the PCIe standard gives roughly 500 MB/s per lane at Gen2 and roughly 985 MB/s per lane at Gen3. The rule in words: a card fitted in a narrower slot runs at the slot's width, so the slot must carry the sum of the ports' line rates with headroom to spare for protocol overhead.

The demand works out at 500 MB/s. A Gen2 x1 slot supplies about that in raw bandwidth, and protocol overhead takes its cut from the same figure, so four busy ports will stall. A Gen3 x1 slot supplies about 985 MB/s and passes with half its capacity free. The decision: for a four-port Gigabit card, use a Gen3 slot at any width, or a Gen2 slot of x4 or wider; a Gen2 x1 slot is not acceptable for this card at full line rate. Run the same sum before fitting any CoaXPress or 10GigE card, whose demand runs several times higher.

This is the card class the example describes:

Step 4 — the card enumerates but will not start

If the entry appears but its device properties report an error — resources it cannot claim — you have a conflict, not a detection failure. Two cards, or the chipset's own controllers, are asking for overlapping address windows or lanes. Move the grabber to a CPU-attached slot, disable slots you do not use in UEFI, and remove cards one at a time until the clash shows itself. The failure mechanisms and the fixes are set out in resolving machine vision frame grabber resource conflicts.

Step 5 — only now the software stack

With the card enumerated and bound, a discovery failure is a genuine software fault: the transport layer not registered after the install, camera files copied into the wrong directory for the installed version, or the application pointed at the wrong host interface. Test in this order: the vendor's own grab utility, then your vision software's device tree, then your application. If the grab utility shows an image and the software does not, the GenTL transport layer startup diagnosis and the missing driver layer behind software that can't find your camera name the exact pieces to check, and camera configuration that stops responding covers the case where the tool hangs instead. When detection works but no pixels arrive, a camera cable or camera fault becomes possible — follow the pipeline probe for a blank image.

When you do not need a frame grabber at all

Some 'frame grabber not detected' reports are the wrong category of card. GigE and USB3 cameras stream over standard host interfaces: a GigE camera needs a PoE network adaptor, not a frame grabber, and the NIC enumerates in the same Device Manager you checked in step 1. A NIC that enumerates while its camera stays invisible is a different fault, covered in duplicate PoE camera discovery and checking a port for PoE support.

In the catalogue this maps to the MV-GC1102IOL for Camera Link, the MV-GX1008 for CoaXPress, and for XoFLink the MV-GS1104F-DF, which lists 40G total bandwidth supported. On the network side the Ethernet adaptors step up by interface:

All 3 share: Humidity 10% RH to 95% RH (no condensation); Jumbo frame 9 KB. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

For a single GigE camera, a dual-port PoE NIC covers the camera today and a second one later:

Make the next fault a ten-minute job

• Bench-test every new card in a plain office PC before it enters a machine image, and record the lspci -nn vendor:device ID and slot on the station's build sheet.
• Fit each card in a slot that matches its edge connector; the record keeps device order predictable, and when two cards swap channels the device-order fix for multiple frame grabbers starts from it.
• Update chipset and storage-controller drivers before blaming the grabber package after a Windows update.
• Keep one driver version per station, and after any OS or vision-software upgrade repeat step 1 before opening acquisition settings.

The rest of the systems troubleshooting guides follow the same layer-by-layer habit.

The decision, case by case

• Nothing new in Device Manager or lspci after a reseat and a second slot: power, UEFI or the board itself — bench-test it, then contact us with the machine details.
• Unknown 'PCI Device' present: install or re-bind the vendor driver, restart, and the entry moves to its category.
• Entry present with an error status: resource conflict — move slots and disable unused ones.
• Bound and clean, but the software list is empty: transport layer and camera files — grab utility first.
• GigE camera on the wanted list: it needs a PoE NIC, not a frame grabber.

If you are choosing hardware for a new station instead, the frame grabbers category lists every card by interface, the accessories finder filters by ports and bandwidth, and the configurator walks the whole chain from camera to card.