Datatype tables¶
ncc c datatypes generates C structs and datatype tables from BSD definitions
and CSV NodeIds. Use these alongside the address-space code from ncc c
for models with custom datatypes.
Try it with MySimple.bsd and MySimple.csv:
This creates types_mymodel_generated.c, .h and .ncc.json in generated/.
The output argument is a path without an extension; the directory is created
if needed. Keep the metadata (.ncc.json) beside the generated C and header files.
Wiring it to ncc c¶
For your own model, replace the input paths and namespace mapping below:
ncc c datatypes -c NodeIds.csv -t MyTypes.bsd \
--namespaceMap 2:urn:my:model ./generated/types_mymodel
ncc c MyModel.xml -e Opc.Ua.NodeSet2.xml \
--bsd MyTypes.bsd -t UA_TYPES_MYMODEL -o ./generated
The names must match: output basename types_mymodel produces the array
UA_TYPES_MYMODEL and header types_mymodel_generated.h.
Compile both generated .c files and make their headers available to the build.
See CMake integration for build setup and
datatype options for imports, filtering and opaque mappings.
Namespace ownership¶
- Supply
--namespaceMap INDEX:URIfor each custom BSDTargetNamespace. The example uses index2forurn:my:model; namespace-qualified CSV IDs must agree. - The mapping sets indexes for standalone use. With ncc metadata, server initialization resolves the actual indexes by namespace URI.
- Address-space generation finds metadata in its output directory. For tables
elsewhere, pass
--types-metadata path/to/types_mymodel_generated.ncc.jsonand the array with-t. Regenerate tables and metadata together if validation fails.
Initial values require UA_ENABLE_XML_ENCODING. Load dependency models first.
Each generated datatype registry supports one server; repeated initialization and
sharing between servers with different namespace orders are unsupported.
See runtime configuration.
Reuse upstream tables¶
Existing open62541-generated tables need no ncc metadata. Preserve their array order, output basename and runtime namespace assumptions: automatic namespace correction requires metadata. See the migration example.
Generate a complete model¶
Generate address-space code, datatype tables and NodeId constants together:
ncc c model MyModel.xml -e Opc.Ua.NodeSet2.xml \
--csv MyModel.NodeIds.csv --shortname mymodel -o generated
The command uses an embedded BSD dictionary, or accepts --bsd MyModel.Types.bsd.
If both are present, they must agree. XML <Definition> elements alone do not
supply C layouts. Models without custom layouts can omit CSV and BSD inputs.
Output in generated/ |
Content |
|---|---|
mymodel.c, mymodel.h |
Address-space initializer. |
types_mymodel_generated.c, .h, .ncc.json |
Datatype tables and namespace metadata. |
mymodel_nodeids.h |
Constants such as NCC_MYMODEL_ID_MYVARIABLE. |
mymodel.ncc.json |
Generated file list and initializer name. |
Choose shortnames that remain distinct after lowercasing. Regeneration replaces these files. NodeId constants contain only the numeric ID; resolve the model's namespace URI when constructing a complete NodeId.
For dependencies, supply XML with -e, arrays with -t, and metadata outside the
output directory with --types-metadata. Import referenced custom layouts with
--import 'UA_TYPES_DEP#Dependency.Types.bsd'. Link dependency sources and load
their initializers first.
Standalone namespace indexes follow the target XML URI order unless overridden
with --namespaceMap INDEX:URI. Server initialization resolves indexes by URI.
See ncc c model --help for additional options.
Generate only NodeId constants¶
Generate a header from CSV without XML, BSD or an SDK:
This produces constants such as UA_NS0ID_MYVARIABLE; the prefix is case-sensitive.
CSVs can use commas, semicolons or tabs, optional headers and UTF-8 BOMs, with
names or numeric IDs first. Invalid IDs or C symbols fail generation; duplicate
macros are preserved and may cause C compiler redefinition errors.
See the migration guide for upstream naming.
Extract only an embedded BSD dictionary¶
This preserves the decoded dictionary bytes and leaves the XML unchanged. Exactly one distinct BSD dictionary is required; identical copies are accepted. Missing, malformed or conflicting dictionaries fail without replacing the output. Layouts are not synthesized from XML definitions. See the migration guide for existing workflows.