Impact Acquire SDK C
|
Since Impact Acquire SDK and the Balluff devices provide a huge variety of functionality, it will be helpful to use this page as a starting point which leads through a number of common image acquisition and configuration tasks.
The summarized code samples will show the most common cases and can be used as a base for an own image acquisition using the Impact Acquire SDK.
A very common task is to acquire various images continuously to use them e.g. for video streams, continuous analysis or displaying purpose. This purpose is a bit more complex than acquiring just a single frame, but usually not that complex.
The following samples will illustrate how simple continuous acquisitions can be realized.
In some cases simple continuous acquisitions are not sufficient since the image data should be processed or stored within the application. The complexity of such an application depends on the task.
To modify device settings e.g. exposure time or gain, there are different approaches depending on interface layout supported by the used device. The two different interface layouts are 'GenICam' and 'Device Specific'. To get an idea which interface is supported by which device, please refer to the chapter Which Interface Is Supported By Which Device?.
Since most Balluff/MATRIX VISION devices support the GenICam™ interface layout, the following examples will be helpful. They will explain how device properties are changed in a convenient and safe way.
Beginning with the release of 2.49.0 of Impact Acquire firmware updates for all devices still active can be applied in a rather convenient way by using a high level firmware update API. This API is available for every supported programming language. For object orientated languages a FirmwareUpdater class will be part of the SDK and code snippets can be found in the corresponding documentation of the class.
Beginning with release 2.35 of the GenICam™ device firmware a growing number of device models now support the mvBlockscan
mode allowing to transmit multiple images as one thus using a single transfer block for transporting several consecutive frames from the same AOI reducing the overall overhead needed for transporting and reporting a frame thus in total reducing the CPU load on the host for certain scenarios.
The properties to control this feature are
The maximum number of frames that can be combined that way by the device might be limited for various reasons but depending on the use-case the performance benefit can be significant.
BVS CA-UB and mvBlueFOX2 USB devices allow to put themselves into a mode where less power is consumed. This can be used when no image acquisition is currently active and helps to reduce the overall power consumption of the system in idle mode.
The PowerMode property with the SystemSettings list can be used to configure this behaviour. It is an enumerated property that accepts values of type TDevicePowerMode
Apart from allowing to generate arbitrary test images in every pixel format supported by Impact Acquire the mvVirtualDevice package can also be used to capture images from a defined folder on the hard disk drive. This can be extremely useful when prototyping without real hardware or to feed defined test images into an algorithm in way the capture engine seems to provide these images. To do that just a couple of properties must be set appropriately:
The images are captured from the directory specified by the application in a Round-Robin fashion so once the last image from the folder has been captured the next image will be the first again. Whenever for some reason an image cannot be imported from the hard disk an artificial test image will be generated instead.
To get an idea how callbacks are implemented, the following sample will be helpful:
How to set up the way Impact Acquire connects to and enumerates third party GenTL producers is described here: Setting Up The Framework For Third Party GenTL Producer Usage