Hi Cesar, if you fixed any issues in that branch, that are not related to publish-subscribe and alarms, it would be great if you could port that to develop.
Chris Am 30.07.20, 17:34 schrieb "Cesar Garcia" <[email protected]>: Hi Stefano, I have made several modifications to the branch for a 0.6.1 revision. If you have the time to try it you can download it from here https://github.com/glcj/plc4x/tree/s7alarm and a number of examples here, https://github.com/glcj/PLC4XS7Examples What version of PLC do you have? Like the rest of the team, I will order to help you if you find any problem. Best regards, El mié., 29 jul. 2020 a las 6:32, Stefano Bossi (<[email protected]>) escribió: > Thanks Chris, > > yes definitely this is a workaround, I am experimenting and learning. > > I really appreciate your time on the investigation of the issue. > > Thanks, > Stefano Bossi > > > > On 29/07/2020 12:08, Christofer Dutz wrote: > > Well that’s a workaround, but not a fix … > > We should focus on fixing this. > > I’ll investigate the issue as soon as I’m done with the Beckhoff ADS/AMS stuff … > > Perhaps Julian could find some time to investigate? > > Chris > > > > Von: Stefano Bossi <[email protected]> <[email protected]> > Antworten an: <[email protected]> <[email protected]> > Datum: Mittwoch, 29. Juli 2020 um 11:41 > An: <[email protected]> <[email protected]> > Betreff: Re: Reading Array of Int > > > I have adopted a workaround reading all the INT variable separated. > > --connection-string 's7:tcp://192.168.1.192?controller-type=S7_1200' --field-addresses '%DB1:274.0:INT' '%DB1:276.0:INT' '%DB1:278.0:INT' '%DB1:280.0:INT' > > In this way on the wire you have: > the query: > > Frame 296: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) on interface utun2, id 0 > > Null/Loopback > > Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192 > > Transmission Control Protocol, Src Port: 57188, Dst Port: 102, Seq: 48, Ack: 50, Len: 67 > > TPKT, Version: 3, Length: 67 > > ISO 8073/X.224 COTP Connection-Oriented Transport Protocol > > S7 Communication > > Header: (Job) > > Parameter: (Read Var) > > Function: Read Var (0x04) > > Item count: 4 > > Item [1]: (DB 1.DBX 274.0 INT 1) > > Item [2]: (DB 1.DBX 276.0 INT 1) > > Item [3]: (DB 1.DBX 278.0 INT 1) > > Item [4]: (DB 1.DBX 280.0 INT 1) > > the answer: > > Frame 297: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on interface utun2, id 0 > > Null/Loopback > > Internet Protocol Version 4, Src: 192.168.1.192, Dst: 192.168.100.4 > > Transmission Control Protocol, Src Port: 102, Dst Port: 57188, Seq: 50, Ack: 115, Len: 45 > > TPKT, Version: 3, Length: 45 > > ISO 8073/X.224 COTP Connection-Oriented Transport Protocol > > S7 Communication > > Header: (Ack_Data) > > Parameter: (Read Var) > > Function: Read Var (0x04) > > Item count: 4 > > Data > > Item [1]: (Success) > > Item [2]: (Success) > > Item [3]: (Success) > > Item [4]: (Success) > > [INFO ] 10:15:44.727 it.fox.datapicker.HelloPlc4x.printResponse() - Value[value-0]: 10 > > [INFO ] 10:15:44.733 it.fox.datapicker.HelloPlc4x.printResponse() - Value[value-1]: 11 > > [INFO ] 10:15:44.737 it.fox.datapicker.HelloPlc4x.printResponse() - Value[value-2]: 12 > > [INFO ] 10:15:44.741 it.fox.datapicker.HelloPlc4x.printResponse() - Value[value-3]: 13 > > Unfortunately my java knowledge are not so advanced to fix the bug in reading the array in a single command, anyway there’s a workaround. > > Hope this mail help some newbies like me to find the right way to read data from the PLC. > > Regards, > Stefano > > On 28/07/2020 11:38, Stefano Bossi wrote: > > Dear plc4x forum, > > I have found a possible problem in reading an array of INT. > I am using the HelloPlc4x app for testing and I am trying to read the field address: '%DB1:274.0:INT[3]' > > In the request, captured via wireShark I can see the query: > > Frame 3: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface utun2, id 0 > > Null/Loopback > > Internet Protocol Version 4, Src: 192.168.100.4, Dst: 192.168.1.192 > > Transmission Control Protocol, Src Port: 54543, Dst Port: 102, Seq: 1, Ack: 1, Len: 31 > > TPKT, Version: 3, Length: 31 > > ISO 8073/X.224 COTP Connection-Oriented Transport Protocol > > S7 Communication > > Header: (Job) > > Parameter: (Read Var) > > Function: Read Var (0x04) > > Item count: 1 > > Item [1]: (DB 1.DBX 274.0 INT 3) > > Variable specification: 0x12 > > Length of following address specification: 10 > > Syntax Id: S7ANY (0x10) > > Transport size: INT (5) > > Length: 3 > > DB number: 1 > > Area: Data blocks (DB) (0x84) > > Address: 0x000890 > > and the response: > > Frame 4: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface utun2, id 0 > > Null/Loopback > > Internet Protocol Version 4, Src: 192.168.1.192, Dst: 192.168.100.4 > > Transmission Control Protocol, Src Port: 102, Dst Port: 54543, Seq: 1, Ack: 32, Len: 31 > > TPKT, Version: 3, Length: 31 > > ISO 8073/X.224 COTP Connection-Oriented Transport Protocol > > S7 Communication > > Header: (Ack_Data) > > Parameter: (Read Var) > > Function: Read Var (0x04) > > Item count: 1 > > Data > > Item [1]: (Success) > > Return code: Success (0xff) > > Transport size: INTEGER (0x05) > > Length: 6 > > Data: 000a000b000c > > The 3 INT I would like to read are there: 000a, 000b, 000c but in the response of: > > PlcReadResponse syncResponse = readRequest.execute().get(); > > only the first one is present. > > I read in jira that there was a similar bug here PLC4X-57<https://issues.apache.org/jira/browse/PLC4X-57> <https://issues.apache.org/jira/browse/PLC4X-57>, is this the same problem? > > Thanks for your help. > > Regards, > Steafano Bossi > > > > > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: [email protected] <[email protected]>*
