Frame grabber diagnostic test failed: isolate board from camera

Three red lines in a frame grabber diagnostic report — FPGA test: failed, interrupt test: failed, trigger test: failed — and a demonstration waiting on the machine. The reflex is to blame the camera, then the cable, then the software, and burn a day on all three. The faster path is one clean experiment: run the diagnostic suite again with the camera cable removed. Those three self-tests exercise the grabber's own silicon, the host's interrupt path and the trigger circuitry, so their pattern without a camera tells you whether the fault lives on the board, in a PCIe slot or in the driver. This guide gives you the decision rule, a ranked cause list, a six-step isolation sequence and the evidence pack that gets an RMA accepted.

What each failed test exercises

The FPGA test never leaves the board. The utility loads a test configuration into the on-board FPGA and walks data through its internal paths and local memory. No camera, cable or connector takes part, so no camera swap can fix a failing FPGA test — and a pass proves the card's core electronics.

The interrupt test has two ends. The board raises an interrupt and the host driver must acknowledge and service it. A failure implicates the board, the driver, or the way the chipset routes the interrupt, which makes it the one test a sick host can fail on perfectly healthy hardware.

The trigger test exercises the I/O block. The board drives its trigger output and expects a defined level, or a returning pulse, at its trigger input. With the camera wired in, the camera's trigger line can hold that input at the wrong level and fail a good board. That single detail explains most "all tests failed" reports that arrive with everything still connected.

Read the pattern, not just the word failed: all three together versus one alone is the whole diagnosis. For how these blocks behave once images flow, see the frame grabber image acquisition guide for Camera Link and CoaXPress.

The rule: unplug the camera first

With the camera cable off, the verdict is short:

• All three tests fail — the board or its host seat is at fault. One slot swap and one clean driver install decide which.
• All three pass — the board is proven good. The fault is downstream: the cable, the camera configuration or the host's bandwidth.
• One test fails alone — a specific subsystem, and most of those causes live on the host side (table below).

Timeout and image-lock errors during live acquisition belong to the link, and a clean self-test never proves the link either. The two halves of the evidence answer different questions, so collect both.

Likely causes, ranked by probability

Match the pattern against this table before touching a screwdriver:

Two of the six rows end at an RMA; the other four cost about an hour, which is why the sequence below runs them first. The interrupt-only row deserves a second look, because shared interrupts and chipset routing conflicts fail healthy boards all day — the machine vision frame grabber resource conflict guide walks the confirmation and mitigation steps.

The isolation sequence

1. Power down fully and remove the camera cable from the grabber, so the evidence comes from the board alone.
2. Boot and run the vendor's diagnostic utility. Record pass or fail for each test. If all three pass, go to step 6; if any test fails, continue.
3. Power down, reseat the grabber in a different PCIe slot, and prefer a slot attached directly to the CPU over one hanging off the chipset. Latch any auxiliary power connector the card carries. The frame grabber PC requirements guide explains which slots carry which lanes.
4. Boot, reinstall or repair the grabber driver from the manufacturer's distribution, confirm the card enumerates in Windows Device Manager or lspci on Linux, and run the diagnostic again. The unresponsive frame grabber host PC fix covers driver-side failures that mimic hardware faults.
5. If the same tests fail in the second slot with a clean driver, the board is proven faulty: build the evidence pack below and start the RMA. If the tests now pass, the board is proven good, and the fault sits in the camera, cable, configuration or slot bandwidth.
6. Reconnect the camera with a known-good cable and rerun live acquisition. If timeouts or image-lock errors return on a board that just passed, work the no-image procedure instead of blaming the board again.

Worked example: slot bandwidth for a dual-port 10GigE grabber

Step 3 moves the board, but not every slot can carry it — a starved slot passes every self-test and still times out once images flow. The case below is the one that bites right after a board swap. Take a dual-port 10GigE frame grabber such as the MV-GT1102P.

Inputs. Two 10GigE ports, from its catalog entry; 10 Gbit/s line rate per port, the 10GigE standard; candidate slots PCIe 3.0 x1 and x4; per-lane throughput of 0.985 GB/s on PCIe 3.0 and 0.5 GB/s on PCIe 2.0, from the PCI-SIG signalling rates.

Rule. A slot can host the grabber only when lane count times per-lane throughput exceeds the summed port line rate, with headroom left for packet overhead.

