External trigger disk logging crashes: isolate the cause

A recording application can fail even when the camera, trigger source, and image acquisition path work correctly. Disk writing, preview rendering, and buffer handling introduce separate failure points that often appear only during externally triggered capture. This troubleshooting procedure separates those paths without changing the required relationship between triggers and saved frames. Use it when acquisition crashes, stops unexpectedly, or produces fewer recorded frames than the machine requested.

1. Define the failure and the frame contract

Start with a precise requirement: each valid external trigger must produce one completed image and one saved frame. Identify whether the trigger acts on the camera, the frame grabber, or an acquisition software object. Those mechanisms are not interchangeable. In particular, triggering reception of a free-running video signal does not necessarily trigger the sensor exposure.

Record the following before changing settings:

• Trigger source, selected input, edge polarity, and pulse timing.
• Image dimensions, delivered pixel format, and bytes occupied by each buffer.
• Frames requested per trigger and the documented repeat-count semantics.
• Application, acquisition runtime, driver, and device firmware versions.
• Whether preview, conversion, compression, and disk logging are active.
• The last completed frame identifier, write completion, and error message before failure.

Separate a process crash from an acquisition timeout or a recording error. A process that exits needs crash diagnostics; a running application awaiting an image needs trigger and acquisition-state checks.

The hardware-trigger frame-rate guide explains timing limits. Establish those limits first if frames are already missing before recording begins.

2. Separate acquisition, recording, and preview

Change one subsystem at a time. Keep the image format, trigger source, and one-frame-per-trigger setting unchanged throughout the initial tests.

Run each test with a repeatable pulse sequence. Start with widely separated triggers, then use the intended production timing, including its fastest expected burst.

For each run, count generated triggers, accepted triggers where available, completed images, and successfully written frames. Do not treat a successful file-open operation as proof that frames reached the file.

3. Prove acquisition to memory first

Disable preview, disk logging, image analysis, and unnecessary pixel conversion. Retain only the processing needed to receive images and release their buffers correctly.

1. Configure the documented external trigger mode and one frame per trigger.
2. Allocate the receive buffers required by the acquisition API.
3. Arm acquisition and wait for its documented ready state.
4. Start the controlled trigger sequence.
5. Count completed images and inspect their status and identifiers.
6. Stop the trigger source, finish outstanding transfers, and stop acquisition through the supported control path.

Use bounded storage. For a long test, count and release images rather than retaining every frame indefinitely. Keep a small sample only when the SDK permits a safe copy.

If this test crashes, disk logging is not necessary to reproduce the fault. Investigate acquisition state transitions, driver compatibility, and buffer lifetime before changing storage hardware.

If it passes, retain that configuration as the acquisition baseline. The offline image-saving guide covers building a reusable image set without making recording part of the initial acquisition test.

A successful low-rate run does not establish production readiness. Repeat the memory-only test at the shortest intended trigger interval and for enough frames to cross the usual failure point.

4. Test the writer independently and calculate its load

Feed the recorder previously captured images with the same dimensions, pixel format, and memory layout as the live stream. This tests writing without external trigger handling.

Check that the writer accepts the delivered format. A packed sensor format, padded image rows, or a monochrome image may need conversion before a particular recording format can accept it. Include that conversion in the independent writer test.

For an uncompressed image payload, use:

These are payload estimates. Row padding, file metadata, conversion copies, and writer buffers can increase actual memory use or disk traffic.

Worked example

Assume a hypothetical image contains 1920 × 1200 pixels stored at 1 byte per pixel, with 40 triggers per second:

Here, MB means 1,000,000 bytes. A run containing 300 frames carries approximately 691.2 MB of image payload before file overhead.

A writer stall lasting 0.5 seconds creates this additional backlog:

That queue only covers the stated stall. It cannot compensate indefinitely if average writing speed remains below average incoming data rate.

Measure write completion and queue depth, not just average disk speed. If the independent writer fails, investigate its input format, error reporting, output destination, and documented file limitations before reconnecting live acquisition.

5. Add recording, then add preview

Reconnect the proven acquisition path to the proven writer through a bounded queue. Keep preview disabled initially.

Track queue depth over time. A steadily rising queue indicates that the consumer cannot match the incoming workload. Sudden jumps suggest intermittent delays, such as conversion pauses or slow writes. Record both the largest queue depth and the longest observed write delay.

Only add preview after live recording passes. Preview may introduce pixel conversion, image scaling, rendering, and additional buffer references. A failure that appears only with preview enabled points toward that added work or its interaction with shared image memory.

