[
https://issues.apache.org/jira/browse/PLC4X-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182341#comment-17182341
]
Christofer Dutz commented on PLC4X-241:
---------------------------------------
This is exactly the same problem as one item itself is bigger than can fit into
one request. Guess I'll have to port the code for splitting... But that will
require time and I currently have to do some paid work first.
> 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.3.4#803005)
