OPC_UA I/O Interface for OPC UA compliant devices

This page provides the documentation of the HALCON OPC UA interface. Only interface-specific parameters and features are described here. For general information of the operators for I/O interfaces please have a look at the HALCON Operator Reference.
Registered customers can download the latest revision of this interface from the MVTec WWW server.

• Intel compatible PC with Windows 10 (64-bit) or newer that is also supported by the vendor-specific SDK, Linux with kernel 6.X (or higher).
• Windows: HALCON I/O device interface hioOPC_UA.dll or hioOPC_UAxl.dll, respectively. Also required are libcrypto-3-x64.dll, libssl-3-x64.dll, and uastack.dll. 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 I/O device interface hioOPC_UA.so or hioOPC_UAxl.so, respectively. Also required are the third-party libraries libcrypto.so.3, libssl.so.3, and libuastack.so. If you have properly installed the interface, the shared objects should reside in lib/$HALCONARCH, and the third-party shared libraries in lib/$HALCONARCH/thirdparty within the HALCON base directory $HALCONROOT you have chosen during the installation of HALCON.
  

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. 18.11.5. The first two numbers describe the minimum HALCON version the interface is compatible with. For the example version 18.11.5 this means that the interface is compatible with all HALCON versions since HALCON 18.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:

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

Starting with version 20.11.7, this interface uses OpenSSL 3.

• Implementation of an OPC UA client.

• The OPC UA I/O interface returns and expects all strings in UTF-8 encoding.
• Only Binary data encoding supported. No OPC UA XML or JSON data enconding support.
• No support for OPC UA over MQTT.
• No PubSub support.
• All dates and times are assumed to be UTC.
• On 32-bit systems, 64-bit OPC UA integer values (both signed and unsigned) cannot be properly represented. They can only be used if the actual value fits within a 32-bit integer.
• OPC UA node IDs are limited to a maximum of 255 characters in their XML representation. This can lead to problems with the 'translate' control_io_device action and the 'browse' query_io_device parameter if the server has very long node IDs.
• The only types of OPC UA user tokens currently supported are Anonymous and UserPassword.
• OPC UA multi-dimensional arrays are not supported.

The open_io_device operator is used to connect to an OPC UA server. Specify the URL of the server to connect to in the IODeviceName parameter. The server URL is generally in the form 'opc.tcp://Server' or 'opc.tcp://Server:Port' if the server is not using the default OPC UA port (4840).

If the server you wish to connect to is registered with an OPC UA discovery server, you can get its URL from the query_io_interface operator using the 'io_device_names' generic parameter if the discovery server is reachable via the URL 'opc.tcp://localhost:4840', or from the control_io_interface operator using the 'discovery' action if it is not. Please see the example opc_ua_discovery.hdev for details. The following security policies are supported:

• http://opcfoundation.org/UA/SecurityPolicy#Aes128_Sha256_RsaOaep
• http://opcfoundation.org/UA/SecurityPolicy#Aes256_Sha256_RsaPss
• http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15
• http://opcfoundation.org/UA/SecurityPolicy#Basic256
• http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256
• http://opcfoundation.org/UA/SecurityPolicy#None

OPC UA has a rich set of data types that have to be mapped to the HALCON control tuple data types integer, real and string on input and output. HALCON OPC UA I/O device interface supports the following built-in OPC UA data types and their derivatives:

• NodeId
  This type is converted to or from HALCON strings following the OPC UA XML schema. The syntax is as follows:

  'ns=<namespaceindex>;<type>=<identifier>'

  <namespaceindex> is the index of the namespace, formatted as a base 10 number. If the index is 0, the entire 'ns=0;' clause can be omitted. A server's namespaces can be determined by calling the get_io_device_param operator for the 'namespaces' parameter; the namespaces are returned in the order of their indexes.
  

  <type> is a flag specifying the type of <identifier>. The following values are possible:

  • i (numeric) - the identifier is a number.
  • s (string) - the identifier is a string.
  • g (guid) - the identifier is a GUID string.
  • b (opaque) - the identifier is an (opaque) byte string.

  <identifier> is the identifier encoded as a string using the XML data type mapping for the identifier type. The identifier may contain any non-NULL UTF-8 character.
  Please note that due to a limitation in the OPC UA SDK used by the interface, when converting from a node ID to a HALCON string if the node ID does not fit within 255 characters, it is truncated and cannot be used to identify nodes.
  

