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

(This GigEVision2 interface replaces the old, deprecated HALCON acquisition GigEVision interface. Users switching from the previous implementation of the GigEVision acquisition interface to this new version, GigEVision2, please pay attention to the section highlighting differences between the two interface versions for easy transition).

• Intel compatible PC with Windows 7 (32-bit or 64-bit) or newer, also WoW64 (using 32-bit HALCON on 64-bit Windows), Linux with kernel 2.6 (or higher) , or macOS.
• Gigabit Ethernet network adapter. 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, to reduce the amount of interrupts. 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 configuration allows your application or HDevelop to connect to the camera and to receive incoming images, otherwise the grabbing will fail. Cameras that support firewall traversal might work anyway.
• MVTec GigE Vision Streaming Filter under Windows x86, WoW64 or Windows x64: The HALCON GigEVision2 interface automatically uses a filter driver to enhance the performance while streaming images. When installing HALCON the filter driver will be automatically installed, if you enable the corresponding check box during installation.
  Please make sure that at least the driver version v2.1.8.0 is actually installed (check your network properties). Older driver versions will not work! For full functionality you need driver version v2.1.8.2.
• GenICam version 3.0.2 . The corresponding files are part of the HALCON GigEVision2 package and are located in the directory genicam within the HALCON base directory %HALCONROOT%.
• Windows: HALCON image acquisition interface hAcqGigEVision2.dll or hAcqGigEVision2xl.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 hAcqGigEVision2.so or hAcqGigEVision2xl.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 hAcqGigEVision2.dylib or hAcqGigEVision2xl.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.

The interface can be controlled through several environment variables:

• 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.
• 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.

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
  • The genicam folder to /Library/Frameworks/HALCON.framework/Libraries
  • The examples folder to the version subdirectory at /Users/Shared/Library/Application Support
  • The doc folder to the version subdirectory at /Library/Application Support

• User-space implementation of the GigE Vision protocol.
  For Windows the MVTec GigE Vision Streaming Filter is available and used automatically if installed to improve performance.
