14:24, EEST
September 3, 2024
Hello,
I am wondering how to correctly remove imported nodesets (server.getAddressSpace().loadModel()) from my server, as the tutorial does not mention this. I would like to have all residues removed because I want to load another nodesets of the same namespaces without conflicts afterwards
There is the server.getAddressSpace().removeNodeManager(nsIndex) method. Is this the correct approach? Or do I have to combine this with other methods or is there something completely different?
Thanks
Christian
15:40, EEST
April 3, 2012
Hi,
Easiest would be to just shut down the server and make another UaServer without the namespaces and start it.
This topic can get really complicated. IF your model is a “leaf namespace” in the dependency hierarchy it is just as simple of deleting all nodes and then removing the manager. However, if not, you must delete all namespaces that depend on this namespace directly or indirectly first. However there is currently no easy way in the SDK to know if a namespace is a “leaf” or not after models have been loaded, but your application layer might “magically know this”.
Since we do have a real node-graph of UaNodes, in the current implementation you must delete the nodes manually so that any references (from nodes that are not deleted) to those nodes are removed. Basically you must call NodeManagerUaNode.deleteNode(node, true, false) for each node in the namespace. NodeManagerUaNode.getNodes() casted to NodeMapUaNode gives NodeMapUaNode.getMap() that gives you Map of the nodes of that manager. Once all are deleted you can use com.prosysopc.ua.server.NodeManagerTable.removeNodeManager(int, boolean), the second parameter controls is the namespace removed from the NamespaceTable (and the server NamespaceArray node updated), note that this was added in somewhat recent SDK and the com.prosysopc.ua.server.NodeManagerTable.removeNodeManager(int) was ambiguous before that (now it an overload that uses ‘true’ for the second parameter). Additionally some clients have had issues with ‘null’ entries in the NamespaceArray, so I recommend setting a placeholder value to that index afterwards.
Note that regradless of that the DataType-related UaDataTypeSpecifications do remain in the EncoderContext and it is not currently possible to remove them. Additionally it should be noted that in OPC UA any existing DataType cannot be altered. For example, you cannot add a field to a Structure. You must make a completely new Structure type with a different NodeId. Unless you control all clients and servers and haven’t published the model. Additionally every change to any VariableType or ObjectType must be backwards-compatible. If not possible, then you must use a different NamespaceUri (with e.g. ‘/v2’).
Most Users Ever Online: 1919
Currently Online:
15 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 86
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 732
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1508
Posts: 6396
Newest Members:
elainesever, powhephenry, mamiecaldwell5, Lamasom, scsneed, berrybulcock, icerdraizomma, athenasummy5, vtaletbhcx, HaroldaDobModerators: Jouni Aro: 1019, Pyry: 1, Petri: 0, Bjarne Boström: 1016, Jimmy Ni: 26, Matti Siponen: 340, Lusetti: 0
Administrators: admin: 1