• ExpandedNodeId
  This type is converted to or from HALCON strings with the following syntax:

  '<Server>|<NamespaceURI>|<NodeId>'

  <Server> is the index of the server, formatted as a base 10 number.

  <NamespaceURI> is the URI of the namespace to use, overriding the namespace specified in the <NodeId>. The reserved characters & and | have to be escaped with a prefixed &, e.g. | must be written as &|.

  <NodeId> is a node ID written in the OPC UA XML schema as detailed above.

• QualifiedName
  This type is converted to and from HALCON strings. These strings can be used directly as path elements for the translate action of control_io_device. The syntax of the string is as follows:

  '[<ns>:]<name>'

  <ns> is the (optional) namespace index, written as one or more digits and followed by a :. If the namespace is not specified, a namespace of 0 is assumed.
  

  <name> is the name. The reserved characters /, ., <, >, #, !, or & have to be escaped with a prefixed &, e.g. < must be written as &<.

• LocalizedText
  These are converted to or from HALCON strings using the following syntax:

  '<locale>|<text>'

  <locale> is the locale ID as defined in RFC 3066, e.g. 'en' for English.
  

  <text> is the text, encoded in the specified locale.
  

• Boolean
  A boolean value, translated to and from the HALCON strings 'true' and 'false'.
• SByte, Int16, Int32, and Int64
  These types are translated to and from HALCON integer values. On 32-bit systems, 64-bit integers outside the range of a 32-bit integer cannot be represented.
• Byte, UInt16, UInt32, and UInt64
  These types are translated to and from HALCON signed integer values. An unsigned value outside the range of HALCON's signed integers is represented as the signed integer corresponding to the bit pattern of the unsigned integer. On 32-bit systems, 64-bit integers outside the range of a 32-bit integer cannot be represented.
• ByteString
  This data type is converted to and from a tuple of HALCON integer values in the range [0..255] or as a HALCON memory block handle.
• DateTime
  The date is translated to and from the number of seconds since January 1, 1970 as a HALCON real value.
• Double and Float
  These types are translated to and from HALCON real values.
• Guid, String and XmlElement
  These types are represented as HALCON strings. Please note that the OPC UA I/O interface returns and expects all strings in UTF-8 encoding.
• X.509 certificates
  While X.509 certificates are not an OPC UA data type per se; they are used to identify servers and clients when creating secured connections. X.509 certificates are represented in HALCON as a Base64 encoded string of the DER encoding of the certificate.
  
  The interface supports the derivative types of the built-in OPC UA data types. These types are converted to and from HALCON data types just like the built-in OPC UA types they are derived from. However, consider that working with these types might imply additional restrictions or requirements on the accepted values, please refer to your server documentation, as handling these restrictions is left to the user.
  
  The interface also supports OPC UA complex data types that inherit from Structures, Unions, OptionSet and Enumerations. Please refer to the official documentation PART 3 'Address Space Model', PART 5 'Information Model', and PART 6 'Mappings' by the OPC Foundation if you require additional details. Please consider the following notes:
• Enumerations
  Represent a list of defined numerical values. The nodes that inherit from this data type are always represented as Int32 by OPC UA. These nodes may have one of the two optional properties EnumStrings or EnumValues that provide the human readable representation the Enumeration values. Please see the example opc_ua_enumeration.hdev for more information.
• Structures
  These nodes represent a group of variables (fields) that can be of any data type known to the server. Reading or writing to a Structure is done using HALCON dictionaries. The field name is used as key for the dictionary value. Structures can have mandatory and optional fields. If a field is mandatory, it will/must always be present on the dictionary. If a field is optional the value might be absent. In the case that a Structure contains fields with complex data types, the dictionary will/must contain additional dictionaries with the corresponding values. Please see the example opc_ua_structure.hdev for more information.
• Unions
  These nodes are a special type of Structure that allows to store different data types (built-in or complex) in the same node. There can be unions with many fields, but only one field can be active at any given time. Reading or writing to a union is done using HALCON dictionaries. The 'SwitchField' key must/will always be provided when writing/reading and the value of the node must be provided by using the field name as Key for the value in the dictionary. The switch value and the field name must correspond with each other. Setting or getting a SwitchField of value 0 means that the Union is not set, so no value needs to be provided or be available. Please see the example opc_ua_union.hdev for more information.
