EM83: Integration test found difference in JobListElementType about open62541-nodeset-loader HOT 11 CLOSED

Did you notice the following too?

Id = ns=3;i=3024 DATATYPE
BrowseName = ns=3;ConfigurationParameterType
DisplayName = :ConfigurationParameterType

reference Server:
[
Name = Unit
Description = :
DataType = i=0
ValueRank = -1
ArrayDimensions = []
MaxStringLength = 0
IsOptional = 0
]

test server:
[
Name = Unit
Description = :
DataType = i=887
ValueRank = -1
ArrayDimensions = []
MaxStringLength = 0
IsOptional = 0
]

DataType i=0 at the reference server seems very odd to me.

But UaExpert client shows the same result ...
At least the integration client does not have a bug (hopefully)

The unit field should be of type EUInformation as in the test server.

.bsd:

 <opc:StructuredType BaseType="ua:ExtensionObject" Name="ConfigurationParameterType">
  <opc:Field TypeName="opc:UInt32" Name="Id"/>
  <opc:Field TypeName="ua:LocalizedText" Name="Description"/>
  <opc:Field TypeName="ua:Variant" Name="DefaultValue"/>
  <opc:Field TypeName="ua:EUInformation" Name="Unit"/>
 </opc:StructuredType>

Maybe the nodeset-compiler has a bug.
I remember that I had problems generating the code for Euromap83 with EUInformation. I had to indicate the .bsd file of namespace 0 with IMPORT_BSD statement. Otherwise it wouldn't compile.

# generate euromap83 namespace which is using DI
ua_generate_nodeset_and_datatypes(
    NAME "integration_test_euromap_83"
    FILE_CSV "${PROJECT_SOURCE_DIR}/nodesets/euromap/Opc.Ua.PlasticsRubber.GeneralTypes.NodeSet2.csv"
    FILE_BSD "${PROJECT_SOURCE_DIR}/nodesets/euromap/Opc.Ua.PlasticsRubber.GeneralTypes.NodeSet2.bsd"
    IMPORT_BSD "UA_TYPES#${open62541_NODESET_DIR}/Schema/Opc.Ua.Types.bsd"
    NAMESPACE_IDX 3
    FILE_NS "${PROJECT_SOURCE_DIR}/nodesets/euromap/Opc.Ua.PlasticsRubber.GeneralTypes.NodeSet2.xml"
    DEPENDS "integration_test_di"
    INTERNAL
)

Maybe there's something wrong here.

I'll answer to your previous question asap.

from open62541-nodeset-loader.

Referring to PlannedProductionTime:

I have generated the .bsd file with an online base64 decoder, because Euromap does not provide a .bsd file.
I took the DataTypeDictionary bytestring of the XML Opc.Ua.PlasticsRubber.GeneralTypes.NodeSet2.xml
There should not have been an error at base64 decoding, etc.

At first I thought that the .bsd maybe only allows built-in DataTypes.

But the DataType duration is described in the namespace 0 .bsd of OpcFoundation ...
https://github.com/OPCFoundation/UA-Nodeset/blob/master/Schema/Opc.Ua.Types.bsd

I don't know if this was intended by the Euromap committee.
Or they thought it does not matter because the en/decoding as you have already mentioned is the same.

I haven't found a lot information in the Opc specifications.

Part 3: 5.8.2 Encoding Rules for different kinds of DataTypes:
https://reference.opcfoundation.org/v104/Core/docs/Part3/5.8.2/

Built-in DataTypes are a fixed set of DataTypes (see OPC 10000-6 for a complete list of Built-
in DataTypes). They have no encodings visible in the AddressSpace since the encoding should
be known to all OPC UA products. Examples of Built-in DataTypes are Int32 (see 8.26) and
Double (see 8.12).

Simple DataTypes are subtypes of the Built-in DataTypes. They are handled on the wire like
the Built-in DataType, i.e. they cannot be distinguished on the wire from their Built-in
supertypes. Since they are handled like Built-in DataTypes regarding the encoding they cannot
have encodings defined in the AddressSpace. Clients can read the DataType Attribute of a
Variable or VariableType to identify the Simple DataType of the Value Attribute. An example of
a Simple DataType is Duration. It is handled on the wire as a Double but the Client can read
the DataType Attribute and thus interpret the value as defined by Duration (see 8.13).

I am not sure if the nodeset-compiler parses the tags from the XML or only uses the .bsd file for DataType information.
It uses an opaque type mapping array (opaque_type_mapping.py) ...
'Duration': {
'ns': 0,
'id': 11,
'name': 'Double'
},

