Ah .. ok ... Think I understand the problem. Currently the driver supports automatically splitting individual requests into multiple PDUs so if you request 10 items each 100bytes, this will get split up. However your use case would require to split up one item into 2 sub-items and to merge them after processing the responses. That's currently not supported at all. But we are planning on supporting that in the future as part of a planned addition to optimize our requests by rewriting what we ask the PLC.
This belongs into the same category that it's more efficient to read a bigger block of multiple bytes instead of multiple smaller blocks. I/we could try to explicitly handle the splitting of large blocks use case as it's probably way more easy to implement than the final rewrite functionality. Chris Am 26.09.18, 09:46 schrieb "Uschold Andreas" <[email protected]>: Hi Chris, I already attached a tcpdump and a thread dump to PLC4X-58. The odd thing is that two requests are sent to the plc (S7 315-2). The first one is completly empty (zero items) and the second one is too big. Andreas -----Ursprüngliche Nachricht----- Von: Christofer Dutz [mailto:[email protected]] Gesendet: Mittwoch, 26. September 2018 15:17 An: [email protected] Betreff: [EXT] Re: [DISCUSS] Apache PLC4X (Incubating) 0.1.0 And I just had a short look just before the first Keynote at ApacheCon. Regarding: PLC4X-59 [S7] Reading a UDINT with value 0x00000000 and non positive floating point values does not work The different types in S7 definitely have to be fine-tuned. I checked the UDINT constants in org.apache.plc4x.java.s7.netty.model.types.TransportSize and I noticed that the constants for UDINT and DINT are the same (Which can't be correct) same with SINT and USINT and INT and UINT ... so we will probably need to find out how to distinguish these types. So if anyone has some way to reliably read these values, it would be super helpful to do so and record the communication with WireShark and attach these recordings to the Jira issue. I just didn't have the means to produce such traffic without looking in the sourcecode of WireShart (Which would be an absolute No-Go as it's GPL licensed) PLC4X-56 [S7] S7Field does not recognize addresses with numElements present PLC4X-57 [S7] Response for address with numElements contains only first item Will definitely be fixed by Julians proposed ANTLR parser. PLC4X-58 [S7] Reading more then PDU with one request blocks calling thread indefinitly This is exactly what I have been using and testing so I'm a little surprised. Could you please do a WireShark recording and attach that to the issue? Chris Am 26.09.18, 08:16 schrieb "Julian Feinauer" <[email protected]>: Hey, I had the exact same discussion with Sebastian on slack (he also suggested 0.2.0). Because he fixed Modbus and we want to have it releases : ) So I don’t care about the number that much as long as we do it regularly and prepare a 0.2.0 as a "(bug-)fixed" 0.1.0. Its good that we're all on the same side here. Julian Am 26.09.18, 14:12 schrieb "Christofer Dutz" <[email protected]>: By the way ... Just noticed that I replied to the vote thread ... Should have been here. So please take the discussion here. Chris Outlook for Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Stefan Bodewig <[email protected]> Sent: Monday, September 24, 2018 10:50:13 PM To: [email protected] Subject: Re: [DISCUSS] Apache PLC4X (Incubating) 0.1.0 On 2018-09-24, Justin Mclean wrote: > Hi, >> * It looks as if plc4x-parent-0.1.0-rc2 was the git tag for the RC as it >> matches the source zip (which misses the .gitignore but includes an >> extra DEPDENDENCIES file, BTW). The name looks a little strange, is >> this going to be "fixed" for the final release? > As tags change be changed it’s best to include the git hash in the > vote email. True. Infra protects tags that start with "rel/" that's why the final tag should be named like this. Stefan