• OptionSet
  These nodes are a special type of Structure to represent a bit mask. Reading or writing to a union is done using HALCON dictionaries. Each OptionSet type has a property 'OptionSetValues' that contains the human-readable representation for the corresponding bit used in the OptionSet. The value of an OptionSet variable is composed of two mandatory fields 'Value' and 'ValidBits'. The field 'Value' is a ByteString representing the bits in the OptionSet. The length of the ByteString depends on the number of bits. The field 'ValidBits' is a ByteString with the same size as 'Value'. When you read an OptionSet the 'ValidBits' provides information of which bits in the bit mask have a meaning. If a bit is 1 then the corresponding bit in the value is valid. If it is set to a 0 it should be ignored. When writing a value to a variable, the 'ValidBits' defines which bits should be written. Only those bits defined in 'ValidBits' (set to 1) are changed in the bit mask, all others are not written. Please see the example opc_ua_option_set.hdev for more information.
  
  
• Arrays
  The interface also supports one dimensional arrays. A variable node with an array of one of the base data types will be mapped to a HALCON tuple. For ByteString arrays, where each array element is mapped to a tuple, the complete array is transformed into a tuple of dictionaries. Each dictionary stores the ByteString under the special key 'h_values'. If doing a multi channel read or write, and one of the channels is an array, the array values are stored in a tuple inside a dictionary under the special key 'h_values'. If calling a method, and one of the input arguments of output arguments is an array, the array values are stored in a tuple inside a dictionary under the special key 'h_values'. Multi dimensional arrays are not supported. If the parameter 'use_memory_blocks' is enabled on the channels, the values of ByteString nodes will be returned as HALCON memory block handles and the previous explanation with HALCON dictionaries and tuples no longer applies.

When writing a variable node the OPC UA interface internally needs to know a concrete data type in order to correctly compose the write request to the server. The default behavior for the interface is to internally cast the tuple values to the OPC UA DataTypes Int64, String or Double if no additional information is provided. Additionally, it is possible to specify one of the built-in data types for a variable using HALCON dictionaries, to do this the dictionary for a value must contain the following two keys:

• h_values : Must contain the tuple value to be written.
• h_types : Must contain one built-in type as a String. e.g., XmlElement, UInt64, Float, etc.. The handles of the dictionaries can be grouped in a tuple to write a variant array that contains different types.

OPC UA nodes are referenced by using their node ID written as a string following the OPC UA XML schema as the channel parameter in the query_io_device and open_io_channel operators. See the section on converting OPC UA data types above on how to write node IDs. In addition to writing the namespace's index, you can also write the namespace's URI enclosed in ^ characters.

The following are all valid ways to refer to the server's ServerStatus node:

'i=2256'
'ns=0;i=2256'
'ns=^http://opcfoundation.org/UA/^;i=2256'

Event handling via message queues is supported on the device-level and on the channel-level. On the device-level, this can be used to receive messages when the connection status to the server changes. On the channel-level, subscriptions to variable nodes data changes and for fired events, based on the available EventTypes on the object node, are supported. A message queue handle to a channel or device can be provided to receive updates on the available events. The process to start monitoring events is the following:

1. Open the device or a channel to a node (variable or object instance).
2. Get a list of the available events on the device or channel by using the parameter 'available_event_names'.
3. (For EventTypes) From the available events use the 'event_selector' to start the configuration process.
4. (For EventTypes) From the selected event query the available event data using the parameter 'available_event_data'.
5. (For EventTypes) From the available event data set the data you are interested on by using the 'event_data' parameter.
6. Provide a message queue handle to the channel or device by using the parameter 'event_message_queue'. As soon as the message queue handle is registered updates will start becoming available.
7. Handle the incoming messages in the message queue with the attached event data.
8. Removing/Stopping event updates is done by setting the parameter 'event_message_queue' to 0 (or HNULL).

After dequeuing a message for an event, the information contained in the message can be accessed using the operator get_message_tuple. The message will always contain the following information:

• id: String composed of the name of the interface plus the address of the server. Eg. 'OPC_UA:opc.tcp://Server:Port'
• event_name: String with the name of the triggered event. e.g., 'DataChange', 'ConnectionStatusChange', '0:TransitionEventType', etc.

Depending on the event additional data might be attached to the message:

• For ConnectionStatusChange events:
• connection_status: The new status of the server connection. It uses the same values as the 'connection_status' parameter.
• For DataChange events:
• node_id: The node ID of the node that triggered the event.
• status_code: The status code of the updated value.
• value: The new updated value of the node.
• For EventType events:
• The attached data depends on what was set using 'event_data' parameter.

Message queues are handled in a FIFO manner, therefore handling multiple variable and/or event subscriptions in the same message queue requires processing all incoming events as they become available.

Please see the following examples for more information:

• opc_ua_monitor_subscription.hdev
• opc_ua_monitor_connection.hdev
• opc_ua_monitor_event.hdev

control_io_interface(::IOInterfaceName, Action, Argument:Result)

Perform an action on the I/O interface.

query_io_interface(::IOInterfaceName, Query:Result)

Query information about the specified I/O device interface.

open_io_device(::IOInterfaceName, IODeviceName, GenParamName, GenParamValue:IODeviceHandle)

Open and configure an I/O device.

control_io_device(::IODeviceHandle, Action, Argument:Result)

Perform an action on the I/O device.

set_io_device_param(::IODeviceHandle, GenParamName, GenParamValue:)

Configure a specific I/O device instance.

get_io_device_param(::IODeviceHandle, GenParamName:GenParamValue)

Query settings of an I/O device instance.

There may exist additional parameter attributes, which can be accessed as 'ParamNames.AttributeName'. The following standard attributes may be available:

• '.access': This attribute provides the access permissions of the corresponding parameter as a string. Possible values are 'ro' (read-only), 'wo' (write-only), 'rw' (read/write), 'na' (unavailable, perhaps due to insufficient access rights), and 'ni' (unavailable, not defined for this device or channel).
• '.category': This attribute provides the category of the corresponding parameter as a string. 'I/O interface' for all pre-defined I/O interface parameters.
• '.default': This attribute provides the default value of the corresponding parameter.
• '.description': This attribute provides the description of the corresponding parameter as a string.
• '.displayname': This attribute provides the displayname of the corresponding parameter as a string.
• '.range': This attribute provides the minimum and maximum, (and the step width, if applicable) for the corresponding integer or float parameter as a tuple with 2 (or 3) elements.
• '.representation': This attribute provides how the value of the parameter should be displayed in a GUI: 'ip address', 'hex', ...
• '.tooltip': This attribute provides the tool-tip of the corresponding parameter as a string.
• '.type': This attribute provides the HALCON value type (integer, real, or string) of the corresponding parameter as a string.
• '.values': This attribute provides the valid value list for the corresponding parameter as a tuple.
• '.visibility': This attribute provides the visibility of the corresponding parameter as a string. Possible values are 'common', 'extended', and 'dangerous'.
• '.unit': This attribute provides the units of the corresponding parameter as a string. For example: 'ns', 'us' and 'ms', or 'mm', 'cm', 'dm' and 'm'.

query_io_device(::IODeviceHandle, IOChannelName, Query:Result)

Query information about channels of the specified I/O device.

open_io_channel(::IODeviceHandle, IOChannelName, GenParamName, GenParamValue:IOChannelHandle)

Open and configure I/O channels.

control_io_channel(::IOChannelHandle, Action, Argument:Result)

Perform an action on I/O channels.

set_io_channel_param(::IOChannelHandle, GenParamName, GenParamValue:)

Set specific parameters of I/O channels.

get_io_channel_param(::IOChannelHandle, GenParamName:GenParamValue)

Query specific parameters of I/O channels.

There may exist additional parameter attributes, which can be accessed as 'ParamNames.AttributeName'. The following standard attributes may be available:

• '.access': This attribute provides the access permissions of the corresponding parameter as a string. Possible values are 'ro' (read-only), 'wo' (write-only), 'rw' (read/write), 'na' (unavailable, perhaps due to insufficient access rights), and 'ni' (unavailable, not defined for this device or channel).
• '.category': This attribute provides the category of the corresponding parameter as a string. 'I/O interface' for all pre-defined I/O interface parameters.
• '.default': This attribute provides the default value of the corresponding parameter.
• '.description': This attribute provides the description of the corresponding parameter as a string.
• '.displayname': This attribute provides the displayname of the corresponding parameter as a string.
• '.range': This attribute provides the minimum and maximum, (and the step width, if applicable) for the corresponding integer or float parameter as a tuple with 2 (or 3) elements.
• '.representation': This attribute provides how the value of the parameter should be displayed in a GUI: 'ip address', 'hex', ...
• '.tooltip': This attribute provides the tool-tip of the corresponding parameter as a string.
• '.type': This attribute provides the HALCON value type (integer, real, or string) of the corresponding parameter as a string.
• '.values': This attribute provides the valid value list for the corresponding parameter as a tuple.
• '.visibility': This attribute provides the visibility of the corresponding parameter as a string. Possible values are 'common', 'extended', and 'dangerous'.
• '.unit': This attribute provides the units of the corresponding parameter as a string. For example: 'ns', 'us' and 'ms', or 'mm', 'cm', 'dm' and 'm'.

read_io_channel(::IOChannelHandle:Value, Status)

Read a value from the specified I/O channels. If multiple channels are specified, they must all belong to the same device.

write_io_channel(::IOChannelHandle, Value:Status)

Write a value to the specified I/O channels. If multiple channels are specified, they must all belong to the same device.

close_io_channel(::IOChannelHandle:)

Close I/O channels.

close_io_device(::IODeviceHandle:)

Close the specified I/O device.

This interface depends on third-party libraries. See the file third_party_opc_ua.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".

This software uses OpenSSL 3 for secure communication with OPC UA servers. It was configured and built with the options no-idea, no-mdc2, no-ntt, and no-rc5 to avoid patent issues.

On Linux, you can use the system-provided OpenSSL libraries if they are binary compatible with OpenSSL 3 by removing libcrypto.so.3 and libssl.so.3 from the directory $HALCONROOT/lib/$HALCONARCH/thirdparty.

If bugs are found in the version of OpenSSL provided by MVTec and you do not want to wait for an update of the interface, you can compile and use your own version.

For this interface the following examples are available:

• opc_ua_browse_variables.hdev - Shows how to browse the available nodes on an OPC UA server. information about the expected datatypes.
• opc_ua_channel_access.hdev - Shows how to read and write OPC UA variable nodes.
• opc_ua_discovery.hdev - Shows how to query an OPC UA discovery server to find OPC UA servers to connect to.
• opc_ua_enumeration.hdev - Shows how to read and write Enumeration variable nodes on an OPC UA server.
• opc_ua_methods.hdev - Shows how to call a method on the OPC UA server and how to query
• opc_ua_monitor_subscription.hdev - Shows how to monitor values by creating a subscription to a variable node.
• opc_ua_monitor_connection.hdev - Shows how to asynchronously monitor the status of the server connection.
• opc_ua_option_set.hdev - Shows how to read and write OptionSet variable nodes on an OPC UA server.
• opc_ua_parameters.hdev - Shows how to determine which parameters are supported.
• opc_ua_security.hdev - Shows how to connect to an OPC UA server using OPC UA's security features.
• opc_ua_structure.hdev - Shows how to read and write Structure variable nodes on an OPC UA server.
• opc_ua_union.hdev - Shows how to read and write Union variable nodes on an OPC UA server.
• opc_ua_monitor_event.hdev - Shows how to monitor events from an object instance on an OPC UA server.
• opc_ua_image.hdev - Shows how to read and write variable nodes with data type ByteString or its sub-types (ImagePNG, ImageJPG, etc.) as memory block handles.

• Revision 24.11.10 (Apr 9, 2026):
  • The Unified Automation OPC UA SDK has been updated to version 2.0.2.
  • Libxml2 has been updated to version 2.15.2.
  • OpenSSL has been updated to version 3.5.5 (LTS).
  • When using the parameter 'create_certificate' in the control_io_interface operator, it was not possible to set an absolute path as a location for the recipe store. This problem has been fixed.
  • In certain cases, attempting to open multiple channels could result in a crash if one of the connections failed (e.g., if NodeId was incorrect). This problem has been fixed.
