Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Slow Browse
December 15, 2016
23:56, EET
Avatar
dhooper
Connecticut
Member
Members
Forum Posts: 6
Member Since:
December 1, 2016
sp_UserOfflineSmall Offline

Hello,

We are developing a client, and the browse is slow. Specifically, we come across a node with a fairly large number of leaves, and it takes a very long time to get those nodes from the address space. Its really this block of code that seems to be taking a long time with this:

// add those references to the nodes to be visited
for(ReferenceDescription reference : references) {
UaNode referenceNode = addressSpace.getNode(reference.getNodeId());
nodesToVisit.add(referenceNode.getNodeId());
}

Is getting a node in this manner inefficient? Is there a better way to ensure we browse the entire address space, but more quickly.
We are browsing a Kepware Server if that is relevant at all

December 16, 2016
9:53, EET
Avatar
Heikki Tahvanainen
Member
Members
Forum Posts: 402
Member Since:
April 17, 2013
sp_UserOfflineSmall Offline

Hello,

The AddressSpace.getNode method initializes all kinds of information about the UaNode in question: it reads common attributes of the node and in addition to that, attributes that are specific to the NodeClass in question. The method also browses the properties of the node and initializes the Properties into the node object. The reasoning behind this implementation is that in common cases this should caching mechanism should be efficient.

As a start, please see this forum discussion about similar subject: http://forum.prosysopc.com/for…..tesnodeid/

December 16, 2016
15:26, EET
Avatar
dhooper
Connecticut
Member
Members
Forum Posts: 6
Member Since:
December 1, 2016
sp_UserOfflineSmall Offline

The only problem with that is, these are ReferenceDescriptons. So reference.getNodeId() returns an ExpandedNodeId, rather than a NodeId. Is there another method to browse, other than using reference descriptions?

December 16, 2016
16:09, EET
Avatar
Heikki Tahvanainen
Member
Members
Forum Posts: 402
Member Since:
April 17, 2013
sp_UserOfflineSmall Offline

ExpandedNodeIds are returned in the browse because in theory the references could point to other OPC UA servers.

You can convert between NodeId and ExpandedNodeId best with UaClient.getNamespaceTable().toNodeId(expandedNodeId) and similarly with toExpandedNodeId methods.

December 16, 2016
16:27, EET
Avatar
dhooper
Connecticut
Member
Members
Forum Posts: 6
Member Since:
December 1, 2016
sp_UserOfflineSmall Offline

Oh I see, that definitely cleared a few things up and helps that part of the code run more quickly. I am still getting a slow browse however, and it is due to still calling addressSpace.getNode(nodeId) in order to get certain items from the node itself. Are there better methods to get the:

– Supported attributes of the node
– Browse name
– Canonical name

Please let me know if you have some methods for extracting this information from the address space, rather than the node itself.

December 16, 2016
16:56, EET
Avatar
Heikki Tahvanainen
Member
Members
Forum Posts: 402
Member Since:
April 17, 2013
sp_UserOfflineSmall Offline

Hi,

All these things can be read from the node with the basic read calls.
– Attributes are NodeClass specific, so you can find out what attributes are supported by reading the NodeClass.
– Every node in the address space has a BrowseName attribute.
– I guess you mean DisplayName attribute with ‘Canonical name’. This attribute is also available in all NodeClasses.

Looking at the Javadoc documentation of UaClient.readXxx methods will probably get you started nicely. You can read the mentioned attributes for example with

client.readAttributes(NodeId.parseNodeId("ns=2;s=MyLevel"), Attributes.NodeClass, Attributes.BrowseName, Attributes.DisplayName);

However, I wouldn’t call this ‘better’ than using the addressSpace.getNode. This is more optimized but on the other hand you must know more about the OPC UA specification yourself. But if you have a situation where you need to optimize the browse and read calls, then using these simpler versions may help.

December 16, 2016
17:24, EET
Avatar
dhooper
Connecticut
Member
Members
Forum Posts: 6
Member Since:
December 1, 2016
sp_UserOfflineSmall Offline

Thank you very much for the help. Do you have any reason this would be the case for a Kepware server specifically? When we browse a UA Gateway server with our current implementation, the performance is fine.

December 19, 2016
16:55, EET
Avatar
Heikki Tahvanainen
Member
Members
Forum Posts: 402
Member Since:
April 17, 2013
sp_UserOfflineSmall Offline

According to my understanding, we have no reason to believe that Kepware servers would somehow offer poor performance. That being said, of course any single application could be having some performance issues.

Are you accessing the same server via UaGateway? Or are you browsing some other server via the UaGateway? If you are browsing for the exactly same data and from UaGateway it’s considerably faster, then this does sound strange.

Have you tried making the same kind of browsing with different general purpose OPC UA Clients? Is the browsing slow also with other client applications?

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 1919

Currently Online:
24 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Heikki Tahvanainen: 402

hbrackel: 144

rocket science: 88

pramanj: 86

Francesco Zambon: 83

Ibrahim: 78

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

Member Stats:

Guest Posters: 0

Members: 737

Moderators: 7

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1524

Posts: 6450

Newest Members:

fannielima, kristiewinkle8, rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger, howardkennerley

Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0

Administrators: admin: 1