A display can often update less frequently than recording. For example, displaying every fourth completed image reduces display update frequency without changing the acquisition or recording requirement. Apply that selection only to the display path; all required images must still reach the recorder.

The callbacks and buffer-queues troubleshooting guide explains why acquisition callbacks should remain short, including in a single-camera application.

6. Check the supported software combination

If acquisition alone fails, or the combined path crashes despite adequate throughput, check the complete compatibility chain:

• Operating system and application architecture.
• Acquisition application and its adaptor or transport layer.
• Driver and runtime libraries actually loaded by the process.
• Frame-grabber firmware and camera firmware, where applicable.
• Supported pixel formats and external-trigger modes.

Use the manufacturer's documentation and supported downloads, or those supplied by its authorized distributor. Review release notes for fixes involving external triggers, recording, callbacks, and shutdown. Do not assume that the newest component works with every older component.

Compare the installed versions with the libraries actually loaded. An application can load an older runtime from a different installation directory even after an update.

Where available, reproduce acquisition in the manufacturer's diagnostic application using equivalent settings. Success there narrows the investigation toward application integration, but does not prove that recording and preview combinations are supported.

For failures during setup rather than after several captured images, follow the frame-grabber initialization checks. Resolve missing runtime components before tuning the recorder.

7. Audit buffer ownership and shutdown

A callback-based writer can be a legitimate alternative when the documented API supports it. However, moving file writing into a callback is not automatically safe.

An acquisition buffer may belong to the driver and remain valid only until it is released or requeued. Passing a reference to another thread does not extend that lifetime unless the API explicitly provides ownership transfer or retention.

Use one documented ownership strategy:

• Copy the required image data into application-owned memory before releasing the acquisition buffer.
• Retain the acquisition buffer through an explicitly supported API, then release it after the consumer finishes.

Keep file opening, compression, and potentially blocking writes outside the acquisition callback. Submit owned data to a bounded writer queue instead. If that queue fills, report the condition and request an orderly stop through the supported control path. Do not silently discard inspection frames.

On shutdown, stop new triggers where the application controls them, finish or explicitly account for pending transfers, and prevent further queue submissions. Drain the writer queue, finalize the file, then release resources in the documented order.

The image-buffer ownership guide covers lifetime errors. If failure occurs specifically during teardown, use the acquisition-stop crash checks.

8. Do not confuse a diagnostic change with a fix

Increasing frames per trigger can change the internal acquisition path and make a crash disappear. That is useful diagnostic evidence, but it changes the capture contract.

If each trigger previously requested one frame, requesting three frames produces a different image sequence. Saving only the first image afterward does not establish that exposure timing, buffer demand, or subsequent trigger acceptance stayed equivalent.

Similarly, free-running capture followed by software frame selection is not automatically equivalent to externally triggered exposure. It may be appropriate for another application, but it needs its own timing analysis.

The multi-image capture guide addresses tasks that genuinely require an image set. Do not adopt that configuration solely to hide a one-frame recording failure.

Accept a workaround only after verifying its documented behavior and demonstrating the original trigger-to-image requirement. Otherwise, keep it labeled as a diagnostic configuration while pursuing a supported software correction.

9. Verify the repair before ordering hardware

Finish with a repeatable acceptance run at the intended image format, trigger pattern, recording destination, and preview configuration.

• Count the whole path: compare sent triggers, accepted triggers, completed images, and written frames using documented counter meanings.
• Inspect identifiers: investigate gaps while accounting for counter resets and rollover.
• Drain the queue: a finished acquisition is not a finished recording while frames remain queued.
• Reopen the file: verify its readable frame count and inspect images from the beginning, middle, and end.
• Repeat lifecycle tests: include normal stop, restart, writer errors, and the documented response to queue exhaustion.
• Record the configuration: retain versions, settings, measured rates, and the test result.

For a clean one-frame-per-trigger run, all corresponding counts should agree after draining. An accepted-trigger count alone cannot reveal input pulses ignored before acceptance.

Do not replace hardware merely because recording crashes. If a replacement is justified, compare frame grabbers in the accessories finder against the actual camera interface and supported software.

The MV-GC1102IOL is listed with a Camera Link interface.

The MV-GE1104 is listed with a GigE interface.

These interface listings do not establish trigger compatibility or application support. The frame-grabber acquisition guide explains interface-specific integration. If changing the camera is necessary, compare area scan cameras in the camera finder rather than assuming an existing card supports the replacement.

For the next step, send your test matrix, version list, image format, and trigger counts through application support. If hardware replacement is confirmed, use the accessories configurator to identify the required interface and supporting parts.