• Revision 24.11.9 (Oct 8, 2025):
  • It is now possible to write Byte and SByte arrays using memory block handles.
  • Reading a variable with a Null value resulted in an exception. It will now instead return an empty tuple.
  • The Unified Automation OPC UA SDK has been updated to version 1.8.8.
  • Libxml2 has been updated to version 2.13.8.
  • OpenSSL has been updated to version 3.0.16 (LTS).
  • 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 20.11.8 (Oct 9, 2024):
  • Update documentation to reflect supported security policies.
  • Update limitations documentation to reflect the current state of OPC UA including data encoding and new ways of communication like PubSub.
  • The Unified Automation OPC UA SDK has been updated to version 1.8.4.
  • Libxml2 has been updated to version 2.13.2.
• Revision 20.11.7 (Apr 18, 2024):
  • OpenSSL has been updated to version 3.2.1.
  • The Unified Automation OPC UA SDK has been updated to version 1.8.3.
  • MacOS is no longer supported.
• Revision 20.11.6 (Aug 1, 2023):
  • Querying the 'event_data' of data change events of variable nodes, which do not deliver event data, led to a crash. This problem has been fixed and now an empty tuple is returned.
  • third_party_opc_ua.txt now contains links to the corresponding software location. See also Usage of third-party libraries.
• Revision 19.11.5 (Oct 7, 2022):
  • OpenSSL has been updated to version 1.1.1k.
  • The Unified Automation OPC UA SDK has been updated to version 1.7.7.
  • Support for reading and writing variant scalar and array nodes of type BaseDataType has been added.
  • It is now possible to read and write empty arrays to/from variable nodes using empty HALCON tuples.
  • It is now possible to create a subscription to monitor events fired from object nodes.
  • The new HDevelop example opc_ua_monitor_event.hdev has been added to show how to monitor events from object nodes.
  • It is now possible to use HALCON memory block handles to read and write variable nodes of the ByteString data type or one of its sub-types (ImagePNG, ImageJPG, etc.). This feature is only available in HALCON versions starting from 22.11 and higher.
  • The new HDevelop example opc_ua_image.hdev has been added to show how to read and write ByteStrings and its sub-types as HALCON memory block handles.
• Revision 19.11.4 (Oct 20, 2021):
  • Closing multiple channel handles using a single call to close_io_channel crashed or locked the application. This problem has been fixed.
  • On Linux the OpenSSL library was linked statically into the interface. This problem has been fixed.
  • The distribution package of this interface now contains files providing meta information for the HDevelop example browser.
  • When a server pushed a monitored item update for a variable that the client has already unregistered the interface crashed. This problem has been fixed.
• Revision 19.11.3 (Oct 27, 2020):
  • This interface couldn't be loaded from .NET Core applications on Linux and macOS. This problem has been fixed.
• Revision 19.11.2 (Aug 27, 2020):
  • Support for OPC UA server methods has been added.
  • The new HDevelop examples opc_ua_methods.hdev has been added to show how to call method nodes and how to query the arguments.
  • OpenSSL has been updated to version 1.1.1g.
  • The Unified Automation OPC UA SDK has been updated to version 1.7.2.
  • Support for "OPC UA Amendment 11 - Spatial Types" data types RationalNumber, 3DVector, 3DCartesianCoordinates, 3DOrientation and 3DFrame has been added.
