Frame grabber in use: detect and handle access conflicts

A camera appears in the device list, but your application cannot open it. Another program may own acquisition, yet the same symptom can follow a driver fault, an unsupported access mode, or incomplete cleanup after an earlier session. This troubleshooting workflow helps you distinguish those cases without treating discovery as an ownership test. You will identify the contested resource, interpret documented access errors, and coordinate applications without disrupting an active inspection.

Start with the failed operation, not the device list

Discovery answers whether a software stack can enumerate a device. It does not universally answer whether your application can control that device or receive its images. Some implementations keep occupied devices visible; others may omit them under particular conditions.

An empty device list therefore does not prove that another process owns the hardware. Likewise, a visible device does not prove that acquisition access is available.

Record the exact point of failure before changing anything:

• Enumeration: the device is absent from the list.
• Open: creating a device handle fails.
• Configuration: opening succeeds, but a feature write fails.
• Stream setup: the device opens, but a stream or buffer allocation fails.
• Acquisition: streaming starts, but images do not arrive.

For a visible device that cannot be opened, the closest companion is GenTL camera open failure after successful discovery. If opening succeeds and frames later disappear, use the separate workflow for intermittent camera acquisition failure.

Identify what is actually being reserved

The contested resource may be a camera, a board, an acquisition channel, a stream, or a driver-managed subsystem. Do not assume that every camera connected to one board shares the same ownership boundary.

Start by recording the camera identity, board identity where available, selected channel, requested access mode, and application process. Use stable identifiers exposed by the documented API rather than relying only on list positions. Enumeration order can change between sessions.

Access modes also differ across software stacks:

These are access patterns, not capabilities guaranteed by every camera or frame grabber. A second client may be able to read identification information while being unable to change exposure or start acquisition.

Shared access also does not automatically mean independent operation. Two applications changing the same trigger configuration can interfere even when both open successfully.

Check likely causes in a controlled order

Begin with a known acquisition program that may already be running. Include minimized viewers, background services, development environments, and earlier instances of your application. Check only systems and processes you are authorized to administer.

The table below separates an ownership conflict from failures that can look similar.

For the final case, follow why one viewer works and another fails. If failure occurs during board startup, use frame grabber initialization checks.

Change one variable per test. Closing another application, updating a driver, and changing the cable together may restore operation, but it will not identify the cause.

Treat documented open errors as evidence

Use symbolic error categories from the installed SDK documentation, not guessed numeric codes or fragments of translated messages. Keep the original status, operation name, and diagnostic text in the log.

A specific resource-busy status is strong evidence that the requested reservation is unavailable. A generic open failure is not. It may represent invalid arguments, unsupported access, missing permissions, or a lower-level initialization problem.

A separate availability query can help explain state, but it cannot reserve the resource. Another process can acquire ownership between your query and your open call. This is a check-then-act race.

Prefer a workflow that attempts the documented open operation and handles its outcome directly. The open call is authoritative for that attempt, provided it requests the access your application actually needs.

A language-neutral control flow is:

request the documented access mode
attempt to open the selected resource
if successful:
    retain the handle for the intended session
otherwise:
    record the operation and exact status
    classify only documented ownership errors as contention
    send other errors to the appropriate diagnostic path

Do not open and immediately close the hardware merely to publish an available flag. That flag becomes stale as soon as you release ownership. Opening can also have documented side effects, so use a supported status query when you need observation without control.

Reproduce the conflict with a deliberate handover

Use a controlled maintenance test rather than interrupting an active production inspection. Confirm that temporarily stopping image acquisition will not defeat a machine safety function or remove required process supervision.

1. Start the designated acquisition owner and confirm that it holds the intended camera or channel.
2. From the second application, request the access mode your production workflow requires.
3. Record whether enumeration, open, configuration, or stream setup fails, including the exact documented status.
4. Ask the owner to stop acquisition and release resources through its normal shutdown path.
5. Repeat the second application's operation without changing its configuration.
6. Repeat the handover in the opposite direction to check both cleanup paths.

