Goodmorning,
In the Wrapper.log, each 3-4 minutes I have this error message:
**W [c.i.x.d.a.ScheduledRequest ] [10:56:49]: Uncaught Throwable invoking class com.inductiveautomation.xopc.drivers.siemens.requests.ReadRequest#receiveMessage: java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 166 out of bounds for byte[142] **
INFO | jvm 1 | 2023/02/13 11:57:10 |
what is the cause???
Error in function system.tag.readBlocking???
Thank You
Bye
That usually means you have an OPC tag pointing into a Siemens DB where the DB is actually shorter than where the tag is looking for your data. It tends to make bad quality in Ignition for the whole DB.
Ok,
Can this error genetated with function system.tag.readBlocking or system.tag.writeBlocking ???
Thank You
Bye
Not by readBlocking, no. That gets the most recent value delivered by the OPC subsystem. It isn't possible that writeBlocking could produce it, either, since the error says it was a "ReadRequest".
It could be produced by system.opc.readValue(), perhaps.
In the project, there isn't function system.opc.readValue()
Here is the documentation on system.opc.readValue:
https://docs.inductiveautomation.com/display/DOC81/system.opc.readValue
In my project, I don't use function system.opc.readValue
My apologies, it seems that I misunderstood.
Then the only source for such a message would be an OPC tag's subscription.
I have a similar problem, I have the following DB:
I’m trying to read the string located at address 200 which is a string of a length 42.
No matter what I try I don’t get the correct value out of the PLC into Ignition.
The only way I get something that is kind of correct is by doing:
You see the string: “Sphere REC ·Wk 37 – MaEoaEA--” The part of this string I need is: “Sphere REC” and for the string located at 244 I need the “Wk 37 - Ma” part of this string.
When I use [RawMaterials]DB101,STRING200.42 the tag gives a bad value.
I get the “arraycopy: last source index 151 out of bounds for byte[44]” error in the gateway.
Does somebody have the answer to my problem?
When you're reading a Siemens string keep in mind two bytes contain meta data.
So in my system we have a String[200] at offset 450, so my tag is configured to
ns=1;s=[{PLC Device Name}]DB100,STRING450.198
Can you get a Wireshark capture or something?
It seems that maybe the one or both of the length prefix bytes are indicating the wrong length.
Of course, I added to this post.
The Ignition server IP is: 192.168.150.253
The PLC IP is: 192.168.200.10
The tag completed the read on: 2023-09-14 02:24:59PM
wiresharkForum.pcapng (4.7 MB)
Also, I don't know if this can cause the problem but the load factor of the PLC is very high.
There is no traffic on this IP address in the capture.
Was the capture taken on the Gateway or on your own machine?
Sorry, I used the wrong network port.
I used the server.
Find the new attached.
wiresharkForum1.pcapng (1.4 MB)
The string is not being stored in correct S7 format in the PLC.
This is the resulting bytes for that read:
0000 20 95 53 70 68 65 72 65 20 52 45 43 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00
The first two bytes indicate max length and actual length.
In this case:
You should have two tags with item paths:
[RawMaterials]DB101,STRING200.42
[RawMaterials]DB101,STRING244.10
The string of length 42 occupies 44 bytes (the first byte is the maximum length, the second one actual length, or viceversa, I don't remember). If you declare these tags you should have no problem, unless you do something wrong on the PLC when writing the strings (you should use Siemens string functions, or be careful to write the first two bytes accordingly).
If you want to try if the problem is in the declaration of this two tags, just create a new device, RawMaterials2, and declare the two tags with item paths [RawMaterials2]... and verify if you still have the same error
@Kevin.Herron this means I never will get a good result without changing the PLC?
@taglias I tried these addresses and splitting but nothing is working.
Yes, the strings are not being stored in the correct format, as @taglias mentioned as well.