• Revision 19.11.1 (Oct 9, 2019):
  • This version of the OPC UA interface will only work in its complete form for HALCON versions starting from 19.11 and higher.
  • The new parameter 'status_code_to_string' has been added. It returns the string representation of an OPC UA status code.
  • The new parameter 'data_type_definition' has been added. It returns the data type definition of the value of a variable node (channel).
  • The parameters 'fields', 'enum_values' and 'option_set_values' now return the information inside a HALCON dictionary. In older versions of this interface, the information was returned inside a tuple.
  • The parameters 'fields', 'enum_values' and 'option_set_values' now throw an exception, if used on a channel which is not of the correct meta type. In older versions of this interface, an empty tuple was returned.
  • It is now possible to query information about DataType nodes directly using query_io_device and the node ID. The parameters 'data_type_definition', 'fields', 'enum_values' and 'option_set_values' are now available for this purpose.
  • OpenSSL has been updated to version 1.1.1c.
  • The Unified Automation OPC UA SDK has been updated to version 1.7.0.
  • The new HDevelop example opc_ua_monitor_connection.hdev has been added to show how to monitor connection status changes of an OPC UA Server by using message queues.
  • The new HDevelop example opc_ua_structure.hdev has been added to show how to read and write Structure variable nodes.
  • The new HDevelop example opc_ua_enumeration.hdev has been added to show how to read and write Enumeration variable nodes.
  • The new HDevelop example opc_ua_union.hdev has been added to show how to read and write Union variable nodes.
  • The new HDevelop example opc_ua_option_set.hdev has been added to show how to read and write OptionSet variable nodes.
  • The file third_party_opc_ua.txt has been added to the distribution package of this interface.
  • The section Usage of third-party libraries has been added to this document.
  • The HDevelop examples opc_ua_read_struct.hdev and opc_ua_read_write_complex_data_types.hdev have been removed in favor of simpler examples for each complex type.
  • The HDevelop example opc_ua_browse_variables.hdev has been updated to provide additional information of each node when browsing and to have a simpler interface.
  • The HDevelop examples opc_ua_monitor_subscription.hdev, opc_ua_channel_access.hdev have been updated to handle complex data types.
  • The limitation of doing multi-channel read and write operations with arrays of ByteStrings, Structures, OptionSets and Unions values has been removed. The values are now read or written as HALCON dictionaries with a single key 'h_values' that contain the node values.
  • Complex types Structures, OptionSets and Unions now use HALCON dictionaries for read and write.
  • The limitation of not being able to read or write complex types that contain other complex types or arrays as one of their fields has been removed. In those cases that value will be returned as a HALCON dictionary.
  • The read support for "OPC UA Part 8: Data Access" data types Range, EUInformation, XVType, ComplexNumberType, DoubleComplexNumberType and AxisInformation has been added.
• Revision 13.0.7 (Jun 11, 2019):
  • The param_names parameter on query_io_device and get_io_channel_param did not return a correct result. This problem has been fixed.
  • Opening a channel failed if the value of the node was Null. This problem has been fixed.
  • When creating a self signed certificate using 'create_certificate' on Windows, HALCON crashed. This problem has been fixed.
• Revision 13.0.6 (Nov 30, 2018):
  • The string transcoding between HALCON and OPC UA was not taken into account for all cases. Now UTF-8 encoding is ensured for all OPC UA strings.
  • It was not possible to write a node with a derived data type outside of the built-in type. This limitation has been removed.
  • query_io_device crashed when querying the attributes of a node without specifying it. This problem has been fixed.
  • Add support for 'DataChange' event on OPC UA variable nodes with HALCON message queues.
  • Add example to show how to subscribe to variable value changes using HALCON message queues.
  • Update OpenSSL to version 1.0.2p
  • Update to version 1.6.2 of the Unified Automation OPC UA SDK.
  • Allow the user to disable the security checks that prevents the client for sending unencrypted passwords without user interaction. This can be caused by server misconfiguration or lack of encryption support. The added parameters are encrypt_password_check and trusted_certificate_for_user_token.
• Revision 13.0.5 (Nov 28, 2017):
  • The technical dependency from the HALCON Library has been removed.
  • When browsing a node with a lot of references if it required a continuation point a crash occurred. This problem has been fixed.
  • If the certificate data was set to null on an OPC UA server HALCON crashed. This problem has been fixed.
• Revision 13.0.4 (Sep 29, 2017):
  • Moved libcrypto.so.1.0.0, libssl.so.1.0.0, and libuastack.so to a subdirectory on Linux systems.
  • Add support for flat Structures, OptionSets, Unions and Enumerations.
  • Add examples for the new data types.
  • Fix connectivity problem with Prosys servers.
  • Update OpenSSL to version 1.0.2l
  • Update to version 1.5.5 of the Unified Automation OPC UA SDK.
• Revision 13.0.3 (Apr 28, 2017):
  • Accept expanded node IDs for nodes located on the same server.
• Revision 13.0.2 (Mar 6, 2017):
  • Fix bug setting 'float' variables to values <= 0.
  • Update OpenSSL to version 1.0.2j
  • Update to version 1.5.4 of the Unified Automation OPC UA SDK
• Revision 13.0.1 (Oct 28, 2016):
  • HALCON 13 version of the interface.