I need to think about all this.

from open62541-nodeset-loader.

The nodesetCompiler uses the bsd for generating the types. When I import the xml, I take the information of the xml and skip the information of the base64 encoded bsd. This explains the difference.

from open62541-nodeset-loader.

I didn't notice the difference on datatype EM83;i=3024 - the nodesetcompiler generates this code for the members:

/* ConfigurationParameterType /
static UA_DataTypeMember ConfigurationParameterType_members[4] = {
{
UA_TYPENAME("Id") / .memberName /
UA_TYPES_UINT32, / .memberTypeIndex /
0, / .padding /
true, / .namespaceZero /
false, / .isArray /
false / .isOptional /
},
{
UA_TYPENAME("Description") / .memberName /
UA_TYPES_LOCALIZEDTEXT, / .memberTypeIndex /
offsetof(UA_ConfigurationParameterType, description) - offsetof(UA_ConfigurationParameterType, id) - sizeof(UA_UInt32), / .padding /
true, / .namespaceZero /
false, / .isArray /
false / .isOptional /
},
{
UA_TYPENAME("DefaultValue") / .memberName /
UA_TYPES_VARIANT, / .memberTypeIndex /
offsetof(UA_ConfigurationParameterType, defaultValue) - offsetof(UA_ConfigurationParameterType, description) - sizeof(UA_LocalizedText), / .padding /
true, / .namespaceZero /
false, / .isArray /
false / .isOptional /
},
{
UA_TYPENAME("Unit") / .memberName /
UA_TYPES_EUINFORMATION, / .memberTypeIndex /
offsetof(UA_ConfigurationParameterType, unit) - offsetof(UA_ConfigurationParameterType, defaultValue) - sizeof(UA_Variant), / .padding /
false, / .namespaceZero /
false, / .isArray /
false / .isOptional */
},};

The last member has typeIndex UA_TYPES_EUINFORMATION, this is correct, but the namespace zero flag is not correct, it should be namespace zero.

When I manually set the namespaceZero flag, the difference is gone. -> This is an nodesetCompiler issue.

from open62541-nodeset-loader.

Regarding EM83;i=3024 - EUInformation - nodeset-compiler bug.
I'll try to fix it or open an issue at open62541 repository.

Regarding the different types from .bsd and xml (double vs. duration):

Probably both implementations (nodeset-compiler and NodesetLoader) are ok.

Do you know if there are any nodeset XMLs which only use the DataTypeDictionary bytestring and do not provide the DataType information in the XML?

Regarding the integration test:
I could manually edit the .bsd file so that the datatpyes match with the xml. There are 4 or 5 Duration/Double changes to replace I think ...
Then the tests would pass.
Would that be ok for you?

Otherwise I could probably search for a supertype (from Duration to Double) for DataType Definition attributes, but I am not sure if I can handle all cases. I don't think this is a good idea.

from open62541-nodeset-loader.

I've added here an issue and did a little debugging in the generator, here the issue open62541/open62541#3618

from open62541-nodeset-loader.

hm, I don't know any nodeset, that only provides the encoded bsd. I think the recommended way is to provide it via the tags on the datatype.
I think you have to grab this open issue ;)
open62541/open62541#2587

For me that would be ok to replace the Duration and Double.

from open62541-nodeset-loader.

Many thanks for opening the issue!

Replacing Double with Duration in the .bsd file unfortunately creates the same issues as with EUInformation datatype.
The namespaceZero flag in the generated referenceServer code is wrong and the DataType Id is 0 ...

{
    UA_TYPENAME("PlannedProductionTime") /* .memberName */
    UA_TYPES_DURATION, /* .memberTypeIndex */
    offsetof(UA_JobListElementType, plannedProductionTime) - offsetof(UA_JobListElementType, plannedStart) - sizeof(UA_DateTime), /* .padding */
    false, /* .namespaceZero */
    false, /* .isArray */
    false /* .isOptional */
},

I have tried following replacements in .bsd:
TypeName="opc:Duration"
TypeName="ua:Duration"

from open62541-nodeset-loader.

from open62541-nodeset-loader.

issue for nodesetcompiler is opened, I close this one.

from open62541-nodeset-loader.

okay, what if we change it in the xml from duration to double?

Even if we would, we would still have the EUInformation datatype issue and the test would still fail.

I will observe the issue tomorrow on open62541 repo, maybe we can fix it. If not then I will rewrite the XML.

from open62541-nodeset-loader.