Log In
Register
Forum
Topic RSS
11:42, EET
November 11, 2016
Offline
Hello,
I’ve written a service which browses the available nodes from server and stores the the variables for other services in a database. After restarting the service it reads known and configured variables from database and subscribes them. To avoid subscribing already unknown nodes (from opc ua server view) i would parse the nodes if they are available.
When i call addressSpace.findNode(NODE ID) then i always get null. If i delay this action and an other thread is browsing the opc server, than findNodes works as expected.
My question is, is findNode not a trustworthy method, or is there a bug?
For detailed process:
NOT WORKING:
connection is established
client.getAddressSpace().findNode(NODE ID); is always null
WORKING:
connection is established
BROWSING:
addressSpace.setReferenceTypeId(
Identifiers.HierarchicalReferences);
rootNodes = addressSpace.browse(Identifiers.RootFolder);
… and so on
AFTER THAT:
client.getAddressSpace().findNode(NODE ID); works as expected
I am using the latest library and given dependencies
Greetings
Karsten
18:03, EET
April 3, 2012
Offline
Assuming by addressSpace you mean the com.prosysopc.ua.client.AddressSpace class.
It works as intended, but the documentation could maybe be made better.
The javadocs as of 2.2.4 state for the id parameter: “id of the (@link UaNode) that is searched for”
It is searches from the AddressSpace’s cache, but does not make any server communication, so it might be a bit misleading. Use AddressSpace.getNode method instead. The SDK uses that method internally from another package in a class called DataTypeConverter, so that is one reason why reason it is public (also type nodes are kept indefinitely in the cache).
– Bjarne
8:22, EET
November 11, 2016
Offline
Hello Bjarne,
thank you for the quick answer.
Is there no other possibility than checking for existing node encapsulated an try catch?
Karsten
10:14, EET
April 3, 2012
Offline
You could also call UaClient.read, but it too has try-catch
Based on your previous post, “To avoid subscribing already unknown nodes (from opc ua server view) i would parse the nodes if they are available. “, I would assume the server has dynamic address space, i.e. nodes are added and removed while the server is running (or the server is restarted and the address space is not the same as previously). If it is, then there is no way to make sure the node exists other than making a call to the server and those calls are modeled in the SDK as ‘throw exception when calling fails’.
– Bjarne
13:37, EET
November 11, 2016
Offline
Ok, my solution now is to move the subscription handling in my browsing thread. If a node comes ready it will be subscribed if necessary. When using the getNode Method the AddressSpaceException is thrown. In this exception is no method to get a clearly reason why it is thrown. Only the message for logging contains status information. Would be great when this information will be available in the exception in future. Currently catching this exception is not an option for me, because other AdressSpaceExeptions may occur during this process and can not be identified. Perhaps subscribing the nodes during browsing may be generally the better way and i used the wrong workflow before.
Karsten
Most Users Ever Online: 518
Currently Online:
9 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 77
Ibrahim: 76
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 682
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6261
Newest Members:
digitechroshni, LouieWreve, Kickbiche, karrimacvitie5, graciela2073, sagarchau, elviralangwell4, Donnavek, Eddiefauth, DonaldPoomaModerators: Jouni Aro: 1010, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 983, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 321, Lusetti: 0, Ari-Pekka Soikkeli: 5
Administrators: admin: 1
