High Performance OPC UA Server SDK
1.7.1.383
|
The purpose of this example is to demonstrate the tagfile functionality of the binary file format using the RTAddress extension.
The UA binary file format allows to add custom extensions to each node with additional information. The extension used in this example is the RTAddress, which allows to store additional implementation specific address information as string.
In this example we assume that the server uses a Modbus connection as underlying data source. Instead of a real Modbus communication, which would require a Modbus device, the implemented modbus_store uses simulation data, but shows how to access data using the Modbus address from tagfile.bin
.
The provider_tagfile loads the binary file tagfile.bin
which is created from tagfile.xml
using xml2bin
.
Files used in this lesson:
The file tagfile.xml
contains the following variables:
DisplayName | NodeId | DataType | Modbus Address |
---|---|---|---|
Temperature | ns=1;i=6001 | UInt32 | 40004 |
OilPressure | ns=1;i=6002 | UInt32 | 40002 |
Current | ns=1;i=6003 | UInt32 | 40001 |
Speed | ns=1;i=6004 | UInt32 | 40003 |
The RTAddress information can be added as XML extension to the nodeset XML file as shown in the example below. The tool xml2bin
understands this extension and converts it into its binary equivalent of the UA Binary File Format.
The example contains the usual gen.sh
script to generate the bin file from the XML source. You can also manually generate the file using this command:
How to generate binary files with extensions programmatically using he UA File Format Library is shown in the example File Writer Example.
You can use the tool filetest
to inspect the content of binary files like this:
The function ua_addressspace_load_file_ext() can be used to load binary files and process the extensions. Unlike the simpler function ua_addressspace_load_file(), this function allows specifying callbacks, which are defined in ua_file_callbacks.
Example:
The callbacks add_extension_namespace
and add_extension
are used in this example for processing the RTAddress extension. Extensions are organized in namespaces (like UA namespaces) to avoid ambiguities in their numeric extension type. The extensions defined by Unified Automation are defined in the namespace UA_EXTENSION_UNIFIEDAUTOMATION_URI.
The first step is mapping the expected extension URI to it's numeric namespace. Every time the add_extension_namespace
is called we check for the URI and store the numeric nsidx for this URI when found.
The next step is processing the extensions itself. Therefor we check for the extension's nsidx and it's type (UA_EXTENSION_RUNTIMEADDRESS). When found we process this runtime address.
In this example we know it is a Modbus address with this syntax: "modbus://<address>". We use sscanf()
to parse this address and register the variable at the modbus_store as show in this code snippet.
Modbus Address Parsing:
The complete callback implementation including the extension filtering code and additional trace information looks like this: