Image Acquisition Interface for GenICam GenTL compliant cameras

This page provides the documentation of the universal HALCON GenICamTL interface for accessing all GenICam GenTL compliant cameras. Registered customers can download the latest revision of this interface from the MVTec WWW server.

• Intel compatible PC with Windows 7 (32-bit or 64-bit) or newer that is also supported by the used GenTL Producer, XP SP1/Vista/7/8, Windows XP/Vista/7/8 x64, also WoW64 (using 32-bit HALCON on 64-bit Windows), Linux with kernel 2.6 (or higher) , or macOS.
• Successfully installed GenICam GenTL Producer. The corresponding .cti file must be located in one of the directories specified by the environment variable GENICAM_GENTL32_PATH or GENICAM_GENTL64_PATH, respectively. Otherwise, the full path to the GenTL Producer has to be specified when opening the device.
• Depending on the used transport layer make sure that you have access to the device. Follow all requirements and recommendations specified by the respective GenTL Producer(s) to guarantee flawless and effective access to the device(s). Especially for (Gigabit) Ethernet the following points have to be checked:
  • It is recommended to use a PCIe network adapter which supports jumbo frames. Please configure the network adapter accordingly, e.g., to a MTU value of 9000. Furthermore, the camera should be connected directly to the network adapter to avoid interference with other network traffic. Please be aware that networking equipment like switches not necessarily supports Jumbo frames.
  • If you are using a firewall please make sure that your firewall settings allow communication with the camera for discovery, control and streaming, depending on your used transport layer. For Windows the easiest way to do this is to allow the application (i.e. HDevelop, or your compiled application) at the firewall.
• GenICam GenApi. The corresponding files are part of the HALCON GenICamTL package and are located in the directory genicam within the HALCON base directory %HALCONROOT%. See section GenICam GenApi for more details.
• Windows: HALCON image acquisition interface hAcqGenICamTL.dll or hAcqGenICamTLxl.dll, respectively. If you have properly installed the interface, all these DLLs should reside in bin\%HALCONARCH% within the HALCON base directory %HALCONROOT% you have chosen during the installation of HALCON.
  Linux: HALCON image acquisition interface hAcqGenICamTL.so or hAcqGenICamTLxl.so, respectively. If you have properly installed the interface, the shared objects should reside in lib/$HALCONARCH within the HALCON base directory $HALCONROOT you have chosen during the installation of HALCON.
  macOS: HALCON image acquisition interface hAcqGenICamTL.dylib or hAcqGenICamTLxl.dylib, respectively. If you have properly installed the interface, the shared objects should reside in the HALCON framework /Library/Frameworks/HALCON.framework or the HALCON XL framework /Library/Frameworks/HALCONxl.framework in the Libraries subdirectory.
• The default acquisition mode assumes the computer is fast enough to process all buffers from the camera. If this is not the case, they are silently discarded (by the GenTL Producer).

MVTec interfaces for digital I/O and image acquisition are always compatible to a range of HALCON versions. Therefore, the versioning scheme both describes the compatibility of the interface and also the revision of the interface itself. An interface version always consists of three numbers, separated by dots, i.e. 24.11.5. The first two numbers describe the minimum HALCON version the interface is compatible with. For the example version 24.11.5 this means that the interface is compatible with all HALCON versions since HALCON 24.11. The last number describes the revision of the interface, in this example this is revision 5.

Only when installing or updating the interface manually follow these steps:

• Windows: Extract the archive containing the interface files to the HALCON base directory %HALCONROOT% (Note: Administrator privileges may be required for this step). Additionally, you have to move the interface examples to the directory %HALCONEXAMPLES% manually.
• Linux: Extract the archive containing the interface files to the HALCON base directory $HALCONROOT.
• OS X: Extract the archive. Manually move the following files:
  • The .dylib files located in lib/x64-macosx to /Library/Frameworks/HALCON.framework/Libraries or /Library/Frameworks/HALCONxl.framework/Libraries repectively.
  • The genicam folder to /Library/Frameworks/HALCON.framework/Libraries or /Library/Frameworks/HALCONxl.framework/Libraries respectively.
  • The examples folder to the version subdirectory at /Users/Shared/Library/Application Support
  • The doc folder to the version subdirectory at /Library/Application Support

The interface can be controlled through several environment variables:

• GENICAM_GENTL32_PATH, GENICAM_GENTL64_PATH are standard GenTL variables holding the list of directories where individual GenTL Producers are installed. The installer of a GenTL Producer usually adapts these variables automatically. Alternatively you can specify the full path to the producer when opening the device.
• HALCON_ACQUIRED_FILE_PAYLOAD_DIR is used to specify the directory where non-image payload types (usually files or 'raw' data) are stored using the filename given by the device or GenTL Producer.
• When specifying a directory with HALCON_GENICAM_WRITE_XMLFILE and/or HALCON_GENICAM_WRITE_RAW_XMLFILE, the GenICam description files (in XML and/or raw format) will be stored there while working with HALCON. These files can also be stored by setting the interface parameter 'do_write_configuration'.
• If you want to use an already installed GenApi version instead of the one supplied with HALCON, you must set the environment variable HALCON_USE_EXTERNAL_GENAPI. Additionally, all environment variables which are necessary for GenApi must also be set in this case. This is only for experts, see also section GenICam GenApi.

• Implementation of a GenICam GenTL consumer.
• Grabbing from multiple cameras.
• Flexible device lookup and connection options.
• Synchronous and asynchronous grabbing.
• Software control of all generic camera parameters using GenApi.
• Software control of all generic GenTL Producer parameters using GenApi.
• Support of various pixel formats and flexible color transformation.
• Support of 'Continuous', 'MultiFrame' and 'SingleFrame' acquisition modes.
• Support of GenICam action control.
• Support of GenICam chunk data.
• Support of GenICam event data.
• Support of GenICam feature persistence.
• Support of GenICam file access.
• Support of GenICam FWUpdate.
• Support of callbacks for feature change notifications.
• Support of non-streamable devices.

• Simultaneous acquisition from multiple data streams of the same device is currently not possible.
• No support of acquisition from devices with read-only access mode
• Limited support for devices with multiple ROI functionality.

• This interface uses GenApi version 3.5.0, for more details refer to the GenICam homepage. The corresponding files are part of the HALCON runtime installation and are located in the directory genicam within the HALCON base directory %HALCONROOT% or $HALCONROOT, respectively. This version is the same as the officially released version at the time of writing.
• The HALCON GenICamTL interface sets all necessary environment variables on its own and ignores other installed GenICam packages by default.
  If you want to use another GenICam package, you need to set the environment variable HALCON_USE_EXTERNAL_GENAPI. This skips the step of setting all necessary variables and paths internally, so you have to make sure they are set correctly. Please note that it might not be possible to use different GenApi versions with different interfaces at the same time and that you must use the required GenApi version for this interface.
• The caching of device XML files is activated to speed up processing, writing to a temporary directory subject to availability of %TEMP%, %TMP%, $TMPDIR, /tmp or %HALCONROOT%.
• The remote device control features as well as the GenTL Producer control features of this interface are controlled via GenApi.

• GenTL is part of the GenICam standard and allows generic communication between a GenTL consumer like the HALCON GenICamTL acquisition interface which is independent of specific transport layers and hardware, and one or more GenTL Producers which implement access to the specific device hardware (usually a camera).
• GenTL Producers are usually provided by the device manufacturer. They implement the communication with the device regarding control and data streaming (images) and present it in a uniform way to a GenTL consumer. The consumer uses GenApi to access and control the device features.
• The available GenICam GenTL Producers are searched within the path set by the environment variable GENICAM_GENTL32_PATH or GENICAM_GENTL64_PATH, respectively. If none of these variables is set, the full path to the GenTL Producer has to be specified (see Identifying and opening a device).
• Warning: The design, stability, and correctness of GenTL Producers from other manufacturers lie outside MVTec's responsibility. Malfunctioning or non‑standard behavior may lead to an unstable state in HALCON. Use them with appropriate caution.

A device accessible through the GenTL interface is usually described as a set of four entities where the names are given by the specific GenTL Producer.

• 'producer' - the name of the GenTL Producer which is used to access the device.
• 'interface' - the name of the (logical) interface where the device is connected. For example an Ethernet based GenTL Producer running on a system with multiple network cards might present the IP or MAC address of the network card where the device is connected as interface name.
• 'device' - the name of the device (typically camera). Note that a device might be accessible through multiple producers or interfaces and might therefore also be shown with different (hopefully similar) names.
• 'stream' - the name of each data stream of the device. Currently only devices with no stream (peripherals) or a single (image) data stream are fully supported, therefore this is not yet used.

The list of devices can be obtained using info_framegrabber with parameter 'info_boards' (all detectable devices) or 'device' (only available ones). Each entry consists of entries of the form 'token:value' (the entities listed above and usually some additionally ones), separated with a ' | ' (space - pipe - space) sequence.
The result of info_framegrabber can be passed directly to open_framegrabber. Alternatively you can specify the device directly. For this one or more of the entries can be omitted (or specified as 'default') - which is like using wildcards, meaning that the particular ID for that entity should not be considered (any ID would match). The HALCON acquisition interface will walk the GenTL device tree (producer -> interface -> device -> stream), until it finds an exact match for all non-default entries.
The values for the individual entries are evaluated as follows for open_framegrabber:

• 'producer': The value is interpreted as filename of the GenTL Producer (always a file with .cti extension). If it is specified using the full path, it's opened directly. If only a filename without path is specified, the GenTL installation directories (specified via GENICAM_GENTL32_PATH respectively GENICAM_GENTL64_PATH) are searched. If the entry is 'default' or omitted, any GenTL Producer found within the GenTL installation directories would match.
• 'interface': The value is interpreted as GenTL interface ID (string identifier assigned to the interface by GenTL Producer). When 'default' or omitted, any interface would match.
• 'device': GenTL device ID (string identifier assigned by GenTL producer). When 'default' or omitted, any device would match, but only a device that is currently reported as accessible by the GenTL Producer, non-accessible devices are skipped.
• 'stream': GenTL data stream ID. When 'default' or omitted, the first data stream reported for given device is used.

When a pure string without any 'token:' and without the ' | ' separator is used, it is interpreted directly as GenTL device ID, assuming that producer, interface and stream are 'default'.

Alternative IDs:

• In addition to the GenTL device ID, devices can be opened by their user-defined name ('DeviceUserID') if the device supports it. If set, the string obtained by info_framegrabber will contain the entry 'user_name:<user-defined name>'. To make it easier for the user, the 'device' entry reflects the user-defined name if it is unique. If the same user-defined name is assigned to more than one device, only the first one will use it, all others will use the unique name instead.
• Some devices might (optionally) allow identifying the interfaces and/or devices using other strings than the GenTL IDs. This might be for example the device's MAC or IP address, serial number or similar. If a GenTL Producer supports this, alternative IDs can be used also when opening devices.
• The GenICamTL interface has to maintain reference counting of the opened producers, interfaces and devices. This is based on GenTL IDs; if using alternative IDs it might be possible that the reference counting does not work properly. We therefore recommend to use either always GenTL IDs or always alternative IDs.

The features of a device or GenTL Producer are described by GenICam feature description files (XML files) that are automatically parsed and offered to the user. The HALCON GenICamTL image acquisition interface provides access to the features exposed through the following GenICam feature description files:

• Features of the connected device (in GenTL terminology "remote device"), typically a camera, are usually loaded directly from the connected device.
• Features of the GenTL Producer, potentially one for each (so called) GenTL module which corresponds to a node in the GenTL device tree to the connected device:
  • The "system", in GenTL terminology representing the overall behavior of the GenTL Producer itself.
  • The "interface" which is used to connect (logically) the device to the system.
  • The "device" (also "local device") which is a kind of proxy device, controlling the GenTL Producer's view of the device.
  • The "data stream" used for the acquisition (if the device provides any data streams).

In most cases the GenICam description files are provided by the device and the GenTL Producer. It is possible to store a copy of these files corresponding to an open connection by using the parameter 'do_write_configuration' (see set_framegrabber_param). The command will write all the GenICam description files and an "ini" file (details in set_framegrabber_param) with various information, including the location of the written GenICam description files, in the following format:

 
RemoteFile=%PATH_TO_GENICAM_FILE_OF_THE_DEVICE% 
SystemFile=%PATH_TO_GENICAM_FILE_OF_GENTL_SYSTEM_MODULE% 
InterfaceFile=%PATH_TO_GENICAM_FILE_OF_GENTL_INTERFACE_MODULE% 
DeviceFile=%PATH_TO_GENICAM_FILE_OF_GENTL_DEVICE_MODULE% 
StreamFile=%PATH_TO_GENICAM_FILE_OF_GENTL_STREAM_MODULE% 

The same ini-file format can be reused to force the HALCON acquisition interface to load an alternative XML file for one or more of these entities. This can be useful, e.g., for updates or troubleshooting. The files listed in the ini file will be used for the given entity instead of the original ones. For the entities excluded from the ini file, the GenICam description file will be searched and loaded the usual way. To apply the ini file, pass its full path to open_framegrabber in the 'CameraType' parameter.

Note that the ini-file can be reused also for other purposes such as storing/restoring configuration as described in Parameters – Persisting Device Status. Be aware that when persistence files are specified, they have priority over other explicit settings passed to open_framegrabber.

The following groups of parameters exist:

• Internal parameters of the MVTec GenTL Consumer itself (GenICamTL acquisition interface). These are named following the "underscore" naming style, e.g., color_space, and are all lowercase. However, MVTec EasyParams are prefixed with "[Consumer]", e.g., [Consumer]gain.
• GenICam-based parameters of the (remote) device, usually a camera, use by convention the "CamelCase" style, e.g., ExposureTime.
• GenICam-based parameters of the individual GenTL Producer modules (system, interface, device and data stream) use by convention the same style but are prefixed with the module name in square brackets. Beware that the system and interface modules might potentially be shared by multiple opened devices, so changing their configuration might have side effects on other connections as well. The following prefixes are used:
  • "[System]", e.g., [System]TLVendorName.
  • "[Interface]", e.g., [Interface]InterfaceType.
  • "[Device]", e.g., [Device]DeviceID.
  • "[Stream]", e.g., [Stream]StreamBufferHandlingMode.

The parameters belonging to the system and interface modules of the GenTL Producer (i.e. those with "[System]" and "[Interface]" prefix see Parameters – Naming Conventions ) must be treated in a special way.
To grasp their behavior, it is important to understand that they do not describe or configure the device itself and do not thus fully belong to the opened instance of the device.
The interface module parameters belong to the interface on which given device was discovered and is shared among all devices open under this interface (see also Identifying and Opening a Device). The system module parameters belong to the entire GenTL Producer and are shared among all devices open within this GenTL Producer.
This has several implications. In particular, when accessing the system or interface module parameters through multiple device instances, those parameters must be treated as shared resources. Modifying those parameters through one device instance affects their values (and possibly values of other features depending on them) as seen through other device instances. Initial values of those parameters after opening a device instance might depend on the interactions with these features from previously opened device instances.

HALCON native parameter types are

• integer – signed integer, 64-bit on 64-bit platforms, 32-bit on 32-bit ones
• real – floating point type
• string – classical string

When accessing GenICam-based features, the GenICam data types must be mapped to the parameter types recognized by HALCON. GenICam offers the following types:

• IInteger – integer value, mapped directly to HALCON's integer parameter type. It will also accept real parameters. When the GenICam feature in question has a representation associated that identifies it as IPV4Address, MACAddress or HexNumber, the corresponding string representation will also be accepted. It should be highlighted that a problem can occur when running HALCON on a 32-bit platform (where integer parameters are 32-bit wide) and accessing a GenICam feature that is naturally 64-bit. In such cases the full range of the feature will not be available to the application and its value might be truncated. Also the sign of the parameter might be misinterpreted. To solve this problem, the parameter 'split_param_values_into_dwords' can be used. This maps the 64-bit IInteger value into two 32-bit integer values and vice versa.
• IFloat – floating point value, mapped directly to HALCON's real parameter type. It will also accept integer parameters.
• IString – string value, mapped directly to HALCON's string parameter type.
• IBoolean – boolean type is handled through HALCON's integer parameters, a value of 0 (zero) means logical false, other values mean logical true.
• IEnumeration – enumeration is a type that allows selecting from a set of values that are primarily identified by their name (the values are called 'enum entries'). Enumerations are interfaced through HALCON's string parameter type, while the enum entry names are used as the parameter values.
• ICommand – The command type allows to "execute" actions. To execute a command, use set_framegrabber_param with an integer parameter of any value (the value is ignored). Some commands' execution might take longer time and the command provides feedback when it is done. To query the status, use get_framegrabber_param for that command. It will return an integer value of 1 if it "is done" (command execution has finished), 0 if it has not finished yet. Note that if some other features are designed to be dependent on the command, querying the "is done" status might be essential to get the depending features invalidated (and updated with new values) as soon as the command execution finishes.
• IRegister – The register data type is used for plain memory blobs that cannot be mapped to any other data type. They are interfaced through HALCON's string parameter type, the register value is the hexadecimal string representation of the register's memory.

The current status of the acquisition device settings (values of all the parameters defining its working state) might be persisted while no acquisition is active, i.e. before grab_image_start or grab_image_async or after set_framegrabber_param(..., 'do_abort_grab', 1). This applies not only to actual device parameters, but also to parameters configuring the GenTL Producer and internal parameters of the GenICamTL image acquisition interface. Device parameters are usually kept until the device is powered down. The GenTL Producer modules and the Consumer parameters are kept until close_framegrabber is called. To indicate which parameters to persist, use the parameter 'settings_selector'. The persistence functionality consists of two steps, storing the current configuration to a file and later re-loading it back to the device. The selected module settings, indicated by 'settings_selector', can be stored using the 'do_write_settings' parameter and re-loaded later using the 'do_load_settings' parameter, specifying the desired persistence file path in both cases. To query if a feature can be persisted use the postfix '_streamable'.

Note that while the format of the files is intentionally human readable and the files can be hand-modified if desired, such modifications should be done with care by someone familiar with the GenICam persistence functionality internals and given device. Improper modifications of the files can lead to errors when using it.

It is important to know that while performed by the software, persistence of the device-related features is actually a device-side function. If the persistence support is implemented incorrectly or incompletely by the device, it will not work as expected – in such a case the manufacturer could provide additional information or help.

The persistence related operations might be blocked by the device and/or GenTL Producer based on the current state, for example while an acquisition is in progress.

The same persistence files can be applied to the entire set of devices of the same type and firmware version. Applying the persistence files to a device of another type or using even different firmware version will probably lead to inconsistencies or will even fail completely – the corresponding device manufacturer should provide guidelines for such use cases .

Apart from the 'do_write_settings', the feature persistence file will also be written together with the ini file documented in the section Selection of GenICam Feature Description File(s) - using parameter 'do_write_configuration'. This command will generate extended version of the persistence file, storing not only the current device configuration, but also contents of its user sets and sequencer sets (if the device supports them). Additionally, it will also generate persistence files for all the GenTL Producer modules (system, interface, device and data stream). The persistence file entries in the ini file will have the format

 
RemotePersistence=%PATH_TO_PERSISTENCE_FILE_OF_THE_DEVICE% 
SystemPersistence=%PATH_TO_PERSISTENCE_FILE_OF_GENTL_SYSTEM_MODULE% 
InterfacePersistence=%PATH_TO_PERSISTENCE_FILE_OF_GENTL_INTERFACE_MODULE% 
DevicePersistence=%PATH_TO_PERSISTENCE_FILE_OF_GENTL_DEVICE_MODULE% 
StreamPersistence=%PATH_TO_PERSISTENCE_FILE_OF_GENTL_STREAM_MODULE% 

If the persistence functionality is not supported properly (or at all) by a given device, use the GenICam features UserSetSave/UserSetLoad, if supported by the device. These features will allow to store/load the device settings in the device's non-volatile memory.

The MVTec EasyParams is a group of MVTec GenTL Consumer parameters based on the regular GenICam features of the device. These parameters allow easy access to the most commonly used camera parameters.
The list of EasyParams can be obtained calling 'available_easyparam_names'. Note that 'available_param_names' does not include the EasyParams. The MVTec EasyParams start with the prefix [Consumer], indicating they are internal parameters of the HALCON GenTL consumer itself.
Since HALCON 22.11 they are available via an own tab in the HDevelop Image Acquisition Assistant.
If your device does not support one of the EasyParams, querying its access will return 'ni' (not implemented). If instead 'na' (not available) is returned, the EasyParam is supported but currently not available, e.g., it depends on the current state of another EasyParam or the access of one or more GenICam features, or because the image acquisition is running. In the latter case, use set_framegrabber_param(..., 'do_abort_grab', ...) to stop the acquisition.
List of MVTec EasyParams:

• General device information:
  • [Consumer]info_general
• Exposure feature:
  • [Consumer]exposure_auto
  • [Consumer]exposure
• Gain feature:
  • [Consumer]gain_auto
  • [Consumer]gain
• Trigger feature:
  • [Consumer]trigger
  • [Consumer]trigger_activation
  • [Consumer]trigger_delay
  • [Consumer]trigger_software

Detailed information of each MVTec EasyParam can be found in sections about getting framegrabber parameters and setting framegrabber parameters.
See also the HDevelop example genicamtl_easyparams.hdev.

The image acquisition can be either synchronous (grab_image/grab_data) or asynchronous (grab_image_start/grab_image_async/grab_data_async), see the reference documentation of the operators.
The interface fully configures and controls the acquisition process on the camera and GenTL Producer. Note that some of the camera or producer features might be locked by GenICam when an acquisition is active.
With synchronous grab (grab_image/grab_data), a new acquisition is started internally for each image, so that the application always gets a new image. Before delivering the image, the acquisition is stopped again, so between individual grab_image/grab_data calls, all acquisition related features remain unlocked.
With asynchronous grabbing, started explicitly by grab_image_start or implicitly by grab_image_async/grab_data_async, the interface keeps the acquisition running internally, collecting further images to be delivered through future grab_image_async/grab_data_async calls. The acquisition related features are locked, until the acquisition is stopped using set_framegrabber_param(..., 'do_abort_grab', ...).
The HALCON acquisition interface properly recognizes the 'Continuous', 'SingleFrame' and 'MultiFrame' acquisition modes configured on the device and adjusts the acquisition control logic accordingly.
Furthermore, the interface takes over exclusive access to several remote device features essential for the acquisition control (AcquisitionStart, AcquisitionStop, AcquisitionAbort, TLParamsLocked). The user application has no direct way to control these features.
The differences between the "image" and "data" version of the grab operators is documented in Acquisition – Grab Operators.

The interface allocates 4 buffers for the acquisition engine by default (the number of buffers can be changed through the 'Generic' parameter of open_framegrabber).
Whenever a new image is acquired successfully and passed to the application as a HALCON image, the interface keeps the buffer locked (not returning it to the acquisition engine) until a new grab-related operator is called by the application or the acquisition is aborted using set_framegrabber_param(..., 'do_abort_grab', ...). During this period, it is fully safe to query information about this "last acquired" buffer – for example query buffer properties through get_framegrabber_param parameters such as 'buffer_timestamp', 'buffer_is_incomplete', 'image_width' and 'image_height'. This applies also to Chunk Data eventually present in the buffer and is also usable in volatile mode.
When a new grab-related operator is called by the application, the interface returns the buffer to the acquisition engine and buffer-related queries are not valid anymore.

With modern, generic image acquisition interfaces an application cannot make valid assumptions about the image format coming from the device based on the current settings. Some devices for example allow changing the image format properties while the acquisition is active. Other setups contain multiple devices in the acquisition path (and e.g. a frame grabber might be modifying the image format provided by the camera).
The HALCON GenICamTL image acquisition interface fully supports these use cases. It checks the image format and other important properties of every single buffer and generates HALCON images corresponding to both the acquired image format and eventual user configured output format parameters such as 'color_space' and 'bits_per_channel'. Only if the necessary information about the buffer are missing (i.e., the GenTL Producer does not support it) , the current settings are used as a fallback.

The acquisition interface provides two mechanisms for acquisition of the image (or other) data from the device, grab_image/grab_image_async and grab_data/grab_data_async. Each of them might be more suitable for different use cases. Internally, both mechanisms work exactly the same (in particular how they acquire and process the data from the device), they differ in the way how the outputs are provided to the application.
The "traditional" grab_image/grab_image_async operators are still well suitable in simple use cases when just a single 2D image is acquired from the device. It is also currently used e.g. by the HDevelop's Image Acquisition Assistant. However, in case when the device is streaming more complex data structures, such as 3D data, multi-AOI or similar data, grab_image/grab_image_async is not able to provide all the outputs. In all these cases it will simply provide the first image found in the acquired data.
The "extended" grab_data/grab_data_async operators allow to output arbitrary number of HALCON images and also arbitrary number of control data. It is therefore suitable for use in advanced use cases when more than just a single HALCON image should be output. An important use case is acquisition from 3D devices (Using 3D Devices) when the operators can build and output the 3D object model through the control data output. It can be also used in other (possibly even device-specific) situations when the device outputs multiple images for a single acquisition.
The structure of the provided outputs can be queried with help of the 'image_contents', 'data_contents' and related parameters.
The grab_data/grab_data_async can also be used in the simple single-image use cases - in that case they will simply provide a single HALCON image and zero control data outputs. They can thus be used as full replacement of the traditional grab_image/grab_image_async operators.

The acquisition interface fully supports the GenICam standard 3D device model and is thus capable to seamlessly integrate 3D devices compliant with this model. This means in particular that the application does not need to care about device-specific ways of 3D data formatting, the acquisition interface will generate the 3D data under the hood using the information from the device.
If instructed so (using the 'create_objectmodel3d' parameter), the acquisition interface will generate the 3D object model from the coordinate data acquired from the device. This model can be directly used by the HALCON's 3D object model related operators.
The completeness and accuracy of the final 3D object model strongly depends on the actual coordinate data and in particular on the 3D configuration information provided by the device. Because the 3D configuration metadata are typically passed from the device through the chunk data mechanism (Chunk Data), it is essential to observe that the chunk data generation is fully enabled on the device.
If some of the important 3D configuration information is missing, the acquisition interface will try to use the suitable defaults, but the quality of the 3D object model output can be lowered.
The creation of the 3D object model can be further affected by additional parameters such as 'coordinate_transform_mode', 'confidence_mode', 'confidence_threshold', 'add_objectmodel3d_overlay_attrib'.
Note: for devices not complying with the GenICam standard 3D device model the HALCON 3D object model cannot be automatically generated.
Note that the 3D object model output is only supported by the grab_data/grab_data_async operators, it cannot be acquired using grab_image/grab_image_async. Besides the 3D object model, the grab_data/grab_data_async operators also output the actual raw coordinate data in form of HALCON images. The individual outputs can be identified with help of 'image_contents', 'data_contents' and related parameters.

The HALCON GenICamTL image acquisition interface has a built-in converter from the pixel formats described in the GenICam Standard Features Naming Convention to the desired HALCON image format. The parameters ColorSpace and BitsPerChannel (open_framegrabber, eventually set_framegrabber_param) define the desired format of the resulting HALCON image. If these parameters are set to defaults, the original pixel format coming from the device is preserved.
To offer a basic support of custom pixel formats (i.e., pixel formats not defined by PFNC or not supported by HALCON), the ColorSpace value 'raw' can be used. In this case the image acquisition interface delivers the buffer to the application without any format conversions.
Note that the same principle is applied whenever a buffer containing other than image data is acquired. Examples of such buffers can be files (e.g., compressed images) or raw data (results of smart camera processing). Such buffers are not real "images", but can still be delivered to the application as 'raw' HALCON images. It is the responsibility of the application to know how to interpret such data.
Last but not least, the 'raw' color space can also be used if the user explicitly wishes to receive raw input data without any conversions. For example when acquiring Bayer encoded images, specifying 'raw' means that the interface should not attempt to decode them to RGB or monochrome format, but deliver the data directly to the application.
It is important to know that when the interface does not have full information about the image format (dimensions and pixel format), it has to choose an artificial one. In such a case it delivers always an 8-bit image with dimensions matching the buffer size (square root of the image size). Eventually an unused tail of the HALCON image (if such an artificial image is bigger than the source buffer) will be padded with zeroes. The fact whether the last acquired buffer contained an image of known properties or a blob of other data (so that the artificial HALCON image size had to be used) as well as the size of the eventual tail padding can be queried using 'image_raw_buffer_type' and 'image_raw_buffer_padding_bytes' parameters.

GenICam compatible cameras can deliver additional meta-data with every image in a so-called chunk data format. It is usually necessary to enable the delivery of individual meta-data "chunks" using the features 'ChunkModeActive' and 'ChunkSelector'/'ChunkEnable' first.
The decoding of the chunk data and matching them to the corresponding camera features is performed transparently by the interface.
The actual values might be read through the regular parameter reading mechanism, i.e., get_framegrabber_param. The choice of the meta-data to be delivered is device-specific. The names of the chunk related features usually start by convention with a prefix 'Chunk' (examples might be 'ChunkExposureTime' or 'ChunkGain'), however, the camera documentation should contain all the information about supported chunks and their corresponding feature names.
Some GenICam compatible devices might implement a chunk-only mode, in which meta-data without an image is transmitted. This mode is incompatible with the grab_image operators, but can be used with the grab_data operators.
The chunk data related features will only provide meaningful values if the "last acquired buffer" is valid, i.e., between delivery of the last image and next call to any grab-related operator (refer to section Acquisition – Buffer Handling).

It is possible to receive notifications about changes of any features exposed through the GenICam interface by the camera and GenTL Producer as well as for internal parameters of the acquisition interface.
Note that the notifications might be raised in various circumstances, including:

• The application (you) explicitly changed that feature.
• Another feature has changed and the notified feature "depends" on the changed feature (the dependencies are defined in the GenICam description file).
• Access mode or current range for the feature has changed.
• As a result of regular "polling" in case of uncached features.
• As a result of device event delivery if the feature is connected to that event.
• As a result of new buffer delivery for features corresponding to chunk data.

Note that the notifications are raised whenever the feature is "marked dirty" (its cache invalidated) by one of the actions described above. It does not necessarily mean that its value has really changed, it is up to the application to check this.
Notification callbacks can be registered for individual features using set_framegrabber_callback - see corresponding operator documentation. Additionally, it is possible to use message queues to receive the event notification. In those cases it is necessary to create a message queue and then register the individual feature - see event message queues.

