Problems reading data from NodeJS OPC UA server

[Coobik]

Hi all,

I've tried to use Eclipse Milo to create a simple OPC UA java client. Found a public demo server at opc.tcp://opcuademo.sterfive.com:26543 (Sterfive is a company behind NodeJS implementation https://node-opcua.github.io so I think this server runs on NodeJS) This server has several nodes with the constantly changed values.

I've set up Milo using Gradle: https://mvnrepository.com/artifact/org.eclipse.milo/sdk-client compile group: 'org.eclipse.milo', name: 'sdk-client', version: '0.1.6'

then connected to that server and subscribed to 2 nodes: ns=1;s=FanSpeed and ns=1;s=Pressure

On most responses from that server, I get an error in the log. Errors may be different, here are the common ones:

• UaSerializationException: max array length exceeded (length=(some large number), max=65535);
• NegativeArraySizeException - it tried to create an array of some negative size;
• UaSerializationException: unknown builtin type: 49 (I've seen different values greater than 25);

I've tried some other public OPC UA servers and they appear to be OK: https://github.com/node-opcua/node-opcua/wiki/publicly-available-OPCUA-servers

Prosys OPC UA Client app is able to handle Sterfive server without issues. https://downloads.prosysopc.com/opc-ua-client-downloads.php

I am trying to understand, are there different versions of message format and is there an ability to switch them? Can anybody advise? Thanks!

---

Here are my observations from the Milo source code:

• BinaryDecoder has a default constructor that sets default hardcoded array and string length. It is called from several places like OpcUaDataTypeEncoding so that custom ChannelConfig set in OpcUaClientConfig is ignored.
• UaTcpStackClient.getEndpoints(String endpointUrl) builds UaTcpStackClientConfig without ChannelConfig so default values are used and it seems they are also applied later in different places.
• During message decoding I've seen multiple instances of BinaryDecoder - one had the custom ChannelConfig, the others had default values.
• BinaryDecoder.decodeBuiltinType(int typeId) handles 25 types. I've checked the source code of OPC Foundation at https://github.com/OPCFoundation/UA-Java and it does the same. Error "unknown builtin type: 49" may mean that message format is just different. But how does Prosys OPC UA Client app handle it?

[kevinherron]

I'll take a look and see if I can reproduce the errors. It's possible that the Node server is sending an array value larger than the configured default, which would account for the first error you saw, and possibly many stranger errors beyond that point.

[kevinherron]

This server you've provided is not responding with either Milo or UaExpert

[Coobik]

Hi, just checked the server opc.tcp://opcuademo.sterfive.com:26543 and it responds. after I created subscription to nodes ns=1;s=FanSpeed and ns=1;s=Pressure i am getting: unknown builtin type: 0, unknown builtin type: 45 on the second run, the errors are: max array length exceeded (length=187518659, max=65535)

[kevinherron]

Can you get a Wireshark capture? I'm going to check with IT and see if something is blocked on our network now...

[Coobik]

Prosys client is able to communicate with this server:

[Coobik]

here is the trace: $ traceroute opcuademo.sterfive.com traceroute to opcuademo.sterfive.com (145.239.218.238), 64 hops max, 52 byte packets 1 172.23.71.1 (172.23.71.1) 3.733 ms 4.707 ms 4.302 ms 2 156.67.50.1 (156.67.50.1) 2.529 ms 2.681 ms 1.973 ms 3 80.91.186.21 (80.91.186.21) 15.889 ms 16.189 ms 13.861 ms 4 5 be100-2.var-5-a9.pl.eu (91.121.215.208) 28.830 ms be100-1102.fra-1-a9.de.eu (213.251.128.113) 47.592 ms 47.222 ms 6 be105.gra-g1-nc5.fr.eu (213.186.32.212) 56.354 ms 57.098 ms be100-1167.ams-1-a9.nl.eu (91.121.215.192) 54.647 ms 7 8 9 10 * 11 ocl11.e-c.com (217.182.192.56) 56.799 ms 60.996 ms 54.869 ms 12 ip238.ip-145-239-218.eu (145.239.218.238) 58.366 ms 57.021 ms 56.342 ms

[kevinherron]

Yes, they started blocking outbound traffic on unknown ports recently. I'll be able to connect and test shortly.

[kevinherron]

Thank you, I see what's going wrong. The encoder/decoder for DataValue does not handle when the picosends fields are present. I'm not sure how this has gone undiscovered for so long.

[kevinherron]

This should be fixed on master now. Thanks again.

[erossignon]

@kevinherron , I am glad our public server did help finding this isssue 😃

[kevinherron]

@erossignon Yep, thanks! You're the only server I've encountered so far using picoseconds... even at the interop events nobody has used them.

[erossignon]

For the record, it seems that Ignition by Inductive Automation Version: Ignition-7.9.7 is affected by this bug.

[kevinherron]

Yep, covered here: https://forum.inductiveautomation.com/t/node-opc-ua-does-not-work/17953/13

Milo 0.2.1 has been integrated for the 7.9.8 release.

[kevinherron]

@erossignon while it's nice that it exposed a bug, have you considered that your stack should not be including picoseconds by default? You certainly don't actually have that kind of resolution and you're increasing the size of every data transmission by doing so.

[erossignon]

Picoseconds might be usuful to distinguish values that change faster than the standard clock resolution ( usually 1ms, depending on your system &/or language).

[kevinherron]

@erossignon Yes, that's their purpose, but the resolution of the UTC time in OPC UA is already in nanoseconds. None of the platforms NodeJS will run on (or Java, or the vast majority of things OPC UA will actually run on in the real world) have picosecond resolution, which makes including it by default somewhat nonsensical. It implies a precision and resolution of the timestamp that is simply not true.

[erossignon]

@kevinherron , you have a point here ! picoseconds is not at all practical and representative at all. As you know we do need a system clock clock which is monotonically increasing to apply timestamps to dataValue.
OPCUA specifies that Date are encoded as "double" value which represent nano seconds. Unfortunalty , the standard javascript DateTime object has a resolution of 1 milliseconds which is 10000 time less accurate than the 100 nano resolution of OPCUA Date. node-opcua "unconventionally" uses picosecond to disambiguate and distinguished between two ticks that returns the same milisecond value. This being said picoseonds encoding are part of the spec since 1.01 ... I also agreed that this negatively impact the size of binary encoded datavalue by 2x16bits. I'll try to improve on my end and apply the désambiguïsation number to the nano part of the date instead. ( i have opened https://github.com/node-opcua/node-opcua/issues/483 for this) Thanks for the tip

[kevinherron]

@erossignon Sounds good 👍

FYI, dates are encoded as 64-bit integers. You may be thinking of the Duration simple/alias type, which is encoded as a Double.