XML2BIN Generator

Table of Contents

• Invoking xml2bin
• Locale Handling
• Extensions

The xml2bin tool can be used to generate binary information model files from XML NodeSet files. This is explained in more detail in section Address Space Generation.

Invoking xml2bin

The possible command line arguments can be listed by calling the tool with the option -h as usual: ./xml2bin -h. The help also gives you one simple example.

Usage: xml2bin [-h] [-o <outputfile>] [<base xml files...>] <xml file...>
 -h: print this help
 -V: print version information
 -s: strip unused type nodes (experimental)
 -f <cat>: filter node by category. This option can be specified multiple times.
 -o: output file name
 -a: export all namespace (except ns0)
 -e <val>: select extensions to export where <val> can be 'none', 'default', or 'all'.
    none: no node extensions will be exported.
    default: all known Unified Automation extensions will be exported.
    all: All extensions will be exported. Unkown will be stored as XML extension also in the binary file
         so that they can be handled on application level.
 -i: specifies a SDK nsidx to export
 -u: specifies an namspace URI to export
 -v: more verbose output
 -b: byte string limit in byte (default = 4 MB = 4096 KB = 4194304 Byte)
 -p: print addressspace
 -l: default locale (default="auto")
 <base xml files>: must be specified in correct order, starting with the base model,
   followed by models built on top of the previous model.
 <xml file>: The information model which gets processed.
Example: Convert the DI model to binary.
  xml2bin -i2 -v -o di.bin Opc.Ua.NodeSet2.xml Opc.Ua.Di.NodeSet2.xml

Important Notes:

• You need to list all NodeSet XML file in correct order which are required to load the XML file which you want to convert. In the example above this was the DI model, which is based on standard UA model (which is always required). E.g. PLCOpen would require DI, which again requires UA, so the list of files would be: Opc.Ua.NodeSet2.xml Opc.Ua.Di.NodeSet2.xml Opc.Ua.Plc.NodeSet2.xml
• -o: Specifies the output filename e.g. 'di.bin'.

• -i select this namespace to be exported.

  The namespaces in the server are normally numbered that way:

  • 0=UA (This is always the UA model http://opcfoundation.org/UA/)
  • 1=UA Server Diagnostics (Generated at runtime by the server)
  • 2=First custom model (e.g. DI)
  • 3=Second custom model (e.g. PLCOpen) If unsure just call the command without -i. It will print the namespace table.

$> ./xml2bin Opc.Ua.NodeSet2.xml Opc.Ua.Di.NodeSet2.xml Opc.Ua.Plc.NodeSet2.xml
SDK Index       XML Index       Prefix  URI
0               0               ua      http://opcfoundation.org/UA/
2               2               ns2     http://opcfoundation.org/UA/DI/
3               1               ns3     http://PLCopen.org/OpcUa/IEC61131-3/

Important here is the SDK Index, which is the index that will be used in the SDK and must be unique. The column XML Index, shows the numeric index used in the XML file which is not unique across files. Prefix is used only for code generation. URI is the unique URI of the information model. Instead of selecting the SDK Index using -i you can also select the model using the option -u and the URI string.

Note that you cannot export SDK Index=1, because the server generates this at runtime. For this reason it is also missing in the xml2bin output above.

Locale Handling

Even though the OPC UA Binary File Format supports multiple languages like the XML Nodesets, the xml2bin currently can only extract one locale.

The XML parsing code of xml2bin is the same as in xml2c. Please see Locale Handling for more information on this topic.

Extensions

XML NodeSet files can contain extensions. xml2bin can convert known extensions into a binary version of this extension. The extension UA_EXTENSION_RUNTIMEADDRESS is such an extension. See Tagfile Server Example for a detailed example on this topic.

Unknown XML extensions can also be converted into the binary extension UA_EXTENSION_XML, which keeps all XML contents as-is. This allows application to load such custom extensions and parse the XML code at runtime.

By default all known Unified Automation extension will get converted, others will be ignored. You can influence this using the option -e <value>:

Option Value	Description
none	Don't export any extensions.
default	Export all known Unified Automation extensions like e.g. UA_EXTENSION_RUNTIMEADDRESS.
all	Export all extensions.