GenICam compatible devices can deliver asynchronous events which optionally carry additional data. It is usually necessary to enable delivery of individual event types using the features 'EventSelector'/'EventNotification' first. For SFNC-compliant events, this is done automatically if the parameter 'event_notification_helper' is enabled.
The decoding of the event data and matching them to the corresponding features, including potential notifications, is performed transparently by the interface.
The actual values might be read through the regular parameter reading mechanism like get_framegrabber_param or by get_message_tuple if you are using message queues to receive events. The choice of the event types to be generated is device-specific. The names of the event related features usually start by convention with a prefix 'Event' (examples might be 'EventFrameTrigger' and 'EventFrameTriggerTimestamp'), however, the device documentation should contain all the information about supported events and their corresponding feature names.
Although the data corresponding to the last delivered event can be in general read at any time, when using callback to receive events it is highly recommended that reading the event data is synchronized to notifications for corresponding event feature(s). Only in such a case it is guaranteed that the read data correspond exactly to the very event instance being notified – and that the feature values are not just being modified through a new instance of the same event. Note that the notifications are raised from context of the event handling/dispatching thread, so when processing the user callback, the event handling mechanism is paused. If multiple data items are associated with the same event, it is enough to register notification just for the actual event feature and read all the data during the callback.
If using message queues to receive events, you can decide to add additional data to be delivered with the corresponding event feature(s), see Event Message Queues. For this case the interface will read all the specified event features as soon as the event is generated and add it to the corresponding message. This guarantees that the delivered information corresponds with the actual value at the time the event was generated.
Besides the asynchronous events generated by the actual device, asynchronous events (optionally including additional data) can be generated by any module of the GenTL Producer (system, interface, device and data stream). The information provided above about handling of the device events applies similarly also to the GenTL Producer events, including enabling/disabling them (typically using 'EventSelector'/'EventNotification' features provided by given module, i.e. with corresponding module prefix in the feature name). For SFNC-compliant events, this is done automatically if the parameter 'event_notification_helper' is enabled.
The interface will automatically capture and decode the events and match them to the corresponding GenTL Producer features. It is only important to understand that because the system and interface modules are potentially shared among multiple opened devices (see Parameters – Sharing Among Devices) and so, the same applies for asynchronous events generated by these shared modules.

This interface supports feature change notifications via message queues. Select the desired target feature with set_framegrabber_param(..., 'event_selector', ...). It is the same plain feature name (GenICam feature or internal parameter) as used with set_framegrabber_param, including a possible prefix, such as '[Device]' (refer to the Parameters – Naming Conventions).
Create a message queue at which you want to receive the notifications with create_message_queue and assign it to the selected feature with set_framegrabber_param(..., 'event_message_queue', QueueHandle).
The message queue can be registered for any GenICam based features, i.e., features published by the device and GenTL Producer or for internal features of the acquisition interface. On top of that, the notification can be registered also for internal events occurring within the acquisition interface, in particular 'event_new_buffer' which gets fired whenever the information about last acquired buffer is updated (new buffer grabbed or last buffer info invalidated when restarting the acquisition).
The list of supported targets can be queried by calling get_framegrabber_param(..., 'available_event_names', ...).
One of the important use cases for feature change callbacks is the device event delivery mechanism, see details in Event Data and Feature Change Notifications sections.
A new message would be added to the specified queue whenever a given feature is potentially changed (including its other properties such as range or access mode). Note that it does not necessarily always mean that the feature actually has a new value. A call to set_framegrabber_param(..., 'event_message_queue', 0) unregisters the previously registered message queue from the specified event. Note that the interface keeps just a single registration for every feature, if you attempt to register a new message queue for a feature that already had a message queue registered, the previous registration will be replaced with the new one.
The messages incoming on an event can be retrieved with dequeue_message and will contain at least three tuples. The first tuple (key 'id') is a unique identifier of the acquisition instance the event is coming from. It is a string composed as '<interface>:<unique_name>'. The second tuple (key 'event_name') is the name of the corresponding feature previously specified by 'event_selector'. The third tuple (key 'event_value') contains the value if the corresponding feature if available and readable.
If you decide to add additional data to be delivered with the corresponding event feature(s), add the features of interest with set_framegrabber_param(..., 'event_data', ...). Each event data feature will be appended to the event message with the key being its name and the tuple its value if readable. Note that duplicities possibly specified through 'event_data' are ignored The value of the notified feature itself (already reported in 'event_value') would also be considered as a duplicity and not reported again.

In case of using the HDevelop Image Acquisition Assistant the following hints will help to avoid problems:

• Some parameters depend on special conditions, e.g., a valid buffer or another parameter activated. After opening the camera these conditions may not yet be fulfilled, so the depending parameters are not shown. By using the 'Refresh' button, all parameters are read again and the depending parameters should appear if the conditions are fulfilled then.
• There are also some parameters regarding the image size and the payload size, which can only be changed if no acquisition takes place. The safest way to ensure this is to apply the action parameter 'do_abort_grab'. Please note that 'Update Image' has to be disabled first.
• The behavior of allowing changes to parameters while streaming is active depends on the capabilities of the device. It is possible that some cameras give you control over, e.g., the exposure time, while streaming and others do not.

The HALCON GenICamTL interface supports an internal color conversion performed in software. The conversion is automatically applied for PFNC (Pixel Format Naming Convention) compatible cameras, when the color format delivered by the camera differs from the user defined format if set via the parameter 'color_space'. The used transformation algorithms are basic and optimized for speed.

Following transformations from the camera color space (see also PFNC) to the interface color space (see also 'color_space' parameter in this document) are supported:

• Bayer pattern to 'rgb':
  

  Bayer_LMMN R G1 G2 B ⇾ [R,G,B] [R,G,B] [R,G,B] [R,G,B]

  Bayer_NMML B G1 G2 R ⇾ [R,G,B] [R,G,B] [R,G,B] [R,G,B]

  with G = (G1 + G2) / 2.

• Y'CbCr to 'rgb' (Note: gamma correction is not considered):
  

  R = Y' + 1.4020 * (Cr- M)
G = Y' - 0.34414 * (Cb- M) -0.71414 * (Cr- M)
B = Y' + 1.7720 * (Cb - M)