Arithmetic. Required: 2 × 10 Gbit/s = 20 Gbit/s, and 20 ÷ 8 = 2.5 GB/s. Gen3 x1 supplies 0.985 GB/s — short by 2.5 ÷ 0.985 ≈ 2.5×, so it fails. Gen3 x4 supplies 4 × 0.985 = 3.94 GB/s; 2.5 ÷ 3.94 ≈ 63% used, 37% headroom, so it passes. On a Gen2 host the same card needs x8: x4 gives 2.0 GB/s (under the 2.5 GB/s requirement), while x8 gives 4.0 GB/s at 63% utilization.

Decision. A dual-port 10GigE grabber belongs in a PCIe 3.0 x4 slot or wider, or x8 on a PCIe 2.0 host. Below that, expect self-tests to pass and live acquisition to time out — a bandwidth-starved slot mimics a board fault exactly.

The same arithmetic scales up the range: the MV-GS1104F-DF is a four-port XoFLink grabber rated for 40G total bandwidth. At line rate that is 5 GB/s, so a Gen3 x8 slot (7.88 GB/s) is the realistic minimum. The PCIe slot compatibility guide for GigE cameras runs the same lane math for single-camera links.

When the tests pass but the image does not

A board that passes every self-test is rarely the problem, so work outward from the connector.

1. Swap the camera cable for a known-good one of the right family and length. Cable damage accounts for a large share of pass-everything, time-out-anyway cases; for a Camera Link camera, a 5 m SDR-to-SDR cable like the LS-CBL-0191 is a standard bench spare.

2. Match the camera and grabber configuration — tap rate, configuration mode, output format. The Camera Link compatibility checklist lists what must agree on both ends of the cable.
3. Check the slot against the worked example above; a x1 slot fails in exactly this way.
4. If the image is still blank, follow the no-image probe, stage by stage, which picks up where the self-tests end.

The trigger test and the loopback

Most trigger self-tests pulse the output and expect it back at an input, and the manual's loopback note names the two I/O connector pins to bridge. Without that loopback — or with the camera's trigger wiring still attached — the test fails on good hardware. A frame grabber I/O cable with open leads, such as the LS-CBL-0224, gives you bare wires to bridge at the open end for a clean bench test.

Once the self-test passes, exercise the path for real: the grabber can source a complete trigger pulse train to the camera with no lab equipment, as the trigger pulse train guide shows, which also settles polarity and pulse-width questions before the camera is connected.

Build the evidence pack before the RMA

A vendor takes a board back faster when the pack shows the fault follows the board, not the slot. Collect:

• Exact model and serial, read from the silkscreen and part number — the frame grabber identification guide decodes the markings if the label is worn.
• Driver version, operating system and BIOS settings for each slot used.
• Diagnostic logs from both slot positions, camera disconnected, with the same failures in each.
• The control entry: a known-good grabber that ran clean in the suspect slot, which removes the last doubt on the host side.

Every frame grabber we ship carries at least a 3-year warranty. If the failed board came from us, start at the contact page with the pack attached and we will take it from there.

When the claim confirms a dead board, the replacement line spans Camera Link, CXP-6 and dual 10GigE frame grabbers:

Checklist before the next demonstration

• Bench-run the diagnostics on every new grabber in a known-good slot before it enters a machine.
• Log slot position, BIOS version and driver version on the machine's asset sheet the day the board goes in.
• Keep a known-good spare grabber and a spare camera cable on the shelf; a demonstration is the wrong time for a board's first power-up.
• Re-run the diagnostic suite after every BIOS or driver update, camera disconnected.
• Keep the I/O loopback with the spare cable so the trigger test can run clean.
• Photograph slot order and cabling before pulling anything; the photo settles the "which slot was it" question later.

Parts and next steps

Match the grabber to the camera's interface first, then to a slot with enough lanes. The frame grabbers category lists boards by interface and port count, the accessories finder filters them live, and trigger and I/O cabling sits in the cables category; the system configurator steps through camera, grabber and cabling together, and in-stock items ship within one business day. More host-side procedures live on the systems topic page, and the multi-camera corruption guide is the next read when several boards share one host. If you send us the diagnostic log taken with the camera unplugged, we will tell you which side of the connector the fault is on.