Stefano Bossi created PLC4X-241: ----------------------------------- Summary: 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 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)