Unified Automation Forum

hi!

we have implemented an open62541 based ua server and are currently evaluating uagateway for some of our customers
who want to connect to our ua server with opc classic clients.

after proper setup of uagateway we can sucessfully connect it to our ua server. for a simple first test we then sucessfully
connect uaexpert to uagateway. we can see our ua server as a folder under root\objects but without any content.

contrary when we connect uaexpert directly to our ua server, we can access the whole model that our ua server exposes.

comparing the logging of our ua server for the above connection scenarios we cannot find any difference.

is there any additional configuration that needs to be done on uagateway?

best regards
horst kronstorfer

Hello,

we do not test with the open62541 because it is not the reference, we test against OPC Foundation reference servers. We encourage you to use UA Servers that are certified for compliance by the OPC Foundation. The UaGateway "forwards" the browse requests and uses browse filters which might be slightly different that in UaExpert, but still allowed by the OPC Specification. Please note that in "classic" OPC there are no operational limits, but if the wrappered underlying UA Server is "micro" or "nano" profile only, the classic OPC Client may put quite some load on the weak underlying server, e.g. is browsing with continuations points supported in open62541?

Please use the latest open62541 server, we gave that one a quick test and we can see the address space through the UaGateway, it works perfectly. Hence it seems like the issues are solved in the latest open62541 release. Are you using an old open62541?

hi!

we are using the current head from master@git://github.com/open62541/open62541.git which is 0.3-rc2-516-g56bb742e.

after changing the type of the root node of our model from 'numeric' (in which case the open62541 stack generates the id) to 'string'
the root node is now visible when connected via uagateway, however, for the nodes under the root node, which are still of type 'numeric'
a browse attempt generates error 'BadNodeIdUnknown'. we are using namespace index 1 for our model.

Hello,

the UaGateway can operate "numeric" and "string" NodeIds (and GUID and others). We do that all the time, this can not be the issue here.

Your hint on the namespaceindex sounds more promising. A compliant server can not have Nodes in namespace "0" because that is reserved by the OPC Fundation. Of course the UaGateway does not accept any nodes that are located in namespace "0".

Make sure your Nodes are located in namespace "1" or above, and that those namespaces have proper URI, as needed for compliant behavior and for proper mapping into the UaGateway.

hi!

to simplify the test i have compiled the code from https://open62541.org/doc/current/tutor ... iable.html
(leaving out writeVariable() and writeWrongVariable()) that adds just a single int32 variable to the model.

(a) in the original form with node type 'string' i can see the variable.
(b) when i change the node type to 'numeric' and explicity set a value (fe 4711) i can see the variable node.
(c) when i let the stack choose the node setting it sets type 'numeric' with value 58192 and the variable node is _not_ shown.

btw the above sample as well as our implementation operate in namespace 1.

Hello,

thank you for further analyzing. It seems to me very clear that the function (c) in the open62541 is obvilosly buggy. The assumption still is that the namespace index is "0", which is wrong, because it is not allowed. UaExpert can display namespace index in Attribute Window.

The UaGateway works correctly and as expected.

Please direct question for bug fixing to the authors of open62541, this forum is targeted to questions regarding Unified Automation products only.