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)
