[
https://issues.apache.org/jira/browse/PLC4X-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466846#comment-17466846
]
Christofer Dutz commented on PLC4X-241:
---------------------------------------
Infirmary we then need someone with an s7 that supports long datatypes to work
on this
> 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)