• RGB to 'yuv' ('yuv' corresponds to Y'CbCr of PFNC, Note: gamma correction is not considered):
  

  Y' = 0.299 * R + 0.587 * G + 0.114 * B
Cb = -0.16874 * R - 0.33126 * G + 0.5 * B + M
Cr = 0.5 * R - 0.41869 * G - 0.08131 * B + M

• RGB to 'gray':
  

  Y' = 0.299 * R + 0.587 * G + 0.114 * B

with M = 128 for 8 bit raw data, and M = 32768 for 16 bit raw data.
The accuracy of the results is limited due to internal 16.16 fix-point arithmetic for 8 bit ( 0...255), and 24.8 fix-point arithmetic for 16 bit raw data.

The acquisition interface supports the GenICam FWUpdate standard, allowing to update firmware on devices supporting the same standard in a generic way. If the device supports the standard, its vendor would distribute the firmware update files in form of GUF files, i.e. files with .guf extension.
To apply the firmware update, the device must be opened (open_framegrabber) in a special configuration mode (called "safe mode"). This mode is selected through the 'Generic' parameter of open_framegrabber - the parameter must include 'device_access=safe-mode'.
When opened in the safe mode, most of the usual parameters (either those provided by HALCON acquisition interface, the device itself or the GenTL Producer) will be unavailable. Instead, the configuration parameters corresponding to the given device and interface technology and in particular the parameters related to firmware update will become available.
To update the device, the GUF file is first selected in 'fwupdate_file_path', one of the (possibly multiple) updates from the file selected using 'fwupdate_update_selector' and finally applied through 'do_fwupdate_apply'. Documentation of these parameters provides further details.
Note that the update procedure may include one or more device resets, after which the device has to be re-discovered by the acquisition interface. The time needed for reset and re-discovery is specified by device vendor in the GUF file. However, there might be situations (depending on the device itself, its connection technology and system setup) when the re-discovery timeout is not sufficient and the device fails to get safely re-discovered. In such case, it is possible to specify an additional timeout that would be added to the one specified in the GUF file, allowing to successfully complete the process. This parameter, 'fwupdate_wait_after_reset', specifies the additional timeout in milliseconds.
See also the HDevelop example genicamtl_fwupdate.hdev.

The parameters of the cameras and GenTL Producer are accessed through GenICam and defined in GenICam description file(s) of the respective camera or GenTL Producer, so the parameter set is different for every product (although the parameter naming should adhere to SFNC and GenTL SFNC GenICam standard). A call of get_framegrabber_param(..., 'available_param_names', ...) returns a tuple containing all available parameters of the connected camera and GenTL Producer. See also section about parameter naming convention.
To set e.g. the current gain of the camera AcqHandle refers to (after calling open_framegrabber), the user can call set_framegrabber_param(AcqHandle, 'Gain', 6.0).
Please note that the interface sets the value of a parameter only if the value is valid. Integer and float values not matching the allowed range for given feature are aligned to the closest valid value. Invalid values of other feature types are refused.
Additionally to the GenICam parameters of the camera and of the GenTL Producer, the following HALCON interface parameters are supported by set_framegrabber_param:

There may exist additional read-only parameters with the following postfixes:

• '_access': These parameters provide the access permissions of the corresponding parameter as a string. Possible values are 'ro' (read-only), 'wo' (write-only), 'rw' (read/write), 'na' (not available), and 'ni' (not implemented).
• '_category': These parameters provide the category of the corresponding parameter as a string.
• '_description': These parameters provide the tool-tip of the corresponding parameter as a string.
• '_displayname': These parameters provide the displayname of the corresponding parameter as a string.
• '_longdescription': These parameters provide the description of the corresponding parameter as a string.
• '_range': These parameters provide the minimum, maximum, step width, and current values for the corresponding integer or float parameter as a tuple with 4 elements, e.g., get_framegrabber_param(.., 'Shutter_range', ..) will return the output tuple [min, max, step, current].
• '_representation': These parameters provide the GenICam representation of the corresponding parameter as a string. They only exist for integer-parameters. Possible values are 'Linear', 'Logarithmic', 'Boolean', 'PureNumber', 'HexNumber', 'IPV4Address' and 'MACAddress'. The purpose of the representation is to aid in GUI design.
• '_streamable': These parameters provide the persistence of the corresponding parameter as an integer. Possible values are 0 if false or 1 if true.
• '_string': These parameters provide the integer values formatted as a string according to the '_representation' postfix. Especially useful for the '_representation' values 'IPV4Address', 'MACAddress' and 'HexNumber'.
• '_type': These parameters provide the type of the corresponding parameter as string.
• '_values': These parameters provide the valid value list for the corresponding parameter as a tuple, e.g., get_framegrabber_param(.., 'volatile_values', ..) will return the output tuple ['enable', 'disable'].
• '_visibility': These parameters provide the visibility of the corresponding parameter as a string. Possible values are 'beginner', 'expert', and 'guru'.

All these postfixed parameter names are not returned when calling info_framegrabber(.., 'parameters', ..) and are used to enable the easy parameterization via a generic graphical user interface, particularly the HDevelop Image Acquisition Assistant.

Not supported by this interface.

Not supported by this interface.

This interface supports feature change callbacks via the operators set_framegrabber_callback and get_framegrabber_callback.
The callback can be registered for any GenICam based features, i.e., features published by the device and GenTL Producer through the GenICam description files as well as for internal parameters of the acquisition interface.
The list of supported callback targets can be queried by calling get_framegrabber_param(..., 'available_callback_types', ...).
One of the important use cases for feature change callbacks is the device event delivery mechanism, see details in event data and feature notifications sections. The 'CallbackType' parameter of set_framegrabber_callback defines the feature for which the callback is registered. It is the same plain feature name as used with set_framegrabber_param, including a possible prefix, such as '[Device]' (refer to the parameter naming convention).
The registered callback function would be called whenever a given feature is potentially changed (including its other properties such as range or access mode). Note that it does not necessarily always mean that the feature actually has a new value. If the callback function is set to NULL, the corresponding callback will be unregistered. Note that the interface keeps just a single registration for every feature, if you attempt to register a new callback for a feature that already had a callback registered, the previous registration will be replaced with the new one.

The signature of the callback function is Herror (__stdcall *HAcqCallback)(void *AcqHandle, void *Context, void *UserContext) and uses the following parameters:

• AcqHandle: Acquisition handle of the corresponding image acquisition instance.
• Context: Optional context data of the specific callback. Up to now, this parameter is not used, i.e., Context is set to NULL.
• UserContext: Optional context data of the specific callback. Up to now, this parameter is not used, i.e., UserContext is set to NULL.

Note that the execution time of a user-specific callback function must always be as short as possible since during the execution of a callback function the handling of further internal callbacks might be blocked. This can be achieved by removing the current processing from the user-specific callback function to a separate thread that is controlled via signals or events. The callback function is executed in the context of the underlying interface or driver.
It is also important to understand that the callbacks might be fired as a side-effect of parameter-setting or grab operations, ie. it might be called from within their respective locks. The user is responsible to take this into account in the callback handler to avoid risk of a deadlock.

This interface supports feature callbacks via the operators set_framegrabber_callback and get_framegrabber_callback. For more information see set_framegrabber_callback.

Starts a new asynchronous grab. See also grab_image_start and section about acquisition control. Note that this operator starts acquisition on the GenTL Producer and device and locks features protected during acquisition. If grab_image_start is called repeatedly, the acquisition is restarted on both GenTL Producer and device. That means, that the buffer queue and all stream related statistics parameters like 'buffer_frameid' are reset. The acquisition can be stopped (and the features unlocked) using set_framegrabber_param(..., 'do_abort_grab', ...).

grab_image starts a new synchronous grab of a single image. See also grab_image, section about acquisition control and about grab operators. Note that the interface converts the acquired image to the desired image format specified by the parameters 'bits_per_channel' and 'color_space'.

grab_image_async returns a single image and starts the next asynchronous grab. See also grab_image_async, section about acquisition control and about grab operators. Note that the interface converts the acquired image to the desired image format specified by the parameters 'bits_per_channel' and 'color_space'.
The 'MaxDelay' parameter of the grab_image_async operator is ignored by the HALCON GenICamTL acquisition interface, because there is no way to support it reliably across all GenTL Producers . If needed, the application needs to implement alternative functionality on its own.

grab_data starts a new synchronous grab, resulting possibly in tuple of output images and tuple of data outputs of various kind, depending on the input and configuration. See also grab_data, section about acquisition control and about grab operators. Note that the interface converts the acquired images to the desired image format specified by the parameters 'bits_per_channel' and 'color_space'. The output tuples are described using the 'data_contents', 'image_contents' and related parameters.

grab_data_async returns acquired images/data and starts the next asynchronous grab. See also grab_data_async, section about acquisition control and about grab operators. Note that the interface converts the acquired image to the desired image format specified by the parameters 'bits_per_channel' and 'color_space'. The output tuples are described using the 'data_contents', 'image_contents' and related parameters.
The 'MaxDelay' parameter of the grab_image_async operator is ignored by the HALCON GenICamTL acquisition interface, because there is no way to support it reliably across all GenTL Producers . If needed, the application needs to implement alternative functionality on its own.

This operator closes the device. See also close_framegrabber.

For this interface there are the following examples available:

• genicamtl.hdev - Benchmark.
• genicamtl_acquisition_events.hdev - Example how to handle events with additional event data using message queues.
• genicamtl_basler_blaze_objectmodel3d.hdev - Example for the usage of the Basler Blaze TOF sensor.
• genicamtl_devicelost_event.hdev - Example how to handle DeviceLost event with message queues.
• genicamtl_do_abort_grab.hdev - Aborting an ongoing image acquisition.
• genicamtl_easyparams.hdev - Handling MVTec EasyParams.
• genicamtl_fileaccess.hdev - Example how to upload and download files from GenICam devices.
• genicamtl_frame_rate.hdev - Example to measure the effective frame rate of an acquisition device.
• genicamtl_fwupdate.hdev - Example how to apply a firmware update using GenICam's FWUpdate module.
• genicamtl_hardware_trigger.hdev - Usage of hardware trigger.
• genicamtl_information.hdev - Program for gathering information about the system and the camera configuration. Please attach the resulting files when requesting support.
• genicamtl_io_control.hdev - Example how to control the GPIOs of a device.
• genicamtl_lmi_gocator_objectmodel3d.hdev - Example for the usage of the LMI Gocator calibrated 3D sensor.
• genicamtl_parameters.hdev - Lists all parameters of a device.
• genicamtl_parameter_persistence.hdev - Demonstrates writing parameter values to files and restoring parameter values from files.
• genicamtl_simple.hdev - A simple example to show the usage of the interface.
• genicamtl_smartray_ecco_objectmodel3d.hdev - Example for the usage of the SmartRay ECCO 3D sensor.
• genicamtl_software_trigger.hdev - Usage of software trigger.
• genicamtl_vrmagic_areascan3d_objectmodel3d.hdev - Example for the usage of the VRmagic AreaScan3D calibrated 3D area sensor.
• genicamtl_zivid_one_objectmodel3d.hdev - Example for the usage of the Zivid One 3D sensor.

In case of problems with the HALCON GenICamTL Interface the following hints might help to solve them.

General:

• Check if the latest revision of the HALCON GenICamTL interface is used.
• Check the System Requirements.
• Check for a newer version of the used GenICam GenTL Producer.
• Check if the device has the latest firmware.
• Enable low-level error messages in HALCON to query more information about the problem (and check the output console in HDevelop if applicable).
• If your device is connected via Ethernet and a firewall is active in the system, it has to be configured in a way so that all applications expected to be using the devices (e.g. HDevelop, but also any user-developed applications) have full access to the connected devices.

GenICam:

• Check if the correct GenICam binaries are in use. HALCON uses the official binaries in a private installation (folder genicam in the HALCONROOT directory). If other GenICam binaries are in your path or in some system path (for Windows e.g. in c:\Windows\System32\ for Linux e.g. in /usr/lib or similar directories) make sure these are the official ones by comparing them with the ones in the HALCON installation. Using unofficial binaries might result in strange problems.

If there are still problems, please contact your local distributor.

The following information is needed for your support request to avoid unnecessary inquiries.

• Used HALCON and acquisition interface versions.
• Used HALCON architecture (especially 32 or 64 bit).
• Low-level error messages if there are any.
• Camera manufacturer, model and firmware version.
• Details about the used GenICam GenTL Producer (at least name and version).
• Details about computer system, like operating system, RAM and CPU.
• Minimal sample code (e.g. HDevelop script) to reproduce the issue.
• Description of observed and expected behavior.

Please run the HDevelop example genicamtl_information.hdev to gather information about the system and the camera configuration, and then attach the resulting files when requesting support.

This interface depends on third-party libraries. See the file third_party_genicamtl.txt in the HALCON base directory for copyright and license information. Libraries are used without modifications unless explicitly stated in the file.

You can request the source for those third-party libraries licensed under GPL or LGPL via email to info@mvtec.com with the subject "Request source code of third-party libraries".

• Revision 24.11.23 (Apr 10, 2026):
  • The decompression mechanism for GenICam feature description files failed for some zip files with: 'Failed to decompress file (unexpected uncompressed size 0)'. This problem has been fixed.
  • zlib has been updated to version 1.3.2.
• Revision 24.11.22 (Oct 8, 2025):
  • The decompression method for GenICam feature description files has been changed to zlib 1.3.1.
  • libjpeg-turbo has been updated to version 3.1.0.
  • The HDevelop script genicamtl_information.hdev has been extended to deal with GenTL producers not implementing the device access status.
  • There was a memory leak when registering for feature change notifications with set_framegrabber_callback or with 'event_message_queue'. This problem has been fixed.
  • A Software Bill of Materials (SBOM) in the System Package Data Exchange (SPDX) format has been added next to each binary file with the same name extended by ".spdx.json".
• Revision 24.11.21 (Apr 16, 2025):
  • The underlying GenApi version has been updated to the latest official release 3.5.0. The previous version failed to load settings that contained empty string parameters. This problem has been fixed.
  • Instead of the documented value, zero was returned when a GenTL Producer did not implement the purpose, region, or source IDs. This problem has been fixed.
• Revision 20.11.20 (Oct 10, 2024):
  • libjpeg-turbo has been updated to version 3.0.3.
• Revision 20.11.19 (Sep 24, 2024):
  • The initialization of the MVTec EasyParam [Consumer]trigger_delay crashed in the rare case that TriggerActivation did not support any of the following values: 'RisingEdge', 'FallingEdge' and 'AnyEdge'.
  • The first access to the MVTec EasyParam [Consumer]exposure_auto and [Consumer]gain_auto could lead to a change in ExposureTime or Gain GenICam device parameter, respectively. This problem has been fixed.
  • Multithread usage of the MVTec EasyParams could lead to abnormal program termination. This problem has been fixed.
• Revision 20.11.18 (Feb 28, 2024):
  • The open_framegrabber's ColorSpace parameter has been extended with the value 'rgbx'. The new value can be used to obtain a 4 channel HALCON image, if the input pixel format is a supported 4 channel PFNC pixel format.
  • Pixel formats 'RGB14', 'RGBa10', 'RGBa12', 'RGBa14', 'RGBa16', 'BGR14', 'BGR16', 'BGRa10', 'BGRa12', 'BGRa14' and 'BGRa16' are now supported.
  • The underlying GenApi version has been updated to the latest official release 3.4.2. This fixes a compatibility break with certain persistence files introduced in version 3.4.1.
  • Loading of configuration files during open_framegrabber (with the parameter CameraType) did not raise an exception, even when the file could not be read. This problem has been fixed.
  • When passing GenICam persistence files to open_framegrabber, the remote device was silently ignored. This problem has been fixed.
  • Grab operators returned an error when the pixel format of the image was unknown. Now, the image is returned as described in Raw Output Format – Custom Pixel Formats, Non-image Buffers.
  • The HDevelop script genicamtl_information.hdev has improved functionality and reliability for checking link dependencies of producer files. The deprecated Dependency Walker tool has been replaced by the up-to-date Dependencies tool. This also fixes issues of long script execution times in cases when cyclical dependencies are discovered.
  • Loading of configuration files during open_framegrabber (with the parameter CameraType) did not raise an exception, even when the file could not be read. This problem has been fixed.
  • The HDevelop example genicamtl_hardware_trigger.hdev has been added to demonstrate how to use the hardware trigger mode.
  • Instead of a range, numeric GenICam parameters can also report a list of values. This is now available through the parameter suffix '_values'.
• Revision 20.11.17 (Jul 31, 2023):
  • The underlying GenApi version has been updated to the latest official release 3.4.1. This improves the validation of the string representation of parameters written through the '_string' postfix.
  • Pixel formats 'YCbCr420_8_YY_CbCr_Semiplanar', 'YCbCr420_8_YY_CrCb_Semiplanar', 'YCbCr422_8_YY_CbCr_Semiplanar', and 'YCbCr422_8_YY_CrCb_Semiplanar' are now supported.
  • The generic parameter 'discovery_timeout' now allows to adjust the maximum waiting time during GenTL module enumeration.
  • Execution of 'do_write_configuration' with 'streaming_mode' off returned an error. This problem has been fixed.
  • The first access to an MVTec EasyParam could change the value of its equivalent GenICam device parameter. This problem has been fixed.
  • Accessing an MVTec EasyParam could lead to a crash if any of the underlying GenICam parameters had an unexpected type. This problem has been fixed.
  • Querying the '_representation' of an MVTec EasyParam could in some cases lead to a crash. This problem has been fixed.
  • In rare cases, the access of not implementable MVTec EasyParams was erroneously set to 'na', instead of 'ni'. This problem has been fixed.
  • The robustness of setting/restoring the device trigger state in genicamtl_information.hdev has been improved.
• Revision 20.11.16 (Apr 5, 2023):
  • If a numerical parameter has a special representation besides its pure value, the type of representation can now be queried by using the '_representation' postfix.
  • The string representation of a parameter value can be now queried by using the '_string' postfix.
  • The libCLAllSerial shared object has been removed from the redistribution of GenApi 3.4.0.
  • The HDevelop example genicamtl_software_trigger.hdev has been added to demonstrate how to use software trigger in combination with grab_image_async.
  • The HDevelop example genicamtl_do_abort_grab.hdev has been added to demonstrate how to interrupt the grab operator and stop the acquisition engine.
  • The HDevelop example genicamtl_basler_blaze_objectmodel3d.hdev has been improved to deal with producer name changes.
  • third_party_genicamtl.txt now contains links to the corresponding software location. See also Usage of third-party libraries.
• Revision 18.11.15 (Oct 7, 2022):
  • The MVTec EasyParams have been implemented to deal with the most common GenICam features in a simple and user-friendly way.
  • The new parameter 'available_easyparam_names' has been added to return the list of the MVTec EasyParams.
  • The HDevelop example genicamtl_easyparams.hdev has been added to demonstrate how to handle the MVTec EasyParams.
  • On a Unix system, loading GenICam persistence files that contained Windows line endings failed. This problem has been fixed.
• Revision 18.11.14 (May 11, 2022):
  • The underlying GenApi version has been updated to the latest official release 3.4. This fixes a crash during 'do_load_settings' when a device failed to execute the underlying command 'DeviceRegistersStreamingEnd'.
  • On a Unix system, loading Consumer persistence or configuration ini that was written on a Windows system failed. This problem has been fixed. Moreover, writing Consumer persistence or configuration ini files on a Windows system has been changed to use Unix line ending.
  • It is now possible to receive Feature Change Notifications on any parameter listed by 'available_param_names'.
  • A new parameter 'event_new_buffer' has been added which is only available as an event, see Feature Change Notifications and following.
  • There was a memory leak with each message delivered through the Event Message Queues mechanism. This problem has been fixed.
  • The identifier (key 'id') of the messages incoming on an event was not always unique. This problem has been fixed. The device name in the string ':' now corresponds with the 'unique_name' from info_framegrabber.
  • Retrieving GenICam XML description files from the host file system was broken. This problem has been fixed.
  • The calculation of the B (Y) coordinates in case of Disparity data from a Linescan device was incorrect. This problem has been fixed.
  • grab_data and grab_data_async failed when 'add_objectmodel3d_overlay_attrib' was enabled but the ObjectModel3D contained no points. This problem has been fixed.
  • The HDevelop script genicamtl_information.hdev now saves the output data into the user's Documents folder to avoid problems with missing writing permissions. Further, the script can now deal with non-alphanumerical characters in the device unique name. Moreover, a problem related to the restoring of the original trigger settings has been fixed.
• Revision 18.11.13 (Oct 20, 2021):
  • JPEG payload as specified by the GenICam GenTL and GenDC standards can now be decoded.
  • Packed Bayer formats as specified by the GigE Vision standard and the GenICam Pixel Format Naming Convention are now supported.
  • Pixel formats 'Coord3D_AC32f', 'Coord3D_AC16', and 'Coord3D_AC8' are now supported.
  • The read-write parameters of the Consumer module are streamable, i.e. they can be persisted with 'do_write_settings' or 'do_write_configuration'. However, get_framegrabber_param returned 0 for these parameters with postfix '_streamable'. This problem has been fixed.
  • The distribution package of this interface now contains files providing meta information for the HDevelop example browser.
• Revision 18.11.12 (Feb 15, 2021):
  • The underlying GenApi version has been updated to the latest official release 3.3.
  • The assembly of an ObjectModel3D from encoder-controlled Linescan 3D devices has been accelerated significantly. To allow this acceleration, the devices must announce ChunkEncoderValue and ChunkScanLineSelector through their ValueArrayCandidates as described by GenICam Standard Feature Naming Convention 2.7 and later.
  • For open_framegrabber with a device string in the 'token:value' form, it was mandatory to contain the separator ' | '. This restriction has been removed.
  • The GenICam caching mechanism was inactive unless one of the environment variables TEMP, TMP or TMPDIR was set. Now, /tmp or HALCONROOT are used as a fallback.
  • The HDevelop example genicamtl_frame_rate.hdev has been added to measure the frame rate of an acquisition device.
  • The HDevelop example genicamtl_acquisition_events.hdev ran into a deadlock in case of very quickly incoming events. This problem has been fixed.
  • The HDevelop example genicamtl_basler_blaze_objectmodel3d.hdev has been adapted to run with newer firmware versions.
  • The HDevelop example genicamtl_information.hdev has been refactored and now it calls the new procedure library genicamtl_information.hdpl. Moreover, this new version switches off TriggerMode in order to test image acquisition.
  • The error handling has been improved. Additional information about the cause of an error can now be queried with the operator get_extended_error_info. For the HALCON language interfaces (C# and C++), the HALCON exception class provides methods to access the additional error information.
  • The HDevelop example genicamtl_zivid_one_objectmodel3d.hdev has been updated to be compatible with the Zivid SDK version 2.0 or higher.
• Revision 18.11.11 (Oct 27, 2020):
  • This interface couldn't be loaded from .NET Core applications on Linux and macOS. This problem has been fixed.
  • Added support for 'YCbCr411_8_CbYYCrYY', 'YCbCr422_8' and 'YCbCr422_8_CbYCrY' pixel formats.
• Revision 13.0.10 (Sep 18, 2020):
  • Most file operations did not support UTF-8 file names. This problem has been fixed. However, some of the operations like Firmware Update are managed by GenICam GenApi which might not support them.
  • In the previous revision 'do_write_configuration' did not write the path to generated xml files into the generated ini file. This problem has been fixed.
• Revision 13.0.9 (Aug 7, 2020):
  • 'do_write_configuration' has been extended to also generate a persistence file for the GenTL Consumer (persisting internal parameters of the HALCON GenICamTL image acquisition interface itself like 'grab_timeout'), see Parameters – Persisting Device Status.
  • It is now possible to write and load persistence files for individual GenTL Producer modules or the GenTL Consumer when the device has already been opened. This was so far only possible for the remote device. The persistence file to be written or loaded is selected with the parameter 'settings_selector'.
  • When loading persistence files with open_framegrabber, some of the persisted parameter values were overwritten. This problem has been fixed.
  • On Windows, GenTL Producers that required additional dependencies, which were on the same location, but not in PATH, were in some cases not loaded correctly. This problem has been fixed.
  • get_framegrabber_param(..., 'event_message_queue', ...) failed with HALCON versions prior to 18.05. This problem has been fixed.
  • The HDevelop example genicamtl_zivid_one_objectmodel3d.hdev used to open the first GenICam device found. Now the example has been improved to open only Zivid devices.
  • The HDevelop example genicamtl_parameter_persistence.hdev has been added to demonstrate writing parameter values to files and restoring parameter values from files.
  • The HDevelop example genicamtl_basler_tof_objectmodel3d.hdev has been replaced with the new example genicamtl_basler_blaze_objectmodel3d.hdev.
  • The parameter 'available_event_names' was wrongly written as 'available_event_types'. This problem has been fixed.
• Revision 13.0.8 (Dec 10, 2019):
  • Updated underlying GenApi version to latest official release v3.2. The Update includes a bug fix on persistence of user and sequencer sets and other minor bug fixes.
  • The parameter 'num_buffers' was limited to an arbitrary maximum of 1023. This limitation has been removed.
  • The HDevelop example genicamtl_information.hdev has been added to gather information about the system and the camera configuration.
  • In the HDevelop example genicamtl_lmi_gocator_objectmodel3d.hdev, the units of the returned resolution and offset are device dependent, therefore a variable 'Units' has been added to the example.
• Revision 13.0.7 (Jul 22, 2019):
  • An HDevelop example has been added demonstrating acquiring images and a HALCON ObjectModel3D from a Zivid One 3D sensor.
  • You can now query if a feature can be persisted by using the '_streamable' postfix.
  • The HDevelop example genicamtl_parameters.hdev has been extended to check if a parameter can be persisted.
  • The file third_party_genicamtl.txt has been added to the distribution package of this interface.
• Revision 13.0.6 (May 2, 2019):
  • Added support for 'BiColorRGBG8' and 'BiColorBGRG8' pixel formats.
  • 3D object models from grab_data and grab_data_async are now generated with 2D mapping. This significantly speeds up several operators working on 3D object models.
  • The mechanism to generate a HALCON ObjectModel3D from 3D images has been extended for Disparity images. Such images need to include the following chunks specified in SFNC 2.4: 'ChunkScan3dFocalLength', 'ChunkScan3dBaseline', 'ChunkScan3dPrincipalPointU', 'ChunkScan3dPrincipalPointV'.
  • The new HDevelop example genicamtl_io_control.hdev has been added to demonstrate how to control the GPIOs of a device.
• Revision 13.0.5 (Oct 30, 2018):
  • Updated underlying GenApi version to latest official release v3.1. Please note that therefore also the genicam directory of your HALCON installation will be updated. The Update includes an accelerated MathParser, improved persistence in combination with sequencers and a fix where values were available even though the corresponding feature was not.
  • GenICam's File Access is now supported. See the new parameters 'fileaccess_file_path', 'fileaccess_remote_name', 'do_fileaccess_download', 'do_fileaccess_upload', 'do_fileaccess_delete', and the new HDevelop example genicamtl_fileaccess.hdev.
  • GenICam's FWUpdate is now supported. See Firmware Update and the new HDevelop example genicamtl_fwupdate.hdev.
  • Receiving GenICam events on message queues is now supported, see Event Message Queues. So far, GenICam events were only supported via callbacks and thus not usable in HDevelop. Additionally, two new HDevelop examples have been added to show this functionality genicamtl_acquisition_events.hdev and genicamtl_devicelost_event.hdev.
  • 'do_write_configuration' has been extended to store not only the current device configuration but also generate persistence files for all the GenTL Producer modules (system, interface, device and data stream), see Parameters – Persisting Device Status.
  • Added new parameters 'buffer_timestamp_ns' and 'device_timestamp_frequency' to improve the usability of 'buffer_timestamp' which on its own is unit-agnostic.
  • If a GenTL Producer did not implement an immediate stop of the acquisition engine (ACQ_STOP_FLAGS_KILL), stopping the engine (e.g. close_framegrabber) could lead to a deadlock. This problem has been fixed.
  • On Windows, GenTL Producers that required additional dependencies which were on the same location but not in PATH were not loaded correctly. This problem has been fixed.
  • On aarch64-linux, GenTL Producers were searched in GENICAM_GENTL32_PATH instead of GENICAM_GENTL64_PATH. This problem has been fixed.
  • Some generic parameters passed to open_framegrabber were not available through get_framegrabber_param. This problem has been fixed.
  • String parameters longer than 1024 characters were silently cropped by get_framegrabber_param. This problem has been fixed.
  • When 'start_async_after_grab_async' was set 'disable', the acquisition was stopped on the remote device after each frame. This problem has been fixed.
  • For consistency, the following examples have been renamed: genicamtl_areascan3d_objectmodel3d.hdev to genicamtl_vrmagic_areascan3d_objectmodel3d.hdev, genicamtl_gocator_objectmodel3d.hdev to genicamtl_lmi_gocator_objectmodel3d.hdev, and genicamtl_smartray_3dsensor_objectmodel3d.hdev to genicamtl_smartray_ecco_objectmodel3d.hdev.
• Revision 13.0.4 (Apr 27, 2018):
  • Added support for the 'Mono4p' pixel format.
  • Added support for the 'YCbCr411_8' pixel format.
  • Unsupported pixel formats are now tried to be returned in their actual image dimensions if they are similar enough to a supported Mono format. Before, all unsupported formats were returned as square images (see Raw Output Format).
  • On Unix systems, HALCON crashed when ended without calling close_framegrabber. This problem has been fixed.
  • When 'DeviceUserID' was set to ' ' (a single space), it could not be used to connect. This problem has been fixed.
  • When trying to connect to a busy device using its DeviceUserID, a misleading low-level error appeared. This problem has been fixed.
• Revision 13.0.3 (Nov 28, 2017):
  • The technical dependency from the HALCON Library has been removed.
  • Added support of GenTL module events. They are used just as the device events but including the module's square bracket prefix. So you can query the available module events by querying 'EventSelector_values' prefixed according to the desired module. For further information, see Event Data.
  • Added new parameter 'event_notification_helper' which enables a helper to automatically set 'EventNotification' during set_framegrabber_callback if the callback is being registered on an SFNC-compliant event. For further information, see Event Data.
  • Added new parameters 'buffer_frameid' and 'image_pixel_format'.
  • Confidence data coming as Non-Multi-Part was assigned a wrong image content. This problem has been fixed.
  • The unit of generated 3D object model coordinates was kilometer. This problem has been fixed. Now, the unit is meter.
  • When calling get_framegrabber_callback on a callback that was not registered, an error was returned. This problem has been fixed.
  • With some cameras, grab_image_async did not start a new acquisition in 'SingleFrame' or 'MultiFrame' mode even though 'start_async_after_grab_async' was enabled. This problem has been fixed.
  • An HDevelop example has been added demonstrating acquiring images and a HALCON ObjectModel3D from a SmartRay 3D sensor.
• Revision 13.0.2 (May 3, 2017):
  • Updated underlying GenApi version to latest official release v3.0.2 which contains some minor bug fixes.
  • Devices that do not provide the 'AcquisitionStart' and 'AcquisitionStop' commands were not supported. This problem has been fixed. The missing features are automatically tolerated for Camera Link devices.
  • An HDevelop example has been added demonstrating acquiring images and a HALCON ObjectModel3D from a Basler TOF sensor.
  • The interface documentation was extended and now contains a description of the strings returned by info_framegrabber(...,'info_boards',...).
• Revision 13.0.1 (Oct 28, 2016):
  • HALCON 13 version of the interface.
  • Added support for GenTL 1.5. This mainly means support for 3D data acquisition, see Using 3D Devices.
    Therefore, the operators grab_data/grab_data_async have been implemented, see Acquisition – Grab Operators.
    To control the 3D data acquisition, the following parameters have been introduced: image_contents, image_source_id, image_region_id, image_purpose_id, image_raw_buffer_type, image_raw_buffer_padding_bytes, data_contents, data_source_id, data_region_id, data_purpose_id, create_objectmodel3d, coordinate_transform_mode, confidence_mode, confidence_threshold, add_objectmodel3d_overlay_attrib.
• Revision 6.5 (May 13, 2016):
  • Updated underlying GenApi version to latest official release v3.0.1. With the previous version some specific cameras could not be opened and in the worst case the application also crashed when using such devices. This problem has been fixed. Please note that therefore also the genicam directory of your HALCON installation will be updated.
  • Under Windows, open_framegrabber crashed if the environment variable PATH was empty. This problem has been fixed.
  • Improved support for linescan cameras by querying the delivered image height for buffers first (if it is available). This also enables the use of producers for linescan cameras which do not properly update the buffer height.
• Revision 6.4 (Feb 15, 2016):
  • Updated underlying GenApi version to latest official release v3.0, which enables to open a device much faster and requires less memory. Please note that therefore also the genicam directory of your HALCON installation will be updated.
  • Added support for the 'Mono10p' and 'Mono12p' pixel formats.
  • Added paragraph 'Using internal color conversion' to this document.
  • According to this documentation, the fourth value returned by get_framegrabber_param(..., 'AnyParameter_range', ...) was a default value. Actually, it is the current value. Thus, this documentation has been adapted accordingly.
• Revision 6.3 (Oct 30, 2015):
  • The system requirements regarding the Visual Studio C++ Redistributable Package have been updated.
  • The error code H_ERR_FGABORTED (#5336) is returned by the grab operators when a grab has been aborted instead of the former H_ERR_FGF (#5306).
  • In case of devices which do not allow to stop acquisition, e.g. due to a lost connection, the call of the parameter 'do_abort_grab' was not able to abort the running grab. This problem has been fixed. Please note that in this case the communication with the device is somehow broken and re-initialization is strongly advised.
  • Added support for user-defined names. Therefore, the strings returned by info_framegrabber(...'info_boards'...) and info_framegrabber(...'device'...) have been extended to include the new entries unique_name:<unique name> and user_name:<user-defined name> which corresponds to UserDeviceID. The content of the new unique_name entry is the same as the content of the former device entry. Now, the device entry contains the user-defined name if available or the unique name. open_framegrabber now also accepts user-defined names.
• Revision 6.2 (Jun 10, 2015):
  • Under Windows, some GenICam dynamic libraries were not loaded/unloaded correctly and a low-level error was printed. This problem has been fixed.
  • do_abort_grab returned an error if called before the first grab. This problem has been fixed.
  • For 'na' (not available) parameters, neither the range nor the values property was implemented. This problem has been fixed.
  • Parameters 'grab_timeout' and 'delay_after_stop' were missing the range property. This problem has been fixed.
  • The access and visibility properties returned 'undefined' in case the parameters had no such properties. Now they return an error if they are not available.
  • 'available_param_names' returned not all implemented parameters. Now it also returns 'na' (not available) parameters in addition to 'ro' (readonly), 'wo' (writeonly) and 'rw' (readwrite) parameters, but only when the visibility is not 'invisible'. Note that the access mode of parameters might change during runtime.
  • The documentation of 'num_buffers' was not clear enough about the need of an extra buffer for internal use. The documentation has been improved.
  • Parameters 'buffer_is_incomplete', 'buffer_timestamp', 'raw_buffer_padding_bytes', 'raw_buffer_type' had fixed access mode 'ro'. In case no buffer has been grabbed yet this is wrong and should be 'na'. This problem has been fixed.
  • The HDevelop example genicamtl_parameters.hdev has been improved.
  • The HDevelop example genicamtl_gocator_objectmodel3d.hdev has been adapted to Gocator GenTL Driver version 4.x. Now X-Y-Z offset and X-Y-Z resolution are in nanometer. Moreover the TransformationZOffset is now correctly interpreted.
• Revision 6.1 (Feb 26, 2015):
  • Updated underlying GenApi version to latest official release v2.4.1, including performance improvements and several minor bug fixes. Please note that therefore also the genicam directory of your HALCON installation will be updated.
  • Aligned consumer with GenTL v1.4 specification.
  • Added support for buffer handling modes 'OldestFirstOverwrite' and 'NewestOnly', this needs to be supported by the producer.
  • Added generic parameter 'device_event_handling=0' to explicitly ignore the event channel when a device is opened.
  • Made warning about unexpected parameter types more human readable.
• Revision 5.8 (Mar 20, 2014):
  • Fixed problem when using multiple image acquisition interfaces, which do not use the same GenApi version, in arbitrary order.
  • Fixed crash when using multiple GenApi-based image acquisition interfaces which use the same GenApi version. In this case, when closing the last instance of one of the interfaces, GenApi could not be used by the remaining interfaces anymore. This fix has the side effect that GenApi cannot be unloaded anymore.
  • Improved description of parameter 'clear_buffer'.
• Revision 5.7 (Jan 31, 2014):
  • Fixed crash when trying to execute GenICam commands without parameter.
  • Fixed crash when trying to use volatile mode.
  • Improved robustness by guarding more calls with exception handling.
  • Added support for PFNC pixel format namespace. Please note that no additional conversion routines have been implemented.
  • New parameter 'register_<addr>_<len>' for direct register access.
  • Added parameters 'do_write_settings' and 'do_load_settings' to write and load GenICam persistence settings. The parameters 'do_write_configuration' and 'do_load_configuration' also support GenICam persistence now.
  • Switching of 'color_space' parameter values now has immediate effect.
  • Extended documentation of 'streaming_mode' and 'clear_buffer' parameters.
  • Renamed environment variables:
    HALCON_GENTL_WRITE_XMLFILE -> HALCON_GENICAM_WRITE_XMLFILE
    HALCON_GENTL_WRITE_RAW_XMLFILE -> HALCON_GENICAM_WRITE_RAW_XMLFILE
    HALCON_GENTL_FILE_PAYLOAD_DIR -> HALCON_ACQUIRED_FILE_PAYLOAD_DIR
• Revision 5.6 (May 24, 2013):
  • The generic parameter 'streaming_mode=0' can now be used with devices which do not provide AcquisitionStart/Stop/Mode features.
  • The internal event handling is now more robust regarding a potential race condition when killing events.
  • Fixed a crash when info_framegrabber(..., 'info_boards', ...) or info_framegrabber(..., 'device', ...) is called and no device is detected.
• Revision 5.5 (Mar 25, 2013):
  • Completely revised the entire interface implementation. Note that backward compatibility is not fully maintained in all cases, in particular some of the parameters are no more supported.
  • Improved producer and device detection and added more flexible device opening options.
  • Supports parallel open connections to devices from same and/or different GenTL Producers.
  • Extensive GenICam support including advanced features and parameter types like IRegister. GenICam 64 Bit integers are now supported also on 32 Bit systems.
  • Support of GenICam chunk data through get_framegrabber_param, removed grab_data(_async) which provided limited support for chunks in the past. The new implementation keeps the grabbed buffer at runtime until the next grab.
  • Support of GenICam events and GenICam event data through callbacks.
  • Support of GenICam feature change notifications through callbacks.
  • Added 'do_write_configuration' parameter.
  • Removed 'callback_timeout' parameter.
  • Support of devices changing basic image properties at runtime as well as GenTL Producers modifying the image.
  • Support of non-image payload types.
  • Improved support of unknown image formats as raw data.
  • Improved support for reading and writing of GenICam configuration (XML) files.
  • Support of devices with known problems with callbacks.
  • Adapted documentation.
  • Improved LMI Gocator example genicamtl_gocator_objectmodel3d.hdev. Now the Z coordinate is correctly converted to the HALCON camera coordinate system and the example shows how to load a configuration file.
  • Fixed documentation of the 'generic' parameter.
• Revision 5.4 (Nov 16, 2012):
  • Removed all dependencies on HALCONROOT environment variable.
  • Fixed XML loading so devices can be opened even when no manifest is available.
• Revision 5.3 (Oct 22, 2012):
  • Use XML with highest schema and version number from manifest.
  • Fixed handling of CLProtocol URLs.
  • Fixed wrong data size for some DSInfo calls to producer.
  • Fixed cancel_mutex locking in case of errors.
  • Removed warning messages while registering internal GenApi callbacks.
  • Added new example genicamtl_gocator_objectmodel3d.hdev for the usage of the LMI Gocator calibrated 3D sensor.
• Revision 5.2 (Sep 28, 2012):
  • Fixed a bug which can lead to a crash when opening some devices while parsing parameters.
• Revision 5.1 (Jul 11, 2012):
  • Updated GenApi to v2.3.1. Please note that therefore also the genicam directory of your HALCON installation will be updated.
  • Fixed a problem with the automatic update of the parameters Width, Height, PayloadSize and AcquisitionMode due to incorrect handling of internal GenApi callbacks.
  • Added HDevelop example program for the usage of the VRmagic AreaScan3D calibrated 3D area sensor.
• Revision 5.0 (May 15, 2012):
  • HALCON 11 version of the interface (included in HALCON 11 DVD).
  • Added support for multiple producers at once.
  • Added caching for access mode of ports.
  • Fixed URL parsing.
  • Added missing error checks but also relaxed too strict checks.
  • Added more warning messages and revised texts.
  • Relaxed GenApi callback registration code.
  • Added support for Mac OS X 10.7.
  • Use of GenApi v2.3.
• Revision 4.4 (Nov 21, 2011):
  • Fixed wrong return value in parameter 'buffer_timestamp' and changed type from integer to string.
  • Fixed adding GenICam path to PATH environment variable each time open_framegrabber was called.
  • Fixed problem when using more than one device with the same name, but different interfaces.
  • Fixed problem with starting the stream each time grab_image or grab_image_async was called.
  • Added support of chunk data via the operators grab_data and grab_data_async. Also in this document a section has been added.
  • Added functionality to get notified in case of any available device-specific event via user-specific callbacks.
  • Added mutex protection for grabbing images.
  • Added parameters 'available_callback_types' and 'callback_timeout'.
  • Added parameters 'clear_buffer' and 'verify_value'.
  • Added generic parameters 'device_access' and 'streaming_mode'.
  • Changed info_framegrabber(..'general'..) to static list.
  • Changed behavior of grab_image if AcquisitionMode of the device is 'Continuous'. Now always a new image should be returned.
  • Changed behavior of parameter 'do_write_xml_file'. Now not only the XML file of the remote device but also the XML files of the GenTL Producer's modules are written (including the name of the used GenTL Producer).
  • Changed internal color conversion to rely on the information which is provided by the current buffer. Currently, the interface uses the PixelFormat of the device, if the BUFFER_INFO_PIXELFORMAT_NAMESPACE or the BUFFER_INFO_PIXELFORMAT returns unsupported values. In this case a low-level error message will be returned.
  • Removed setting of external trigger from open_framegrabber.
• Revision 4.3 (Dec 13, 2010):
  • Changed default setting for horizontal/vertical resolution in open_framegrabber from 1 to 0.
  • Fixed parsing problems of the XML files under Linux, when opening a camera several times.
  • Fixed timeout when the image size has been changed and software trigger is used.
  • Fixed problem with setting module parameters, which in some cases led to an error.
  • Fixed error if more than one GenTL Producer was found, but one of them could not be loaded. Now the broken one is skipped and all others can be loaded correctly.
  • Improved color conversion for YUV pixel formats.
  • Added support of representation tags to show hexadecimal numbers correctly.
  • Added low-level error messages to improve error handling.
  • Added helper function to correct a value which exceeds the valid boundaries of a parameter.
• Revision 4.2 (Sep 30, 2010):
  • Changed order of starting the acquisition: Now the acquisition of the remote device is started after starting the acquisition of the GenTL Producer.
  • Fixed error when calling info_framegrabber with parameters 'info_boards', 'device' or 'general' more than once after each other.
• Revision 4.1 (Sep 10, 2010):
  • Fixed bug to prevent HDevelop crash if info_framegrabber(..., 'info_boards', ...) was called while a device was already open.
  • Fixed bug to prevent double calls of 'StartAcquisition' which led to problems with some devices.
  • Enabled use of multiple devices simultaneously.
  • Fixed memory leak.
  • Fixed bug to enable opening a device even if there exist no module parameters in the used GenTL Producer.
  • Module parameter names now start with the prefix of the corresponding module layer to ensure the uniqueness of all parameter names. Without the prefix the returned values and categories of these parameters could have been wrong.
  • If the environment variables for GenICam were not set correctly, the interface failed with H_ERR_DLOPEN. Now the delayed loading of the GenICam libraries is enabled, so that the environment variables can be set automatically.
  • Added parameters 'buffer_is_incomplete', 'buffer_timestamp', 'do_write_xml_file', 'num_buffers_await_delivery', 'num_buffers_underrun', 'tl_displayname', 'tl_filename', tl_id', 'tl_model', and 'tl_pathname'.
  • Added paragraphs 'GenICam GenTL' and 'Parameter Naming' in this documentation.
  • HALCON 10 version of the interface (included in HALCON 10 DVD).
• Revision 4.0 (Jul 30, 2010):
  • First official release.