Camera Link frame grabber detection and integration

A Camera Link board can hold a healthy driver, enumerate cleanly in the operating system, and still be invisible to the acquisition application: no device in the browser, no camera, no frames. In most cases that is an integration-path fault, and you can prove it without ordering a single part. This sequence walks you through five ordered tests: a native-utility baseline, the port math the Camera Link standard fixes, the application's adapter path, a version matrix, and a bounded smoke test with real numbers.

1. Which layer is actually failing

Detection is four layers, and each test names the failing one. Test them separately and an empty browser stops being a mystery.

GenICam standardizes how device features are described and accessed; GenTL standardizes the transport-layer producer an application loads. Neither standard promises that a Camera Link board appears in every browser, because most Camera Link applications reach the board through the grabber maker's acquisition adapter instead. That is why one viewer lists the camera and another shows nothing: the SDK support differences between viewers explain the split.

For the broader software decision, read the acquisition software integration options; keep the physical Camera Link board compatibility checks separate from this visibility fault.

2. Prove the hardware in the native utility first

Ten minutes in the manufacturer's own tool settles the hardware question for the whole investigation:

1. Record the device status and driver version the operating system reports for the board. An error code here ends the software hunt: reinstall the driver package and retest.
2. Close every acquisition program, viewers in the system tray included, so no other process owns the board.
3. Open the native utility that shipped with the board's software package and let it enumerate the board.
4. Load the camera file for your camera and grab 10 consecutive frames in free-run.
5. Open the utility's serial tab and talk to the camera at the standard's default 9600 baud; a reply clears the serial channel too.

Reading the result is binary. Frames in the native utility: hardware, cable, camera file and driver are proven, and you jump to section 4. No frames: stay here. Check that the camera file matches the camera's tap count, that the 26-pin cable seats at both ends, and that Medium, Full and 80-bit cameras carry the second cable; the standard runs those widths over two connectors, so a single cable passes only Base.

If the installation itself is incomplete, run the driver package detection checks. If the board enumerates but will not initialize, go to the firmware and runtime initialization checks.

3. The numbers the Camera Link standard fixes

The Camera Link 2.0 standard, finalized in February 2012, defines the whole camera-to-grabber link: 26-pin MDR or SDR connectors, four LVDS camera-control lines (CC1 to CC4), a serial channel that defaults to 9600 baud, and image data organized as 8-bit ports. The grabber's data bus is built from those ports, and a camera file maps the camera's taps onto them. The configurations stack the ports:

The standard's pixel-clock ceiling is 85 MHz, so throughput follows directly:

Worked example: an 8-tap camera moving 8 bits per tap at an 80 MHz pixel clock carries 64 x 80 MHz = 5120 Mbit/s, or 640 MB/s. That fits Full's 680 MB/s ceiling at 85 MHz and sits far above Base's 255 MB/s. If the native utility delivers that camera's frames, every one of those numbers already works on your bench, and a browser that stays empty sits above a proven link.

4. Open the integration path the application names

An application reaches a Camera Link board by exactly one of three routes, and its integration guide states which:

These routes are alternatives, not synonyms. Installing a GenTL producer does not enable the acquisition adapter, and an adapter file on disk is inert until the application loads it. The application log settles the question: it names the missing library, the version it wanted, or the bitness it rejected.

The frame-grabber acquisition overview covers how the board moves pixels; the route your application uses is this decision.

5. Build the version matrix before you change anything

Write the six rows down first; uninstalling by trial is how working setups get destroyed.

A 64-bit application loads 64-bit adapter and runtime libraries; a 64-bit operating system does not make them appear. A package's advertised version is not the installed one either, so read the installed component list rather than the installer filename. Install the application, adapter, runtime and driver as the matched set from one row of the support matrix, then retest with the minimal sample below.

6. Isolate loading with the smallest sample

Launch the smallest example program the integration ships, in the same bitness as the application, and check in this order:

• Component discovery: the adapter or producer sits where the application expects it.
• Dependency load: the log names a missing library or a bitness error; that message is the fault.
• Search path: for a producer route, the application reads the path its guide names.
• Ownership: no viewer, service or tray icon still holds the board; use the device access-conflict checks.
• Licensing: the vendor's license tool reports the entitlement the integration needs.
• Device selection: the sample opens the interface you mean, not a stale saved identifier.

The first failing entry in that list is your fault; every message after it is a consequence. Never copy libraries into an application folder to silence a dependency error. That mixture loads today and fails during production capture.

7. Smoke-test with numbers, then trust it

Enumeration is not acceptance. Grab real frames through the application path with a bounded test:

1. Load the camera configuration that already worked in the native utility and free-run it.
2. Request 100 frames. At 20 frames/s the nominal run is:

3. Set the whole-sequence timeout to at least three times nominal, 15 s for this run, and treat a per-frame timeout as a separate quantity with its own meaning.
4. Record requested frames, received frames and incomplete buffers. Accept the run only at 100 received and 0 incomplete.
5. Repeat the open-acquire-close cycle 3 times, restart the application, and run once more. That proves the integration releases the board and survives a cold start.

These counts are the starting point; scale the frame count to your line rate and retest. If frames stop mid-run, the acquisition timeout diagnosis takes over. Only after this test passes should external triggering, processing and the production sequence return.

8. When the hardware really is the answer

Replace parts only after the native utility fails too, or when the interface itself is wrong for the application. Two checks come first: the camera file's tap count fits the configuration the board runs, with Base on one cable and Medium and above on two, and the connector pair matches both endpoints, since SDR and MDR housings do not mate.

The MV-GC1102IOL is catalogued as a Camera Link frame grabber for that hardware route.

For the link itself, the LS-CBL-0191 is catalogued as a Camera Link cable with SDR connectors at both ends.

Browse frame grabbers by interface and camera cables by connector; the accessories finder narrows both lists before you commit.

9. Five fixes that are usually wrong

• Another browser. If the application integrates through its acquisition adapter, browser troubleshooting targets the wrong layer entirely.
• A cable swap. Frames in the native utility already prove the cable for that configuration; replace it only after the native path fails.
• The newest runtime. Install the matched set from the support-matrix row; version conflicts above the driver are invisible to the hardware and survive any swap.
• A firmware flash. Discovery faults live in software layers. Flash only on a listed requirement, with the manufacturer's recovery procedure at hand.
• Copying libraries by hand. A hand-built mixture of runtime files loads in the shop and fails under production capture rates.

10. Evidence to send when you escalate

Collect this once and a support request gets answered in one pass:

• Operating-system device status and the driver version actually installed.
• Native utility result, split into enumeration and acquisition.
• The integration guide's named route: producer, adapter or native API.
• The six-row version matrix from section 5.
• The first loading error verbatim, with its log context.
• Smoke-test counts: requested, received, incomplete.

Send the matrix, the camera interface requirements and the native result through the support contact page, or start a matched hardware set in the accessories configurator.