OPC UA Server Node Attributes

[AutomateSHANE]

I am using OPC UA Server app version 1.12.5 on an X3. My UA client can reach the server but then immediately encounters a ton of errors about nodes missing type definitions. It very quickly hits a stack limit and stops. I recall having the same, or at least very similar, issue with this client trying to connect to an XM22 server on version 14. Once I upgraded to v15, the issue was resolved. I assume this to be an issue with how the server is implemented on the CORE. Is there a solution or an updated UA Server app coming soon?

I have included a log file of the errors.

[CodeShepherd]

A far as i know there is quite no difference between the OPC UA servers in IndraWorks version 14 and 15.

The actual ctrlX CORE OPC UA server is 1.18 that can be found like other early adopter version in the corresponding area of the collaboration room. See e.g. the FAQ for ctrlX WORKS how to get access.

[AutomateSHANE]

The latest version of the OPC UA Server app that is available to the me in the collaboration room is 1.12.5. As I have seen with my N.A. contact, 1.18 is visible to you as a Bosch employee, but not to everyone else (or at least just not to me). I would be happy to try 1.18 because as I said, switching from IW 14 to 15 had solved my previous problems with this exact same UA client. The differences were evidently stark enough and I would hope that the latest ctrlX UA server would match closely the IW 15 server. 

[CodeShepherd]

All early adopter version can also be visible for not Bosch employees. As mentioned above you need to request access once. See post above.

[AutomateSHANE]

I have received the appropriate access, downloaded and installed V1.18 of the OPC UA Server app and the problem remains the same. The client cannot import nodes because of missing or incorrect type definitions. There is still something wrong with the ctrlX UA server.

[CodeShepherd]

Could you please send me a private message with your contact data, so we can have a direct look to this topic?

[CodeShepherd]

After a short session we could see the error. We tried to reproduce with your client but in our cases after some time the connection to a IW14 and also IW15 OPC UA server is working fine.

But your topic should be fixed in the next release version 1.20 coming up end of March.

[AutomateSHANE]

It currently does not work with my ctrlX UA Server, which means I cannot continue with development. The machine is shipping mid-March, which means it needs to be functional by mid-February. I need a solution in the next couple of weeks, not by the end of March.

[CodeShepherd]

We are actually checking your topic to get an earlier solution as a patch for 1.18. We will inform you end of the week.

[AutomateSHANE]

Hi,

Which week? I had assumed Week 5.

[CodeShepherd · Accepted solution]

We needed some more time to find that the problem for crashing is on client side not on servers. The missing description error did not lead to it but will be fixed in our next release of the server.

The Reason for the error “BadEncodingLimitsExceeded” (“FT-Optix.png”) inside the FT Optix OPC UA client is the variable “ns=2;s=datalayer/retain/chunks”. The client tries to read the value and fails, because of the size of the returned data.

We also teted other clients like e.g. the Prosys OPC UA client can read the value and here you see it’s an array with 122880 elements:
read value in Prosys OPC UA client

The UA-Expert can read, but cannot show the value, because the default setting for the array size is 65536:

read value in UA_Expert OPC UA client

After increasing the max array size to 123000 the UA-Expert is able to show the data too:
read value in UA_Expert OPC UA client 2

And this fits to the OPC UA specification:

OPC UA specification BadEncodingLimitsExceeded

The client must handle such “BadEncodingLimitsExceeded” errors. Please check if you can increase the max array size inside the settings of the FT-Optix UA Client.

[AutomateSHANE]

FWIW, this is issue was mostly resolved, but I am still not thrilled with the outcome. The UA client software has had numerous improvements so that I am able to import PLC variables from the ctrlX UA server, but only after nearly 5 minutes. It seems that most of the time is spent by the client browsing the server and determining how to deal with invalid items. They even go so far now as to put a warning stating that the server does not comply with OPC UA specification.

I have attached the logs so that you can see what is happening. I'm still not an expert in this area so it is not clear to me where the problem lies. Other clients can read the ctrlX UA server and show the variables in a fraction of the time though, so this is suspect. 

[CodeShepherd]

Like I tried to point out in my post above, we did tests with customers OPC UA client and also improved our server until we only could find the last error “BadEncodingLimitsExceeded”. 

Can you please tell us which OPC UA server app version was used in the current tests?

[AutomateSHANE]

Current tests carried out with version 1.20.4

[NoRisk4Project]

Hello,

the warning is shown, because some attributes are not set. But this has nothing to do with the 4,5 to 5 minutes delay you mentioned. Inside the logfile we see, that your client reads every datatype and variable, that exists on the control. And this just takes some time.

It might be helpful, if you could send us a Wireshark trace, that covers the startup/connection sequence of the client, but I guess we will see the same as inside the logfiles.

You already mentioned that other clients are much faster when connecting to the ctrlX. I guess they don't read all datatypes and variable in advance. Is there a way to disable this behavior on FT Optix OPC UA client?

Did you tried to connect with the FT Optix OPC UA client to a different OPC UA server?

[AutomateSHANE]

@NoRisk4Project I have no control over the behaviour of the Optix OPC UA client. I am at the mercy of the developers. Recently I did receive feedback from a liason in regards to that warning message. They say that your server is actually not following the specs, which is very common with Bosch and Siemens "which are using references in the wrong way, trying to parse the whole tree and fixing such references."

If I had a different OPC UA server available to test with, I would. Unfortunately, I do not.

Attached is the requested Wireshark capture.

[NoRisk4Project]

Hello,

the Wireshark is unfortunately encrypted, therefore I we can't see anything inside. Would it be possible to create a Wireshark trace without encryption?

[AutomateSHANE]

Sure, here is the trace with encryption turned off.