Frame grabber SDK support: why one viewer works and another fails

A camera can deliver clean images in its hardware configuration utility while remaining unavailable to a separate vision application. That usually points to a difference between acquisition software paths, not immediate proof of faulty hardware. This troubleshooting sequence is for engineers commissioning a frame grabber with a separate vision SDK. It helps you distinguish missing integration support, installation problems, device ownership and recording limits before changing working hardware.

What the working viewer actually proves

A native hardware utility normally uses the acquisition stack supplied for that hardware. A separate vision SDK may need its own integration adapter, a compatible runtime, or a supported GenTL producer before it can acquire images.

Successful capture therefore validates a particular combination of hardware, settings and software. It does not establish compatibility with every application installed on the computer.

Start by separating the camera, board driver and application integration layers. The acquisition software compatibility guide explains the broader integration choices; the checks below focus on the adapter between working hardware and your application.

Check for explicit SDK adapter support first

When the native utility works but the application cannot open the hardware, check these causes in order:

1. The SDK does not support the exact frame grabber.
2. The required integration adapter is absent or not selected.
3. The adapter is installed, but its version or dependencies are incompatible.
4. Another application owns the device.
5. The device opens, but acquisition or recording settings are wrong.

Begin with the SDK's supported-hardware documentation. Match the exact board model and revision where the documentation distinguishes revisions. Support for a related board, the same camera transport, or another product from the same family is insufficient evidence.

Find out which acquisition route the SDK expects. Possibilities include a dedicated board adapter, a supported GenTL producer, or another documented interface. A camera feature description alone does not identify the required host-side integration.

Ask the SDK provider to confirm these points:

• The exact board is supported by the proposed adapter release.
• The operating system and application architecture are supported.
• The required board driver, runtime and firmware versions are identified.
• Your intended acquisition mode is covered, including triggering where needed.

If support is missing, changing camera settings will not create it. The legitimate options are a released integration package, a documented alternative acquisition interface, or a different supported hardware/software combination.

Match the complete software version chain

Once support is confirmed, make a version inventory before installing anything else. Record the operating system build, application architecture, vision SDK release, integration adapter release, board driver and runtime versions. Include firmware versions when the compatibility documentation requires them.

The correct combination is the documented combination, not necessarily the newest release of every component. A recently updated SDK can be incompatible with an older adapter, while an adapter built for another runtime may fail during loading.

A 64-bit application generally needs compatible 64-bit in-process modules and dependencies. Installing a 32-bit integration package does not make that package loadable inside a 64-bit process. Some systems also install separate components for each architecture, so confirm which package your application actually uses.

Use only downloads supplied by the manufacturer or its authorized distributors. Follow the documented installation order, restart requirements and configuration procedure. Do not assemble an installation by copying individual libraries from unrelated computers or unofficial file-sharing locations.

If the SDK uses GenTL, verify the producer version, architecture and discovery configuration specified for that integration. The GenTL producer compatibility checks help distinguish discovery problems from missing-function errors.

For failures before the board becomes usable in any application, follow the separate frame grabber initialization troubleshooting sequence. That is a different starting condition from a board that already streams successfully in its native utility.

Diagnose adapter loading before camera settings

An acquisition file can represent a software integration module rather than a saved set of camera settings. Its presence does not mean it can be loaded by every SDK version or used with every frame grabber.

Classify the error by the stage at which it occurs:

Use the SDK's smallest documented acquisition example before testing your full application. It removes custom configuration, processing and recording code from the investigation.

Preserve the complete error text and any underlying loader error. A generic failure dialog may conceal a missing dependency, unsupported interface version or permission problem.

Confirm that the package is installed in its documented location. Use the vendor's approved configuration or repair procedure rather than moving adapter files until the application finds one. If licensing is reported, check entitlement and activation through the documented licensing tools or contact support; reinstalling an unrelated adapter is not a licensing remedy.

Release device ownership, then test live acquisition

Close the native viewer before opening the device in the SDK. Some acquisition stacks allow only one controlling application at a time. A minimized viewer or background acquisition service may still hold the device.

Use a controlled test sequence:

1. Exit all acquisition applications and stop only documented, nonessential acquisition services.
2. Open the hardware in the native utility and verify live images.
3. Save or record the working settings, then close the utility completely.
4. Launch the SDK's minimal acquisition example and select the documented adapter.
5. Start with a documented free-running configuration, if supported, before adding external triggering.
6. Confirm that received frame counters advance, rather than relying on a single displayed image.