• Support for GigE Vision 1.x up to 2.x (preliminary support for upcoming 2.1 multipart payload)
• Grabbing from multiple cameras.
• Synchronous and asynchronous grabbing.
• Grabbing of 3D data and creation of object model 3d.
• Support of Jumbo frames and automatic packet size optimization.
• Software control of all generic camera parameters using GenApi.
• Software control of transport layer-dependent parameters.
• Support of various pixel formats and flexible color transformation.
• No Administrator or root privileges required, except for the installation of the filter driver (and internal thread priority control).
• Support of Forced IP.
• Support of 'Continuous', 'SingleFrame', and also 'MultiFrame' 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 (devices that can be controlled by means of GenICam, but do not stream any image (or other) data.
• Support of pending acknowledges which allow to wait for device response to long taking commands without needing to manually adjust the timeout.

• The MVTec GigE Vision Streaming Filter is available only under Windows. For more details see paragraph MVTec GigE Vision Streaming Filter.
• No support of BayerXXPacked, BGRXXPlanar, and RGBXXPlanar pixel formats yet.
• Only stream channel 0 supported.
• No support of acquisition from devices with read-only access mode
• On 32 bit systems, 64 bit parameter values cannot be used.
• The new SFNC 'Transfer Control' features are currently not considered for acquisition control – there are currently not enough devices with such functionality on the market.

• This interface uses GenApi version 3.0.2, 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 GigEVision2 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, Windows uses %TEMP% and Linux/macOS use $TMP or /tmp if $TMP is not set for cached XML files.

• This interface implements GigE Vision specification version 2.0, covering all three basic protocols it defines: control, image/data streaming including chunk data and asynchronous device events.
• The interface also provides support for the new functionality proposed for (not yet ratified) specification version 2.1, including in particular the multi-part streaming used e.g. by 3D devices.
• The device features control is accessed via GenApi.
• To provide a consistent user experience, the control features of the GigE Vision Producer of this interface are also controlled via GenApi.

To ensure full access to the device, the following preconditions have to be fulfilled:

General:

• If a firewall is active in the system, it has to be configured in a way so that all applications expected to be using the GigE Vision devices (e.g. HDevelop, but also any user-developed applications) have full access to the connected devices. Cameras that support firewall traversal might work anyway.
• If possible, guarantee that the used devices are configured properly to match IP configuration of the network interface they are connected to (either by means of Persistent IP configuration of the device or by means of DHCP).
• If the device's IP configuration does not match that of the network interface the device is connected to, the HALCON GigEVision2 acquisition interface will discover the device, but will mark it as inaccessible and opening it will not be possible.
• If you are using the HDevelop Image Acquisition Assistant, it will automatically prompt you to add the correct generic parameter to force a suitable temporary IP address to the device. Please keep in mind that this temporary IP address will not survive the device's power cycle. It is still desirable to configure the device properly (Persistent IP or DHCP) so that it starts with suitable IP configuration upon next power up.

Linux:

• On Linux, the discovery of misconfigured (wrong subnet) devices might not be possible if 'reverse path filtering' is switched on in the system. Reverse path filtering is a security option dropping incoming packets on the interface if the reverse path traffic (to the source of the incoming packet) would not be routed on that interface. In practice this means that the discovery packet where the device announces itself would be dropped. To prevent this, we recommend to switch off reverse path filtering option on any interfaces where GigE Vision devices are to be discovered (perhaps unless you are sure that the devices will never be misconfigured). To temporarily disable reverse path filtering on eth0, execute
  sudo sysctl -w net.ipv4.conf.all.rp_filter=0
  sudo sysctl -w net.ipv4.conf.eth0.rp_filter=0
  To make the changes permanent, adjust these options in the sysctl configuration file (such as /etc/sysctl.conf or /etc/sysctl.d tree):
  net.ipv4.conf.all.rp_filter=0
  net.ipv4.conf.eth0.rp_filter=0

• For Windows x86 and x64 a so-called 'filter driver' is available. It is used automatically, if it is installed and activated. This kernel mode driver enhances the performance and should be used if possible.
• Installation:
  When installing HALCON the filter driver will be installed automatically, if you enable the corresponding check box during installation.
  The filter driver can also be installed separately by the installer in %HALCONROOT%\misc. To do this, close all your network connections and execute the installer as administrator. It will install and enable the filter on all your Ethernet interfaces. The driver files will additionally be placed in %HALCONROOT%\..\GevStreamingFilter.
  To disable the filter for a specific interface, you can deselect the 'MVTec GigE Vision Streaming Filter' in the network interface properties. The filter driver can be uninstalled completely by the uninstaller in %HALCONROOT%\..\GevStreamingFilter. To do this, close all your network connections and execute the uninstaller as administrator.
  Please reboot after the installation of the driver to make sure it can be used.
• Update Installation:
  For updating from an older version of the 'MVTec GigE Vision Streaming Filter', please de-install the old version first before installing the new version (see instructions above). Please reboot to make sure the new version will be used.
• Note that the filter driver is officially signed with Microsoft Authenticode, but not WHQL-certified, i.e., the installation might warn that the driver is not Windows logo certified. This warning can be safely ignored.
• The generic parameter 'force_sockdrv' is available, when it is necessary to disable the use of the filter driver for a specific device.
• The parameter '[Stream]GevStreamActiveEngine' can be queried to check if a specific device uses the filter driver.
• The filter driver may run out of kernel memory, although there is enough free user memory. Please decrease the generic parameter 'num_buffers' in this case.
• If the filter driver cannot be used, the underlying GVSP streaming is performed in user-space by the socket driver which increases the CPU load.
• When using the MVTec GigE Vision Streaming Filter some parameters behave different from socket driver as documented.

• The recommended way of using multiple cameras is to attach each camera to its own interface.
• If cameras share a single interface, you need to calculate the resulting load on the link. You can do this roughly, if you multiply the size of one image with the frame rate. This means, e.g., for a VGA gray-scale image with a depth of 8 bit per pixel and a frame rate of 100 frames/s:
  640*480*1 Byte*100/s = 3072000 Byte/s or about 30 MByte/s
  As a GigE link can transport about 120 MByte/s, theoretically 4 cameras can be attached to one link, in practice it might be limited to 3 cameras. The reason for this smaller number is the overhead for the GVSP protocol and maybe necessary resends, which the above calculation does not take into account. Also depending on the behavior of the camera and the network interface the single packets of the frames (also called blocks) are sent as a burst or equally distributed over a frame time.
  Additionally, the behavior of the necessary network equipment, like a switch, needs to be taken into account and might result in using small packets and even loss of packets.
  In such case adjusting network relevant parameters like device's inter-packet delay might be necessary to improve the performance. When in doubts, follow also performance related recommendations of the corresponding device manufacturer.

The connection to the (acquisition) device is established through the open_framegrabber operator. The operator provides a set of parameters allowing to configure the basic properties of the device and how the HALCON GigEVision2 interface controls it – see corresponding section. Some of the parameters can be also modified at runtime through set_framegrabber_param. This section concentrates solely on the 'Device' parameter of open_framegrabber, identifying the device (usually camera) that should be opened.
A connection to the device accessible through the GigEVision2 interface is established using the device ID which is guaranteed to be unique per GigE Vision device and (usually) stays persistent across multiple sessions. Optionally, the connection can be further defined through the interface ID, defining a single network interface of the host to be used for device lookup. Instead of the unique device ID, the user-defined name attached to the device can be used. Finally, it is also possible to use the IP address of the device.
The list of all devices currently available in the system can be at any point obtained using info_framegrabber parameter 'device' or 'info_boards' – see corresponding section. Both parameters return a list of devices, each specified using the above listed entities in the format ' | device:<device id> | ... | interface:<interface id> | ... ', where '<device id>' is either the unique device ID or a user-defined name ('DeviceUserID'). If a user-defined name is set on the device, 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. The full string (obtained from the info_framegrabber call) can be directly used for the 'Device' parameter of open_framegrabber, it uses the same format. Only the ' | device:<device id>' string entry is mandatory for open_framegrabber, the others might be omitted.

If you know the device ID in advance, you can create the string yourself – without using info_framegrabber. As shown above, it consists of entries separated by ' | ', the 'device' entry being the only significant one. The optional 'interface' entry specifies the network interface to look for the device.
When a string without any ' | ' separator is used, it is interpreted directly as the device ID.
As a special case, the string 'default' can be used – in this case the HALCON acquisition interface will use the first available device (devices currently reported as non-accessible will be skipped). Note that when using the same 'default' string again, that device will no more be accessible, therefore the next accessible device will be opened. This way, all devices connected to the system may be easily opened in a loop.

Note that the current version of the interface supports only single-stream devices and the first available stream is always open. If support for devices with multiple image streams will be added in future, the format to open the device might be extended with the stream entry.

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

• Features of the connected device ("remote device"), typically a camera, are usually loaded directly from the connected device.
• Features of the GigE Vision Producer are exposed through a set of GenICam description files, one for each internal entity to control the device tree:
  • The "system" – representing the overall behavior of the acquisition interface
  • The interface used to connect the device to the system.
  • A proxy (called "local device") to the device, controlling the GigE Vision Producer 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 GigE Vision 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_THE_SYSTEM_MODULE% 
InterfaceFile=%PATH_TO_GENICAM_FILE_OF_THE_INTERFACE_MODULE% 
DeviceFile=%PATH_TO_GENICAM_FILE_OF_THE_LOCAL_DEVICE_MODULE% 
StreamFile=%PATH_TO_GENICAM_FILE_OF_THE_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.

The following groups of parameters exist:

• Internal parameters of the HALCON GigEVision2 image acquisition interface itself. These are named following the "underscore" naming style, e.g., color_space, and are all lowercase.
• GenICam-based parameters of the device, usually a camera, use by convention the "CamelCase" style, e.g., ExposureTime.
• GenICam-based parameters of the individual GigE Vision 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 GigE Vision Producer (ie. 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 GigE Vision Producer and are shared among all devices open within this GigE Vision 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 and when the GenICam feature in question is identified to be an IP or MAC address, the string representation of the address 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 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). The persistence functionality consists of two steps, storing the current configuration to a file and later re-loading it back to the device. The current device settings 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 file is intentionally human readable and the file 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 file can lead to errors when using it.

It is important to know that while performed by the software, the feature settings persistence is actually a camera-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 camera manufacturer could provide additional information or help.

The same persistence file can be applied to the entire set of devices of the same type and firmware version. Applying the persistence file 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 also generate persistence files for all the GigE Vision 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_THE_SYSTEM_MODULE% 
InterfacePersistence=%PATH_TO_PERSISTENCE_FILE_OF_THE_INTERFACE_MODULE% 
DevicePersistence=%PATH_TO_PERSISTENCE_FILE_OF_THE_LOCAL_DEVICE_MODULE% 
StreamPersistence=%PATH_TO_PERSISTENCE_FILE_OF_THE_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 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. Note that some of the camera 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', ...).
Note that the interface properly recognizes the 'Continuous', 'SingleFrame' and 'MultiFrame' acquisition modes configured on the device and adjusts the acquisition control logic accordingly.
Note that the HALCON acquisition interface itself 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.

It can happen, that the camera is temporarily or constantly acquiring data in higher speed than the application is processing them. In such case the streaming engine of the GigE Vision Producer decides how to treat the acquired buffers based on the '[Stream]StreamBufferHandlingMode' parameter.

Note that the streaming engine behavior can be further controlled through additional parameters described in Advanced Streaming Engine Control.

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.
The HALCON GigEVision2 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 , 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 GigEVision2 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 'raw_buffer_type' and '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.
It is important to remember, that the chunk data related features will provide only 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 GigE Vision Producer.
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 GigE Vision Producer (system, interface, device and data stream). The information provided above about handling of the device events applies similarly also to the GigE Vision 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 GigE Vision 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 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 GigE Vision Producer through the GenICam description files. The list of supported targets can be queried by calling get_framegrabber_param(..., 'available_event_types', ...).
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. 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>:<device>'. 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. 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 available.

The streaming engine attempts to work well for all standard use cases. However, to reach optimal performance (whatever that means from perspective of each application), fine-tuning some parameters might be desirable to match given device type and application needs. One important aspect of the GigE Vision streaming protocol is management of resend-requests for missing packets (which can get lost between the device and application due to various reasons including in particular high CPU load). The control of the resend-requests might need to be considered both from application perspective (preferring low latency and high throughput or high reliability) as well as from device perspective (fixed predictable packet/block timing versus irregular streaming expectable eg. for line scan cameras). It is desirable that based on known characteristics of the device and the system the resend requests are neither issued too late (the device might no longer store copies of those packets) nor too early (which can lead to duplicate packets being sent).
The engine can therefore be configured through various stream parameters including '[Stream]GevStreamMaxPacketGaps', '[Stream]GevStreamMaxBlockDuration', or '[Stream]GevStreamDeliverIncompleteBlocks'. When changing a parameter, it will be passed to the packet handling engine at closest suitable point (typically when re-queueing a buffer back to the engine) and applied to subsequent buffer acquisitions.
On the other hand, the engine provides various statictics that might help to observe its performance and behavior and help to fine tune the input parameters. The statistics include for example '[Stream]GevStreamLostPacketCount', '[Stream]GevStreamResendCommandCount', or '[Stream]GevStreamIncompleteBlockCount'. The statistics are updated regularly and reset on each acquisition start.
Refer to the documentation of the stream parameters for complete list and details.
If the stream filter driver is not used, the ability to process incoming data has a heavy effect on the performance of the streaming engine. This is strongly affected by the priority of the streaming engine thread relative to other threads in the system. Refer to the documentation of the parameters '[Stream]StreamThreadPriority', '[Stream]StreamThreadSchedulingPolicy' and '[Stream]StreamThreadApplyPriority' for details. Upon device open, generally suitable default priority is selected.
Finally, the streaming infrastructure can be completely disabled using the 'streaming_mode=0' generic parameter while opening the device.

The event engine works well for standard use cases. However, in specific use cases, the behavior must be fine tuned. The parameters described in this section are intended for this advanced use only and should be treated with care - wrong configuration can significantly affect performance.
The event engine thread priority is controlled by the parameters '[Device]DeviceEventsThreadPriority', '[Device]DeviceEventsThreadSchedulingPolicy' and '[Device]DeviceEventsThreadApplyPriority'. Upon device open, generally suitable default priority is selected.
The event handling infrastructure can be completely disabled using the 'device_event_handling=0' generic parameter while opening the device.

When debugging applications using GigE Vision devices, it is important to know that a core concept of the GigE Vision protocol is maintaining connection with the device using the regular 'heartbeat' packets. When the application stops maintaining the heartbeat, the device disconnects. The HALCON GigEVision2 handles the heartbeat control fully transparently, but there is a specific case when it cannot do so - when the application is being debugged and hits a breakpoint. In such case all threads are typically halted, including the one responsible for heartbeat maintenance.
To prevent loosing connection to the device while debugging, it is possible to significantly prolong the heartbeat timeout period or fully disable the heartbeat control on the device. Learn details from description of the parameters '[Device]DeviceLinkHeartbeatTimeout' and '[Device]DeviceLinkHeartbeatMode'.

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 GigEVision2 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 GigE Vision 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 addtional 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 gigevision2_fwupdate.hdev.

Parameter	Value List	Type	Kind	Description
'bits_per_channel'	[-1, 8, 10, 12, 14, 16]	integer	pre-defined	Values for bits per channel.
'camera_type'	['CAMFILE:', 'ini;xml', '<path>', 'default']	string	pre-defined	Syntax for connection configuration file and default value.
'color_space'	['default', 'gray', 'raw', 'rgb', 'yuv']	string	pre-defined	Values for color space.
'defaults'	[0, 0, 0, 0, 0, 0, 'progressive', -1, 'default', -1.0, 'false', 'default', '0', 0, 0]	mixed	pre-defined	Default values for open_framegrabber.
'device'	[' | device:<device id> | unique_name:<unique name> | user_name:<user-defined name> | interface:<interface id> | producer:Esen | device_ip:<device ip>']	string	dynamic	List of GigE Vision devices discovered in the system with information about their device ID, unique name, user-defined name, interface to which they are connected and identifier of the image acquisition interface. See the full description in section about device opening. Only devices that are currently available for opening are listed.
'external_trigger'	[]			Ignored.
'field'	[]			Unused.
'general'	[]	string	pre-defined	Information about the HALCON GigEVision2 interface.
'generic'	['', 'num_buffers=<num>', 'direct_connection=<mode>', 'force_ip=<interface_ip/device_mac/force_device_ip/force_device_mask[/force_device_gateway/force_command_timeout]>', 'force_sockdrv=1', 'streaming_mode=0', 'device_event_handling=0', 'workarounds=<list>']	string	pre-defined	Value list for the Generic parameter.
'horizontal_resolution'	[0, 1]	integer	pre-defined	Value list for horizontal resolution.
'image_height'	[]			Unsupported query.
'image_width'	[]			Unsupported query.
'info_boards'	[' | device:<device_id> | unique_name:<unique_name> | user_name:<user_defined_name> | interface:<interface_id> | producer:Esen | vendor:<device_vendor> | model:<device_model> | device_ip:<device_ip> | interface_ip:<interface_ip> | status:<device_status> | suggestion:<generic_param>']	string	dynamic	List of GigE Vision devices discovered in the system with additional information as a string. Some values are only shown, if they are available. For misconfigured devices (such as those having an IP of a wrong subnet) a corresponding generic parameter to resolve the problem is suggested. device_id is the name of the device, which will be shown by info_framegrabber(...,'device',...). If a user_name (or 'DeviceUserID') is set, then this will be shown. Otherwise the unique_name is used. unique_name is a string, which contains the device MAC address, the vendor and the model separated by underscores. No other device should have the same string, so this is a unique name for the device. user_name represents the value of the feature 'DeviceUserID', which is a user-defined name for the device. It can be set if the device is opened and provides this feature. interface shows the hardware interface by which the device is connected to the PC. For GigEVision2 the value of this entry is 'Esen_ITF_' with the MAC address, IP and subnet mask of the the network interface card appended. producer shows the name of the underlying GenICamTL producer. vendor represents the value of the feature 'DeviceVendorName'. model represents the value of the feature 'DeviceModelName'. tl_type shows the type of the underlying transport layer, i.e. 'U3V'. device_ip shows the IP address of the device, e.g. 169.54.12.243/16. This value can also be queried by the feature 'GevCurrentIPAddress'. interface_ip is the IP address of the interface (mostly a network card), which has detected the device by a broadcast request, e.g. 169.54.18.34/16. status shows, if the device is correctly configured or not. The possible values are 'available', 'read-only', 'busy', 'misconfigured' and 'unknown'. For misconfigured devices (such as those with IP settings for incorrect subnet) a corresponding generic parameter to resolve the problem is suggested through the suggestion info token. Status of 'busy' means the device is currently opened by another application. Even devices that are currently not available for opening are listed. suggestion is added only if status is reported as 'misconfigured' because the device is on wrong subnet. The value of the suggestion info will be the generic 'force_ip' parameter that can be used to resolve the problem. This means that if you will pass the suggested 'force_ip' parameter as-is in the open_framegrabber operator's Generic parameter (see its documentation), the GigEVision2 interface will attempt to switch the device temporarily to correct subnet and open it.
'parameters'	['<parameters>']	string	pre-defined	Pre-defined parameters of the HALCON interface.
'parameters_readonly'	['<parameters>']	string	pre-defined	Pre-defined read-only parameters of the HALCON interface.
'parameters_writeonly'	['<parameters>']	string	pre-defined	Pre-defined write-only parameters of the HALCON interface.
'port'	[]			Unused.
'revision'	'<revision>'	string	pre-defined	Revision number of the GigEVision2 interface.
'start_column'	[]			Unsupported query.
'start_row'	[]			Unsupported query.
'vertical_resolution'	[0, 1]	integer	pre-defined	Value list for vertical resolution.

Parameters for open_framegrabber