Software Trigger Capture with the Basler pylon SDK (C# / .NET)

When working with industrial cameras such as Basler, you don’t always want to run the camera in free-run mode (continuous acquisition). There are many situations where you need to capture exactly when something meaningful happens, for example:

  • The moment a button on an experimental setup is pressed
  • When a temperature or voltage reaches a certain threshold
  • When an external event occurs in another device or system

In such cases, software-triggered acquisition is extremely useful.

In this article, we’ll look at how to perform software-trigger capture using the Basler pylon SDK in C#, and compare it against free-run / GrabOne() acquisitions using simple stopwatch-based timing.


✅ Environment

Item Value
Camera Basler acA2500-14gm
SDK Basler pylon Camera Software Suite
Lang C# / .NET 8.0 (Windows)

As in previous articles (for example: How to record camera settings alongside captured images (C# / .NET)), we extend the same BaslerCameraSample class and add software-trigger-related functions plus an example test.


🔧 Configuring the Software Trigger

In pylon, software trigger is configured by setting the trigger mode and trigger source as follows:

When you want to capture an image, you call ExecuteSoftwareTrigger() to fire the trigger and acquire a frame at that instant:

Before calling ExecuteSoftwareTrigger, you must start camera streaming with Camera.StreamGrabber.Start(). In other words, the camera must already be armed and grabbing when the trigger is executed.


🔁 Example: Using the Software Trigger

Here is one example of how to use the software trigger. There are many ways to structure this, but using the existing implementation from earlier articles, we follow this sequence:

  1. Enable software trigger mode
  2. Start streaming
  3. Fire the software trigger
  4. Wait for frame acquisition (via ImageGrabbed) and then stop streaming

Because there is a delay between firing the trigger and the ImageGrabbed event, we wait until the handler confirms that a frame was actually acquired before stopping streaming.

Here, BufferedImageQueue refers to the queue filled by the OnImageGrabbed event handler (as implemented in the earlier event-driven capture article).


⏱ Experiment: Software Trigger vs “Just call GrabOne()

You might wonder:

“What’s the difference between using a software trigger and simply calling GrabOne() after an event occurs?”

To test this, we extend ExecuteSoftwareTriggerTest to also measure the time taken by a plain GrabOne() call and compare the two.


📊 Results

On my test environment (Basler acA2500-14gm, GigE, AMD Ryzen 9, Windows), software-trigger capture achieved a faster time-to-image than a plain GrabOne().

This is likely because the camera is already streaming and armed, so the sensor doesn’t need to be restarted for each frame.

Summary:

Mode Acquisition Time Characteristics
Software trigger ~112 ms Faster image acquisition; precise knowledge of when the trigger occurred
GrabOne ~193 ms Simple to implement; trigger timing is not strictly known

📝 Summary

  • Software trigger is ideal when you want to capture semantically meaningful moments:

    • e.g., synchronization with experimental data, test equipment, or external signals
  • Compared to GrabOne():

    • Software trigger can reduce the delay between event and image acquisition
    • It also lets you know exactly when the trigger was fired

In the next article, we’ll look at how to display camera images in WPF, using the same design that I’m adopting in my in-development camera configuration management tool.


Author: @MilleVision


🛠 Full Sample Code Project(With Japanese comment)

All sample code introduced in this Qiita series is available as a C# project with unit tests on BOOTH:

  • Includes unit tests for easy verification and learning
  • Will be updated alongside new articles

👉 Product page

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA