21:17, EET
November 16, 2020
PROSYS OPC UA (Java Client) 4.42-1266
openjdk version “13.0.1”
Siemens S7-1500 OPC UA V02.05.02
UaExpert 1.4.4 275
UaExpert seems to connect and display values without issues.
My application fails with a BufferUnderflowException with version 4.42-1266 SDK (also fails the same with version 4.2.0-995).
Built the SimpleClient and it also fails during the Connection.
11/16/2020 07:33:33.992 DEBUG token=SecurityToken(Id=1, secureChannelId=-1133918622, creationTime=Nov 16, 2020, 7:33:31 AM, lifetime=3600000)
11/16/2020 07:33:33.994 DEBUG tokens(1)=[SecurityToken(Id=1, secureChannelId=-1133918622, creationTime=Nov 16, 2020, 7:33:31 AM, lifetime=3600000)]
11/16/2020 07:33:33.994 DEBUG token=SecurityToken(Id=1, secureChannelId=-1133918622, creationTime=Nov 16, 2020, 7:33:31 AM, lifetime=3600000)
11/16/2020 07:33:33.996 ERROR Uncaught Exception in Thread Thread[OPC-UA-Stack-Blocking-Work-Executor-16,5,main]
java.nio.BufferUnderflowException
at java.base/java.nio.Buffer.nextGetIndex(Buffer.java:681)
at java.base/java.nio.HeapByteBuffer.getInt(HeapByteBuffer.java:434)
at com.prosysopc.ua.stack.utils.bytebuffer.ByteBufferReadable.getInt(SourceFile:121)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getUInt32(SourceFile:1639)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$28.C(SourceFile:158)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$28.c(SourceFile:154)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.get(SourceFile:498)
at com.prosysopc.ua.types.opcua.Serializers$StructureFieldSerializer.getEncodeable(SourceFile:5616)
at com.prosysopc.ua.StructureSerializer.getEncodeable(SourceFile:83)
at com.prosysopc.ua.stack.encoding.utils.AbstractSerializer.getEncodeable(SourceFile:155)
at com.prosysopc.ua.stack.encoding.utils.SerializerComposition.getEncodeable(SourceFile:109)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getEncodeable(SourceFile:839)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$16.r(SourceFile:269)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$16.c(SourceFile:265)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.get(SourceFile:498)
at com.prosysopc.ua.types.opcua.Serializers$StructureDefinitionSerializer.getEncodeable(SourceFile:1679)
at com.prosysopc.ua.StructureSerializer.getEncodeable(SourceFile:83)
at com.prosysopc.ua.typedictionary.StructureSpecification.getEncodeable(SourceFile:256)
at com.prosysopc.ua.stack.builtintypes.ExtensionObject.decode(SourceFile:495)
at com.prosysopc.ua.stack.builtintypes.ExtensionObject.decode(SourceFile:396)
at com.prosysopc.ua.stack.builtintypes.ExtensionObject.decode(SourceFile:355)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getExtensionObject(SourceFile:1040)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getScalarObject(SourceFile:1492)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getVariant(SourceFile:1713)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getDataValue(SourceFile:694)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$17.s(SourceFile:276)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$17.c(SourceFile:272)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.get(SourceFile:498)
at com.prosysopc.ua.types.opcua.Serializers$ReadResponseSerializer.getEncodeable(SourceFile:2120)
at com.prosysopc.ua.StructureSerializer.getEncodeable(SourceFile:83)
at com.prosysopc.ua.stack.encoding.utils.AbstractSerializer.getEncodeable(SourceFile:155)
at com.prosysopc.ua.stack.encoding.utils.SerializerComposition.getEncodeable(SourceFile:109)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getMessage(SourceFile:1306)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection$b$1.run(SourceFile:759)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:830)
java.nio.BufferUnderflowException
Any help or ideas would be greatly appreciated.
10:33, EET
April 3, 2012
Hi,
(Making an assumption that this is a previously known issue, looks a lot like it)
Basically the short answer is that please update the firmware of the S7-1500, that should fix the issue.
The longer answer is that the binary data S7-1500 sent for the OPC UA 1.04 new DataTypeDefinition Attribute is not exactly correct in the firmware you have. We have had this issue ourselves with our S7-1500 we have at our office and that has been fixed by a firmware update to it. Within your stacktrace there is “Serializers$StructureDefinitionSerializer”, thus I would assume it is the same thing (StructureDefinition is the value type for the DataType Attribute for Structure DataType nodes).
The current SDK version does read all types on connect (thus the error), basically in part due to the new Attribute, but that is an another longer explanation of why. UaExpert might do things differently, which is why it works (or is the same as below). But assuming I remember things correctly, if you navigate to a Structure DataType node with UaExpert, you should see the same buffer underflow within the UaExpert’s log view once you click on a (custom) Structure DataType node and you should not see the Attribute view updating. Note that depending on things in some cases the issue could manifest otherwise (since the binary stream consists of length-prefixed or known beforehand rules).
Also writing just in case, there has been another sort of similar case where the binary data (opc.tcp is basically raw binary with encoding rules in the lowest levels) was incorrect. Though in that case, UaExpert did work, but that was because it basically ignored some length fields in some special cases (for the standard types for the base information model and service calls). Basically you can either treat the binary tcp stream as a stream or chunk it to messages per read lengths, the former can ignore message lengths in certain cases, but our SDK works by separating the messages as individual messages/chunks of binary and then decode them.
16:50, EET
November 16, 2020
17:34, EET
April 3, 2012
It works with SDK 3.x, since that doesn’t try to read the new Attribute, thus the server wont send invalid data; only SDK 4.x does read the DataTypeDefinition. In practice our SDK version numbering has been x.y.z-b, where x equals OPC UA version 1.0x, thus SDK 3 is for UA 1.03, SDK 4 is for UA 1.04, and the new Attribute was defined in OPC UA 1.04. Only 1.04 understanding clients can use the new Attribute (1.04 also was the first time OPC UA introduced new Attributes).
Most Users Ever Online: 1919
Currently Online:
22 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: 735
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1523
Posts: 6449
Newest Members:
rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger, howardkennerley, Thomassnism, biancacraft16Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1