Change one setting at a time. Keep exposure, image dimensions and pixel format consistent where the integration permits it. Note any settings the SDK applies automatically when opening the device.

If continuous acquisition works but individual capture requests time out, investigate the acquisition sequence rather than reinstalling the board. The one-shot capture timeout guide explains why a working stream can still behave differently under software triggering.

The frame grabber acquisition guide provides the wider bring-up sequence once the integration layer is available.

Prove the stream before testing recording

Recording adds memory copies, possible pixel conversion, encoding, file handling and storage writes. Test those only after the SDK receives physical frames reliably.

For an initial recording test, disable optional processing and overlays. Use a documented raw or uncompressed output path where available. Keep the test short enough to inspect frame counts, timestamps and file contents without creating an unnecessarily large dataset.

Estimate the uncompressed payload using the format actually stored in memory:

For a hypothetical monochrome stream, assume an image contains 2,048 × 2,048 pixels, stored as one byte per pixel, at 50 frames/s:

• Frame size = 2,048 × 2,048 × 1 = 4,194,304 bytes.
• Payload rate = 4,194,304 × 50 = 209,715,200 bytes/s, or 200 MiB/s.
• A 10-second recording contains 2,097,152,000 payload bytes, about 1.95 GiB.

These are payload estimates, not a complete storage specification. Row padding, metadata, file structure and intermediate copies can add demand. Packed sensor data may also become a larger representation after conversion.

At that assumed rate, a fully usable 256 MiB queue holds 256 ÷ 200 = 1.28 seconds of incoming images. It can absorb a brief pause, but it cannot compensate for storage that remains slower than acquisition.

Compare acquired, queued and written frame counts. A smooth preview does not prove every frame reached the recording file. For offline validation, use the workflow in saving camera frames for repeatable testing.

Choose the hardware interface without assuming software support

The interface remains an essential purchasing check, but it is only one part of compatibility. Review frame grabbers and the accessories finder alongside the SDK's supported-hardware documentation.

The MV-GX1008 is listed with a CoaXPress interface. Its catalog interface identifies the hardware transport, not a guarantee that a particular third-party SDK has an adapter for it.

The MV-GC1102IOL is listed with a Camera Link interface. Confirm the application's documented integration route before selecting it for an existing software project.

These are interface examples, not claims of compatibility with your application. Neither a category listing nor a product card replaces the SDK provider's support confirmation.

When replacing the camera as well, compare area scan cameras through the camera finder. Preserve the required transport, image format and acquisition behavior rather than treating resolution as the only selection criterion.

When the missing-adapter explanation is wrong

Do not keep reinstalling integration packages after you have evidence that the adapter loads and receives physical frames. Move to the layer implicated by the symptom.

• The SDK receives images, but your application does not: compare application startup settings, selected device identifiers and acquisition order with the working SDK example.
• Capture works until triggering is enabled: check trigger source, mode, signal arrival and acquisition readiness. The hardware trigger line configuration guide addresses that branch.
• Only the display looks wrong: verify pixel interpretation, stride and conversion before assuming transport corruption.
• Only recording fails: separate acquisition, processing and disk writes. The triggered recording crash checks help isolate failures introduced by logging.
• The native viewer also stops working: return to hardware initialization, cabling and the supported board runtime instead of treating the problem as application-only.

A useful diagnosis explains both the failing test and the working test. If a proposed fix cannot explain why the native utility succeeds, gather more evidence before replacing components.

Build a support case and an ordering checklist

Before requesting an integration package or ordering replacement hardware, collect a reproducible record:

• [ ] Exact camera and frame grabber identities, including relevant hardware revisions.
• [ ] Operating system, application architecture and all acquisition software versions.
• [ ] The supported-hardware entry or written compatibility confirmation.
• [ ] Adapter installation source and the documented acquisition interface selected.
• [ ] Complete error text, logs and the stage where acquisition stops.
• [ ] Results from the native utility and the SDK's minimal example, tested separately.
• [ ] Image dimensions, stored pixel format, acquisition rate and triggering mode.
• [ ] Received and written frame counts for any recording failure.

Keep a record of the working software combination after commissioning. Recheck adapter compatibility before upgrading the SDK, board driver or firmware, and retain a vendor-supported recovery path.

If you are selecting components, start with the accessory configuration step. For help reviewing the acquisition path, send the version inventory and test results through applications support. Confirm software support before committing to replacement hardware.