Log In
Register
Topic RSS
17:04, EEST
February 21, 2014
Offline
Hello,
I am generating code from a nodeset containing custom structured dataTypes. When instantiating a (BaseDataVariableType) variable of such custom dataType, the instance in the addressSpace has children for every non-optional structure component. Is there a way to prevent this behaviour and just have the bare basevariable w/o children?
NB: SDK 5.3.0
The Instances are “loaded” from a nodeset as well. I double checked and the instances nodeset does not contain any child variables.
The generated code doesn’t contain the child variables either, so I assume that they are created by the server code when loading the nodeset.
Many thanks
PS: I think we discussed this topic some time ago, but I could not find the post…
14:47, EEST
April 3, 2012
Offline
Hi,
Is this more of a “curiosity question” or related to some problem (I would like more details)?
This is not directly related to Codegen, it is a feature of the instantiation system. There are some limits, but currently SDK will automatically create sub-nodes (if they do not already exist) that represent the Structure fields and it will synchronize values between them and the main node. Currently there is no intended way to disable this (as we have not had issues with it that I can remember).
The sub-nodes helps clients that do not understand custom structures, it is the ‘third approach’ explained in https://reference.opcfoundatio…..docs/A.4.3, and basically SDK takes care of the disadvantage part since it already syncs the data, though we cannot synchronize fields representing arrays further down to individual elements (and some CPU time goes of course as well).
I guess a workaround would be to edit generated code to not call super.afterCreate() in .afterCreate() (this prevents it going to BaseVariableTypeNode eventually, that does the sub-nodes), though the generated super is responsible for recursively passing down the call to components which wouldn’t happen (though maybe not an issue here). Though it would be somewhat painful to edit the files. We could maybe add a flag to disable this if there is some issue?
P.S.
Note that there are some limitations when this feature activates, currently the InstanceDeclarationHierarchy must already have the Variable/VariableType ValueRank as Scalar and the DataType must be of a Structure type (setting these afterwards doesn’t help, though afterCall could be called manually). In addition, we intentionally do skip all Optional fields, because it is possible to model a Structure type whose Optional field refers to the same Structure type itself (think like linked list nodes pointing to the next one). Or there could be a Chain A->(field)B->C->A that causes the same issue. For non-optional fields this cannot be the case as the Binary Encodings always require a default instance for “null fields” that are structures (so one would never be able to binary encode such type that would refer to itself somehow via non-optional fields).
10:12, EEST
February 21, 2014
Offline
Thank you very much for the explanation.
This is not a curiosity question 
. It is a little bit of an annoyance for my use case (as there are many of those variables), because a) I explicitly just need the “main” variable without child nodes, b) if the child nodes were there, the optional nodes should be present as well, as otherwise the user doesn’t get the complete view of the data, and c) the variable itself is readonly, but the children are writable.
My chosen workaround is to remove the children immediately after the server started. As the design of the addressSpace is still not finalized, code is generated frequently and modifications to generated classes would possibly be overwritten accidentally.
I was wondering whether I would overlook a configuration switch (codegen) or variable (instantation system) by which this auto-instantiation could be controlled.
Many thanks again,
Hans-Uwe
1 Guest(s)