A failure while ownership is held, followed by success after orderly release, supports an access-conflict diagnosis. It does not prove that every future open failure has the same cause.

If the same test still fails after release, stop repeating ownership checks. Investigate the actual error category, software compatibility, and resource lifecycle instead.

Release resources through the documented lifecycle

Stopping acquisition and releasing ownership are different operations. A stopped stream may leave a device handle open, and a closed viewer window may leave its acquisition service running.

Follow the SDK's documented teardown order. A typical lifecycle includes stopping new acquisition work, waiting for active operations to finish, returning outstanding buffers, closing stream resources, and closing the device handle. The exact order and buffer responsibilities vary by API.

Pay particular attention to asynchronous code. A callback can still be executing while the main application begins shutdown. A worker thread may retain a reference after the interface reports that acquisition has stopped.

Check these cleanup points:

• Every successful open has a matching close on normal and error paths.
• Callback subscriptions and acquisition workers stop according to the documented sequence.
• Outstanding image buffers are returned before their owning resources are destroyed.
• Automatic reconnect does not immediately reopen a device being handed over.
• Cleanup failures are logged rather than hidden by a generic shutdown message.

After a crash, use documented recovery procedures. There is no universal delay after which every driver must release an abandoned resource.

Coordinate applications and bound any retries

When several applications need images, the cleanest architecture is often one acquisition owner with explicit image distribution. Consumers request images or results from that owner instead of independently changing camera state.

Define who controls exposure, trigger settings, acquisition start, and recovery. Also define whether a slow consumer receives queued images, the latest image only, or an explicit dropped-image notification.

If applications must alternate ownership, use a handover protocol. The current owner acknowledges completed release before the next client requests access. Application-level coordination reduces collisions, but it does not replace the driver's own access enforcement.

Retries should be limited to documented transient conditions. Do not retry every open failure indefinitely.

For a hypothetical SDK whose configured open timeout is documented and honored, the retry budget is:

Suppose you allow 3 open attempts, each limited to 1 s, with delays of 0.25 s and 0.50 s:

This is an application example, not a hardware specification. Scheduling and subsequent initialization add time. If the open call lacks a documented bound, this calculation cannot establish a recovery deadline; investigate supported cancellation or recovery instead.

Check hardware requirements without assuming sharing support

Replacing hardware is not the first remedy for an ownership problem. Confirm the transport and documented software access model before selecting another card or camera.

The MV-GC1102IOL is listed with a Camera Link interface. The MV-GE1104 is listed with a GigE interface. Those interface descriptions do not establish whether either device supports your proposed multi-application workflow.

Use the frame grabbers category and accessories finder to identify transport candidates. Confirm access modes, reservation scope, operating-system support, and recovery behavior in the documentation for the intended driver package.

For a camera-side change, use the area scan cameras category and camera finder. A different camera interface does not, by itself, solve application coordination.

A supported shared mode may be appropriate when clients have compatible responsibilities. When consumers need different crops or processing, distributing images from one owner is often preferable to giving each consumer configuration authority.

Verify the fix and record the ownership contract

Before returning the system to operation, check the complete handover rather than only the first successful open:

• Confirm the required application can acquire valid images after ownership transfers.
• Confirm the previous owner remains closed and does not reconnect unexpectedly.
• Verify configuration after handover, particularly trigger and exposure settings.
• Exercise normal shutdown and a documented error-recovery path.
• Confirm unrelated cameras or channels remain operational.
• Record which application owns acquisition and how maintenance software requests access.

The useful outcome is not an always-accurate busy indicator. It is a repeatable ownership contract, precise error handling, and predictable release behavior.

For component selection, start with the accessories configurator. For an unresolved conflict, send the transport, software versions, requested access mode, exact error, and handover observations through application support.