[
https://issues.apache.org/jira/browse/PLC4X-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466749#comment-17466749
]
Stefano Bossi commented on PLC4X-241:
-------------------------------------
Hi,
unfortunately the bug is still there in the 0.9.1 version, I have just tested
to read an array of 400 INT and I have this exception:
{code:java}
2021-12-30T09:47:14,891 INFO TcpChannelFactory - Configuring Bootstrap with
Configuration{local-rack=1, local-slot=1, remote-rack=0, remot-slot=0,
pduSize=1024, maxAmqCaller=8, maxAmqCallee=8, controllerType='null'}
2021-12-30T09:47:14,906 INFO S7ProtocolLogic - S7 Driver running in ACTIVE
mode.
2021-12-30T09:47:15,016 WARN S7ProtocolLogic - Got an unknown error response
from the PLC. Error Class: 133, Error Code 0. We probably need to implement
explicit handling for this, so please file a bug-report on
https://issues.apache.org/jira/projects/PLC4X and ideally attach a WireShark
dump containing a capture of the communication.
2021-12-30T09:47:15,016 WARN CachedPlcConnection - Request finished with
exception. Reporting Connection as Broken
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
~[?:?]
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:645)
~[?:?]
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
~[?:?]
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
~[?:?]
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.lambda$readInternal$18(S7ProtocolLogic.java:271)
~[plc4j-driver-s7-0.9.1.jar:0.9.1]
at
org.apache.plc4x.java.spi.Plc4xNettyWrapper.decode(Plc4xNettyWrapper.java:175)
~[plc4j-spi-0.9.1.jar:0.9.1]
at
io.netty.handler.codec.MessageToMessageCodec$2.decode(MessageToMessageCodec.java:81)
~[netty-codec-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
~[netty-codec-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
~[netty-codec-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
~[netty-codec-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
~[netty-codec-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)
~[netty-codec-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
~[netty-transport-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
~[netty-common-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
~[netty-common-4.1.67.Final.jar:4.1.67.Final]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
~[netty-common-4.1.67.Final.jar:4.1.67.Final]
at java.lang.Thread.run(Thread.java:829) ~[?:?]
Caused by: java.lang.NullPointerException
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.decodeReadResponse(S7ProtocolLogic.java:765)
~[plc4j-driver-s7-0.9.1.jar:0.9.1]
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.lambda$toPlcReadResponse$13(S7ProtocolLogic.java:233)
~[plc4j-driver-s7-0.9.1.jar:0.9.1]
at
java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642)
~[?:?]
... 29 more
2021-12-30T09:47:15,019 ERROR HelloPlc4x - Interrupted Exception fired
java.util.concurrent.ExecutionException:
org.apache.plc4x.java.api.exceptions.PlcRuntimeException: Unable to finish
Request!
at
java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
~[?:?]
at
java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022) ~[?:?]
at it.fox.datapicker.HelloPlc4x.main(HelloPlc4x.java:59) [main/:?]
Caused by: org.apache.plc4x.java.api.exceptions.PlcRuntimeException: Unable to
finish Request!
at
org.apache.plc4x.java.utils.connectionpool2.CachedPlcConnection.closeConnectionExceptionally(CachedPlcConnection.java:146)
~[plc4j-connection-cache-0.9.1.jar:0.9.1]
at
org.apache.plc4x.java.utils.connectionpool2.CachedPlcConnection.access$100(CachedPlcConnection.java:47)
~[plc4j-connection-cache-0.9.1.jar:0.9.1]
at
org.apache.plc4x.java.utils.connectionpool2.CachedPlcConnection$2.apply(CachedPlcConnection.java:127)
~[plc4j-connection-cache-0.9.1.jar:0.9.1]
at
org.apache.plc4x.java.utils.connectionpool2.CachedPlcConnection$2.apply(CachedPlcConnection.java:121)
~[plc4j-connection-cache-0.9.1.jar:0.9.1]
at
java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
~[?:?]
at
java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
~[?:?]
at
java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
~[?:?]
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
~[?:?]
at
java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
~[?:?]
at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) ~[?:?]
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
~[?:?]
at
java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
~[?:?]{code}
Reading the same array but just 4 INT (as an example) no problem.
Thanks,
S.
> Reading long Int Array
> ----------------------
>
> Key: PLC4X-241
> URL: https://issues.apache.org/jira/browse/PLC4X-241
> Project: Apache PLC4X
> Issue Type: Bug
> Components: Driver-S7
> Affects Versions: 0.8.0
> Reporter: Stefano Bossi
> Priority: Major
> Attachments: Screenshot 2020-08-22 at 09.57.45.png,
> readComplexDBError.pcapng, readLongIntArray_v0.8.0_Error.pcapng,
> readLongIntArray_v0_6_0.pcapng
>
>
> Dear Chris,
> I need to report an another bug.
> As you know I am trying to read a very complex Data Bloc from a S7-1200, in
> the future I will try with a 1500. A picture of one of this block in in the
> attached picture.
> I found a problem which actually is similar to the String problem I reported
> in
> [PLC4X-240|https://issues.apache.org/jira/projects/PLC4X/issues/PLC4X-240],
> in reading long array of Int.
> The software running in the PLC as a component which actually samples an
> analog value a store the data in long Array of Integer or Real. An example is:
> {code:java}
> PLC_CellValue_2[400]='%DB2:928.0:INT[400]'
> {code}
> or
> {code:java}
> PLC_SpeedNotSafety[400]='%DB2:6542.0:REAL[400]'
> {code}
> Reading such a long array of values is not possible because the request on
> the wire is for a too huge payload (probably this is the same problem we had
> with the string).
> I have attached the wireshark capture for you.
> I did the comparison with the 0.6.0 version of the library and the array is
> correctly read. On the wire I see 3 read of 110 Integer and a last one of 70
> which are my 400 Integer.
> As for this reading I have captured the wireshark.
> just to complete the big picture my final target is to read a big DB. In this
> complex scenario there a similar problem that I think is a data request size
> problem too.
> If I try to read a list of variables like this one:
> {code:java}
> PLC_ReportColpoDateLast='%DB2:0.0:DATE_AND_TIME'
> PLC_@timestamp='%DB2:12.0:DATE_AND_TIME'
> PLC_ReportColpoDateLastID='%DB2:24.0:DINT'
> PLC_ReportColpoDateID='%DB2:28.0:DINT'
> PLC_RichiestaCurva='%DB2:32.0:INT'
> PLC_TrasferimentoCurva='%DB2:34.0:BOOL'
> PLC_ArchiveReport='%DB2:36.0:BOOL'
> PLC_DeleteReport='%DB2:36.1:BOOL'
> PLC_Report='%DB2:36.2:BOOL'
> PLC_Enable='%DB2:36.3:BOOL'
> PLC_SetCelloffset='%DB2:36.4:BOOL'
> PLC_ResCelloffset='%DB2:36.5:BOOL'
> PLC_IDX='%DB2:38.0:INT'
> PLC_KW='%DB2:40.0:BOOL'
> PLC_TemCen='%DB2:42.0:REAL'
> PLC_TemBiella='%DB2:46.0:REAL'
> PLC_TemBroDx='%DB2:50.0:REAL'
> PLC_TemBroSx='%DB2:54.0:REAL'
> PLC_PreCen='%DB2:58.0:REAL'
> PLC_PreFreno='%DB2:62.0:REAL'
> PLC_PreCil='%DB2:66.0:REAL'
> PLC_EncPosAct='%DB2:70.0:REAL'
> PLC_EncPosActSafety='%DB2:74.0:REAL'
> PLC_EncSpeedSafety='%DB2:78.0:REAL'
> PLC_EncSpeed='%DB2:82.0:REAL'
> PLC_CellValue[5]='%DB2:86.0:INT[5]'
> PLC_CellValueOffset[5]='%DB2:96.0:INT[5]'
> PLC_N_TotPezzi='%DB2:106.0:DINT'
> PLC_N_TotColpi='%DB2:110.0:DINT'
> PLC_KW_Max='%DB2:114.0:INT'
> PLC_CellValueMax[5]='%DB2:116.0:INT[5]'
> PLC_CellValue_1[2]='%DB2:126.0:INT[2]'
> PLC_CellValue_2[400]='%DB2:928.0:INT[100]'
> {code}
> The error I find on the wire is the same. Pleas note that in the list of
> variables there are no array of 400 samples but, I suppose, that the sum of
> all the request fire the same bug about the request of more than 240 byte
> length.
> I have attached a wireshark capture of this scenario too.
> Hope this analysis could help to find an universal solution for this problem.
> Regards,
> Stefano
> P.S. As usual I am using the HellpPlc4x code and the latest compiled version
> of the 0.8.0 library.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
