Unified Automation Forum

Hi,

we are running into problems accessing a Siemens-PLC driven OPC-UA Server using Halocon/HalconCPP, which in turn seems to be built on unified automation.

We currently have two c++/halcon/opcua applications accesssing the opcua server from two different macines (later there will be 4-8). Each application browses the complete node tree on connect, polls 2-4 variables in ~50-100ms interval and occsionaly reads or writes (1-5 accesses /minute on average) to one of ~20 variables.
On each machine we are also running DataFeed opc client as a development aid to manually set/view opc-variables.

With this setup we have the problem that browse calls to e.g. query_io_device or open_io_channel fail with an BadNodeIdUnknown error. What was seemingly undeterministic has been tracked down to happen frequently during disconnects/reconnects of other clients (our only 2nd application or the Datafeed tool). This behaviour can be triggered in about 90-95% of the cases by intentionally disconnecting/connecting one app while the other is browsing. All variables are accessed via short namespace and ids.

• Since we are not dynamically changing, moving, deleting or creating the failing nodes i have no idea why this annoyoing errors would happen?

• Is this a problem with the setup of our server? Are there any settings to consider/change?

• Can this be a problem with the changing nodes in the ServerSessions subtree? But then, why would other nodes be unavailable?

Thanks!

Hi,

this is most probably an issue in the server implementation. Some servers do not hold the address space themselves, but obtain that from the undelying source on the fly, they are just wrappers of some underlying device, sometimes connected via slow propritarian connection. Most probably this underlying system is not started up completely or is still in the process of collectiong data from the underlying source, hence returning "NodeIDUnknown" (or "not yet known") in the meanwhile. It is an allowed behavior from an OPC UA perspective that node "becomes known" during runtime.

You could question yourself if browsing the whole device (eventhough you only want to read 3 nodes) every time after connect is a smart idea, typically you browse during engineering/configuration (once) only? Another approach would be "try again" little later, but when browsing the whole device again, you may consider your approach as stress test for the server, hence it might get worse.

Please contact the manufacturer of the UA server for in depth analyses and check with the manufacturer of the client side application if "stress" could be reduced.