 |
UaModeler
1.6.5.472
|
|
UaModeler
1.6.5.472
|
To edit the following settings, choose Settings → Edit Settings from the menu bar. The settings are split into three groups: UaModeler, Code Generation, and Modeling.
If Check for Updates is enabled, UaModeler regularly checks whether an update is available. You can specify the Update Interval in days using the respective input field. If this value is set to 0, UaModeler checks for updates on every start-up.
To manually check for updates, choose Help → Check for Updates… from the menu.
If Generate Date is checked, the current date will be written into the headers of the generated files (see screenshot).
To prevent that generated files are accidentially overwritten, a dialog window appears if a file to be generated already exists. You can change this default behavior. There are four options:
If Overwrite all or Overwrite none is selected, the files which would replace existing files are written to a temporary directory. If you would like to manually overwrite some or all of these files, choose Project → Overwrite generated files manually from the menu bar. A dialog window will open (see screenshot) where it is possible to select the files to overwrite.
In the Author section of the dialog you can add some infomation about the author. This data will be written into the headers of the generated files:
In this section you can set information that is related to other products of UnifiedAutomation.
You can set the installation location of sdks from UnifiedAutomation and of license files that are needed for generated code here. UaModeler tries to find the sdks at standard installation paths.
Depending on the template set that is selected for code generation the sdk libraries are referenced by the generated code or tools that are shipped with the sdk are called during code generation.
There have been some changes in the XML schema for NodeSet2 XML files. The following settings have been added to create XML files that are valid for the old schema.
The schema of NodeSet2 XML files changed with OPC UA specification 1.04. The DataType of the AccessLevel attribute has been changed from UInt8 to UInt32 to be able to store the new bits defined in the OPC UA variable attribute AccessLevelEx. If an XML importer checks whether the XML file is valid using the old schema file, it cannot load it.
With the setting “Disable Export of AccessLevelEx” disable the exporting of the bits defined in AccessLevelEx. If the setting is set, the AccessLevel attributes in the exported XML file are valid for the old XML schema.
In OPC UA specification 1.04 the XML attributes UserAccessLevel and UserExecutable in NodeSet2 XML files have been marked as obsolete. They should not be used anymore. However some XML importers try to evaluate the attributes. If the attributes are not existing, default values are used. But the default values (CurrentRead for UserAccessLevel and “true” for UserExecutable) do not match to the attributes AccessLevel and Executable.
You can enable exporting the attributes UserAccessLevel and UserExecutable with this setting.
By default, the user cannot edit the NodeIds of UaNodes in custom models: The UaModeler sets the NodeIds and takes care that they are unique. You can enable the editing of the NodeIds by checking the box “Enable editing of NodeIds”. For types, the NodeIds have to be numeric, for instances, all kinds of NodeIds are allowed. If you choose to edit the NodeIds by hand, the UaModeler will still check if they are unique.
By default, the user cannot edit the NodeIds of encoding nodes of structured DataTypes in custom models. The UaModeler sets the NodeIds and takes care that they are unique. You can enable the editing of the encoding NodeIds by checking the boxes “Enable editing of NodeIds” and “Enable editing of Encoding NodeIds”. UaModeler only supports numeric NodeIds for NodeIds of encoding nodes. If you choose to edit the NodeIds by hand, the UaModeler will still check if they are unique.
JSON encoding was defined in OPC UA specification 1.04. If the application shall be able to support JSON encoding for structured DataTypes, the structured DataTypes shall have JSON encoding nodes.
This setting is used for new models. You can add or remove JSON encoding nodes with the dialog Update Encoding nodes.
In OPC UA specification 1.04 the attribute DataTypeDefinition was defined for DataTypes. This attribute describes the fields of structured DataTypes or enumerations. Generic clients which are based on OPC UA specification 1.04 can read this attribute to get the structure definition of DataTypes. In this way these clients are able to interpret the received the received data when reading the value of a Variable with a structured DataType.
Before OPC UA specification 1.04 the information about the fields of structured DataTypes was published in the OPC UA addressspace by dictionary nodes. These dictionary nodes shall be added to model if the server does not support the DataTypeDefinition attribute and it is expected that generic clients that do no evaluate the new attribute will connect to the server.
If it is expected that only clients which have knowledge about the structure definitions at compile time, the DataType dictionary nodes are not required.
If this setting is active, DataType dictionary nodes will be added for new models which define structured DataTypes.
You can add or remove dictionary nodes with the dialog Update Encoding nodes.
This setting specifies if DataType dictionary nodes are kept or removed when an existing model is imported.
These settings can be used to control the behavior of the NodeAccessInfo extension.
NodeAccessInfo is disabled by default. Check the box NodeAccessInfo enabled to enable it. It will then show up in the Extensions View.
The drop-down menu Mode allows you to select the mode to use for NodeAccessInfo. See Enabling NodeAccessInfo for more information.
If Add Default Roles is checked, a set of default roles/groups to be used for NodeAccessInfo is enabled (see Adding Users and Groups).
User Defined Extensions are disabled by default. Check the box User defined extensions enabled to enable them. UaModeler’s XML editor to display and edit user defined extensions will then show up in the Extensions View.
The input field Default Extension Namespace URI can be used to define the namespace to use for user defined extensions (see User Defined Extensions). Leave the field empty to disable this feature.
The Documentation enabled setting enables and disables the editor for Node Documentation. The editor for Node Documentation is disabled by default. You can enable it by checking Documentation enabled.
The Table and List Support setting specifies if tables and lists can be entered in a Markdown like style.
By checking Disable Code Generation you can specify whether the documentation entered in the extensions editor should be included in generated code. Generic documentation is included nevertheless and cannot be disabled.
If Support multiple namespaces in one XML file is checked, such XML files can be added using the “Add Existing Model” dialog. It is not possible to use them for updating a model from a file.
If Allow replacing built-in Namespace 0 model is checked, a different version of the namespace 0 model than the sipped one can be selected when creating new UaModeler projects. The code generation is only tested with the built-in model, so code generation may not work properly when using other models.
We recommend to replace the built-in namespace 0 model only for modeling-only use cases.