Hi Chris, I will do the PR. inside the fork there are also the changes I did to the Camel component a couple of weeks ago (passing a List of queries and returning a List of values).
Etienne On 2020/03/17 10:25:01, Christofer Dutz <[email protected]> wrote: > Hi Etienne, > > I would suggest you create a Pull Request for your changes so we can pull > them in. > We can then work on finalizing this together. > > Chris > > > > Am 17.03.20, 11:22 schrieb "Etienne Robinet" <[email protected]>: > > Hi Chris, > the problem was the <parameter> tag was a parameter from COTP and not > propper to XML. Just removed it and it found the right parameters. I pushed > the test for Parser/Serializer for Read&Write Response/Request. The only > little issue I have is with the parsing from the Java Object to an XML string > (to compare). It seems like it still has some difficulties to correctly parse > a byte[]; for the rest everything should be OK. > What needs to be done more on the driver? > Etienne > On 2020/03/17 08:00:49, Christofer Dutz <[email protected]> > wrote: > > Hi Etienne, > > > > sorry for the late response ... couldn't read the image on my phone, > but on the computer it's fine. > > > > In your case the root element needs to be EipConnectionRequest and not > EipRequest. > > > > I have to admit I too haven't completely grasped all the details of how > Jackson parses and serializes stuff. > > But usually I paste an empty xml representation (in your case an empty > EipPacket element) and put in the bytes. > > Then I run the test and obviously it fails complaining about what it > parsed and that it looks different. > > I manually examine if the xml is correct and replace the empty element > with the printed out verson. > > > > Chris > > > > > > > > Am 16.03.20, 17:20 schrieb "Etienne Robinet" <[email protected]>: > > > > Hi again, > > I started also to test serializer and parser. Here is the problem I > am facing: https://i.imgur.com/stmEqlm.png > > On the left you see the testcase, on the right the code in the > ProtocolLogic. I don't know what I a m doing wrong, but from the log it seems > it does only look for the parameters I am giving? > > > > Etienne > > On 2020/03/16 15:38:33, Etienne Robinet <[email protected]> wrote: > > > Hi Chris, > > > I did a similar test for reading a tag. As I never did such tests > before, I don't know if the method is correct, but the results are similar to > the ones I get running the same test for the s7. I also pushed this to my > fork. Tomorrow I will try to do some tests on the PLC to see if I can perform > fetching a lot of data (like I did on the s7) and if the writing works. > > > > > > Etienne > > > > > > On 2020/03/16 13:47:53, Christofer Dutz > <[email protected]> wrote: > > > > Hi Etienne, > > > > > > > > You probably pulled in a SNAPSHOT from our maven repo ... if > this is newer than yours, Maven usually pulls new versions the first time you > build on every day. ... yes this can be annoying ;-) > > > > > > > > Chris > > > > > > > > Am 16.03.20, 14:41 schrieb "Etienne Robinet" > <[email protected]>: > > > > > > > > Hi, > > > > Ok I see, seems to be resolved once rebuilt. But how does > it come that it generates the getLengthInBits() before I updated it? > > > > > > > > Etienne > > > > On 2020/03/16 13:10:24, Christofer Dutz > <[email protected]> wrote: > > > > > Hi Etienne, > > > > > > > > > > it's there ... have a look: > > > > > > https://github.com/apache/plc4x/blob/develop/plc4j/spi/src/main/java/org/apache/plc4x/java/spi/generation/Message.java > > > > > > > > > > The problem is that you checked out your fork. That > doesn't update automatically if someone pushes anything to our repo. > > > > > You manually have to do that. > > > > > > > > > > Please check "Keeping your fork up to date" on > https://plc4x.apache.org/developers/contributing.html > > > > > > > > > > Hope that helps. > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > Am 16.03.20, 13:50 schrieb "Etienne Robinet" > <[email protected]>: > > > > > > > > > > Hi Chris, > > > > > > > > > > buy how do I stop it from generating the error? He > calls the getLengthInBits on an implmentation of Message so that is where the > error happens (also the @Override). I checked the Message interface and there > is no such metho, also checked the pojo-template and couldn't find the > method. I did not had that before when generating sources (I think since I > ran some tests on the PLC). > > > > > Etienne > > > > > On 2020/03/16 12:46:48, Christofer Dutz > <[email protected]> wrote: > > > > > > Hi Etienne, > > > > > > > > > > > > well the getLengthInBytes is still there ... it > just calls the getLengthInBits and divides that by 8. > > > > > > The reason was that with the Firmata driver we > first had a protocol where the getLengthInBytes returned 0 because one > datatype didn't have a full multiple of 8 as content. This made > getLengthInBytes return 0 instead of 1. > > > > > > > > > > > > In general nothing should have changed as the > getLengthInBytes still exists. It's just that there is an additional > getLengthInBits. > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 16.03.20, 13:19 schrieb "Etienne Robinet" > <[email protected]>: > > > > > > > > > > > > Hi Chris, > > > > > > > > > > > > Thanks for the advice I will try to find a way > for that. > > > > > > I tried executing some tests but I realisedI > got an error on runtime. After looking at the generated source, this is what > I have: > > > > > > https://i.imgur.com/LflQvpw.png > > > > > > Why does the getLengthInBytes method got > swapped by getLengthInBits? The error comes that he is looking for the > gteLengthInBits() on a Message, and the @Override is also wrong. > > > > > > > > > > > > Etienne > > > > > > On 2020/03/16 11:46:53, Christofer Dutz > <[email protected]> wrote: > > > > > > > Hi Etienne, > > > > > > > > > > > > > > well there must be some way to distinguish > the two ... perhaps using more than one field to discriminate the types? > > > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 16.03.20, 12:01 schrieb "Etienne Robinet" > <[email protected]>: > > > > > > > > > > > > > > Hi Chris, > > > > > > > I will have a look to build the tests for > the parser/serializer. > > > > > > > > > > > > > > I have another question. In Cip when data > is too large and wont fit into a signle packet (>500 bytes), we use > fragmentedRequest. The problem I'm facing is: ReadFragmentedService and > UnconnectedRequest have the same service number 0x52. > > > > > > > From the structure, the > UnconnectedRequest contains the fragmentedServiceRequest; but the responses > are at the same 'level' as the UnconnectedRequest. So I don't know for now > how to implement this and if we even need it (but I still find a good option); > > > > > > > > > > > > > > Etienne > > > > > > > On 2020/03/16 10:35:34, Christofer Dutz > <[email protected]> wrote: > > > > > > > > Hi Etienne, > > > > > > > > > > > > > > > > I would also suggest you have a look at > the unit-test framework I built for testing the parsers, serializers and the > model. > > > > > > > > > > > > > > > > > plc4j/drivers/s7/src/test/java/org/apache/plc4x/java/s7/readwrite/S7DriverTestsuite.java > > > > > > > > > plc4j/drivers/s7/src/test/resources/testsuite/S7DriverTestsuite.xml > > > > > > > > > > > > > > > > I'm currently still working on an > integration test-suite that will test the protocol component using > pre-defined messages: > > > > > > > > > > > > > > > > > plc4j/drivers/s7/src/test/java/org/apache/plc4x/java/s7/readwrite/S7ParserSerializerTestsuite.java > > > > > > > > > plc4j/drivers/s7/src/test/resources/testsuite/S7ParserSerializerTestsuite.xml > > > > > > > > > > > > > > > > But I wouldn't call that production > ready yet as I was distracted by other work and have to check where I dropped > the ball last time. > > > > > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 16.03.20, 11:28 schrieb "Etienne > Robinet" <[email protected]>: > > > > > > > > > > > > > > > > Hi Chris, > > > > > > > > this did also the trick and looks > far more clean, thanks for the help on that! > > > > > > > > > > > > > > > > I am now working on the writing, > might have a look on connected messages afterwards. The fact is that now I'm > doing home office so it will be a bit trickier to test, but I might get a > solution in the following days. > > > > > > > > Stay safe, > > > > > > > > > > > > > > > > Etienne > > > > > > > > On 2020/03/13 17:09:06, Christofer > Dutz <[email protected]> wrote: > > > > > > > > > Hi Etienne, > > > > > > > > > > > > > > > > > > I just took the version before > your last commit and applied the pattern how you pass along the arguments. > > > > > > > > > Please have a look ... I haven't > compiled the spec, but it should work. As you can see, if you want to use the > > > > > > > > > arguments inside a sub-type, you > have to re-declare the variable (identical name and type) in the sub-type. > > > > > > > > > > > > > > > > > > > > > > > > > > > // > > > > > > > > > // Licensed to the Apache > Software Foundation (ASF) under one > > > > > > > > > // or more contributor license > agreements. See the NOTICE file > > > > > > > > > // distributed with this work > for additional information > > > > > > > > > // regarding copyright > ownership. The ASF licenses this file > > > > > > > > > // to you under the Apache > License, Version 2.0 (the > > > > > > > > > // "License"); you may not use > this file except in compliance > > > > > > > > > // with the License. You may > obtain a copy of the License at > > > > > > > > > // > > > > > > > > > // > http://www.apache.org/licenses/LICENSE-2.0 > > > > > > > > > // > > > > > > > > > // Unless required by applicable > law or agreed to in writing, > > > > > > > > > // software distributed under > the License is distributed on an > > > > > > > > > // "AS IS" BASIS, WITHOUT > WARRANTIES OR CONDITIONS OF ANY > > > > > > > > > // KIND, either express or > implied. See the License for the > > > > > > > > > // specific language governing > permissions and limitations > > > > > > > > > // under the License. > > > > > > > > > // > > > > > > > > > > > > > > > > > > > ////////////////////////////////////////////////////////////////// > > > > > > > > > ///EthernetIP Header of size 24 > > > > > > > > > > ///////////////////////////////////////////////////////////////// > > > > > > > > > > > > > > > > > > [discriminatedType 'EipPacket' > > > > > > > > > [discriminator uint 16 > 'command'] > > > > > > > > > [implicit uint 16 'len' > 'lengthInBytes - 24'] > > > > > > > > > [simple uint 32 > 'sessionHandle'] > > > > > > > > > [simple uint 32 > 'status'] > > > > > > > > > [array uint 8 > 'senderContext' count '8'] > > > > > > > > > [simple uint 32 > 'options'] > > > > > > > > > [typeSwitch 'command' > > > > > > > > > ['0x0065' > EipConnectionRequest > > > > > > > > > [const uint > 16 'protocolVersion' '0x01'] > > > > > > > > > [const uint > 16 'flags' '0x00'] > > > > > > > > > ] > > > > > > > > > ['0x0066' > EipDisconnectRequest > > > > > > > > > ] > > > > > > > > > ['0x006F' CipRRData > [uint 16 'len'] > > > > > > > > > [reserved uint > 32 '0x00000000'] > > > > > > > > > [reserved uint > 16 '0x0000'] > > > > > > > > > [simple > CipExchange 'exchange' ['len-6']] > > > > > > > > > ] > > > > > > > > > ] > > > > > > > > > ] > > > > > > > > > [type 'CipExchange' [uint 16 > 'exchangeLen'] > > > > > > > > > [const uint > 16 'itemCount' '0x0002'] //2 items > > > > > > > > > [const uint > 32 'nullPtr' '0x0'] //NullPointerAddress > > > > > > > > > [const uint > 16 'UnconnectedData' '0x00B2'] //Connection Manager > > > > > > > > > [implicit uint > 16 'size' 'lengthInBytes - 8 - 2'] //remove fields above > and routing > > > > > > > > > [simple CipService > 'service' ['exchangeLen - 10'] ] > > > > > > > > > ] > > > > > > > > > > > > > > > > > > [discriminatedType 'CipService' > [uint 16 'serviceLen'] > > > > > > > > > [discriminator uint 8 > 'service'] > > > > > > > > > [typeSwitch 'service' > > > > > > > > > ['0x4C' CipReadRequest > > > > > > > > > [simple int 8 > 'RequestPathSize'] > > > > > > > > > [array int 8 > 'tag' length '(RequestPathSize*2)'] > > > > > > > > > [simple uint > 16 'elementNb'] > > > > > > > > > ] > > > > > > > > > ['0xCC' CipReadResponse > [uint 16 'serviceLen'] > > > > > > > > > [reserved uint > 8 '0x00'] > > > > > > > > > [simple uint > 8 'status'] > > > > > > > > > [simple uint > 8 'extStatus'] > > > > > > > > > [enum > CIPDataTypeCode 'dataType'] > > > > > > > > > [array int > 8 'data' length 'serviceLen-6'] > > > > > > > > > ] > > > > > > > > > ['0x0A' > MultipleServiceRequest [uint 16 'serviceLen'] > > > > > > > > > [const int 8 > 'RequestPathSize' '0x02'] > > > > > > > > > [const uint 32 > 'RequestPath' '0x01240220'] //Logical Segment: Class(0x20) 0x02, > Instance(0x24) 01 (Message Router) > > > > > > > > > [simple Services > 'data' ['serviceLen - 6 ']] > > > > > > > > > ] > > > > > > > > > ['0x8A' > MultipleServiceResponse [uint 16 'serviceLen'] > > > > > > > > > [reserved uint > 8 '0x0'] > > > > > > > > > [simple uint > 8 'status'] > > > > > > > > > [simple uint > 8 'extStatus'] > > > > > > > > > [simple Services > 'data' ['serviceLen - 4']] > > > > > > > > > ] > > > > > > > > > ['0x0052' > CipUnconnectedRequest > > > > > > > > > [reserved uint > 8 '0x02'] > > > > > > > > > [reserved uint > 8 '0x20'] // setRequestPathLogicalClassSegment > > > > > > > > > [reserved uint > 8 '0x06'] // set request class path > > > > > > > > > [reserved uint > 8 '0x24'] // setRequestPathLogicalInstanceSegment > > > > > > > > > [reserved uint > 8 '0x01'] // setRequestPathInstance > > > > > > > > > [reserved uint > 16 '0x9D05'] //Timeout 5s > > > > > > > > > [implicit uint > 16 'messageSize' 'lengthInBytes - 10 - 4'] //substract above and > routing > > > > > > > > > [simple > CipService 'service'] > > > > > > > > > [const uint > 16 'route' '0x0001'] > > > > > > > > > [simple int > 8 'backPlane'] > > > > > > > > > [simple int > 8 'slot'] > > > > > > > > > ] > > > > > > > > > ] > > > > > > > > > ] > > > > > > > > > > > > > > > > > > [type 'Services' [uint 16 > 'servicesLen'] > > > > > > > > > [simple uint 16 > 'serviceNb'] > > > > > > > > > [array uint 16 > 'offsets' count 'serviceNb'] > > > > > > > > > [array CipService > 'services' count 'serviceNb' ['servicesLen/serviceNb'] ] > > > > > > > > > ] > > > > > > > > > > > > > > > > > > [enum uint 16 > 'CIPDataTypeCode' [uint 8 'size'] > > > > > > > > > ['0X00C1' BOOL > ['1']] > > > > > > > > > ['0X00CA' REAL > ['4']] > > > > > > > > > ['0X00C4' DINT > ['4']] > > > > > > > > > ['0X00C3' INT > ['2']] > > > > > > > > > ['0X00C2' SINT > ['1']] > > > > > > > > > ['0X02A0' STRUCTURED > ['88']] > > > > > > > > > ['0X02A0' STRING > ['88']] > > > > > > > > > ['0X02A0' STRING36 > ['40']] > > > > > > > > > ['-1' UNKNOWN > ['-1']] > > > > > > > > > ] > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope that helps, > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 13.03.20, 17:09 schrieb > "Etienne Robinet" <[email protected]>: > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > sorry for double-posting, but > I found the fix. For me the code does not look that 'sexy' now but it works. > I do not know if I can make it better but for now I will stick to this :) I > pushed it to the 'eip' branch of my fork. > > > > > > > > > Have a nice weekend, > > > > > > > > > > > > > > > > > > Etienne > > > > > > > > > On 2020/03/13 14:48:35, > Etienne Robinet <[email protected]> wrote: > > > > > > > > > > Hi, > > > > > > > > > > Thanks for the advice. I am > trying to pass the length down the subclasses, but I'm stuck. This does not > work as it seems: > > > > > > > > > > > https://i.imgur.com/77bbdBN.png CipRRData does not know what 'len' is nor its > value as it seems. > > > > > > > > > > > > > > > > > > > > I wanted to inspire mysefl > from the CotpPayload, but unfortunately, the first byte of the whole packet > is a discriminator (command). > > > > > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > On 2020/03/13 13:52:16, > Christofer Dutz <[email protected]> wrote: > > > > > > > > > > > Hi Etienne, > > > > > > > > > > > > > > > > > > > > > > I think you can solve > your problem in two ways. > > > > > > > > > > > In all you need to pass > down the length of the packet in total from the root type (which knows the > length). > > > > > > > > > > > 1) You keep on just > reading bytes and parse in the protocol logic class (Like in the S7 driver or > KNX) > > > > > > > > > > > 2) You directly parse > PlcValues (using "dataIo" types) > > > > > > > > > > > > > > > > > > > > > > I would prefer option 2 > but 1 is simpler. The reason I'm doing 1) in S7 and KNX is that I need to > know the type from the request to decode in the S7 case and in the KNX case I > need to know the type from an external source in order to decode it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > Am 13.03.20, 14:45 > schrieb "Etienne Robinet" <[email protected]>: > > > > > > > > > > > > > > > > > > > > > > Yes this is exactly > what I need. If I get the remaining bytes, I can know the element numbers as > I have their type! > > > > > > > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > > > > > > > On 2020/03/13 > 13:40:09, Julian Feinauer <[email protected]> wrote: > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > > > > > > > > > > > there ist he > possibility to get the remaining size oft he bytes of the message. Does that > help? > > > > > > > > > > > > Otherwise I misread > your question. > > > > > > > > > > > > > > > > > > > > > > > > Julian > > > > > > > > > > > > > > > > > > > > > > > > Am 13.03.20, 14:37 > schrieb "Etienne Robinet" <[email protected]>: > > > > > > > > > > > > > > > > > > > > > > > > Hi Julian, > > > > > > > > > > > > so how should I > declare this field in the mspec if I can not get its size? > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > > > > > > > > > On 2020/03/13 > 13:35:52, Julian Feinauer <[email protected]> wrote: > > > > > > > > > > > > > Hi Etienne, > > > > > > > > > > > > > > > > > > > > > > > > > > first, > Congratulations on your Progress! > > > > > > > > > > > > > To you > question: > > > > > > > > > > > > > This is a > common issue with many protocols. > > > > > > > > > > > > > We solve that > in the protocol layer by keeping the request until we get the response (see > for Example how we did it for S7). > > > > > > > > > > > > > So you cannot > solve that in mpsec at compile time but have to decode the byte[] you get > with the Information from the Request. > > > > > > > > > > > > > > > > > > > > > > > > > > Hope that > helps! > > > > > > > > > > > > > Julian > > > > > > > > > > > > > > > > > > > > > > > > > > Am 13.03.20, > 14:02 schrieb "Etienne Robinet" <[email protected]>: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Chris, > > > > > > > > > > > > > I have > yet another question. When sending a request for multiple elements (let's say > 10 elements of an array), you get a response from the PLC with all the data > at the end of the packet. The problem is, in the request there is the number > of elements we want, but not in the response. So so the protocol knows how > many elements there are in the response packet, but not the packet itself. > This is quite a problem as for the parse, we need to know the length of the > 'data' array containing the response data (for now it was only depending on > the type, but I would need type*elements). > > > > > > > > > > > > > > > > > > > > > > > > > > I tested > a bit by modifying the generated IO, and 1 way to do it is to get the > remaining bytes and divide this by the datatype size. I just wanted to ask if > someone would know how to declare this in the mspec, as I don't want to touch > at the template. I also thought about having an attribute on the response, > but I don't know how to put an attribute that won't get parsed/serialized. > Hope I am clear enough, but this is a code sample that worked (modifying > generated sources): > > > > > > > > > > > > > > https://i.imgur.com/Xm6DxEZ.png (notice the error but this code works if I > write it myself) > > > > > > > > > > > > > And here > is how I put it in the mspec: https://i.imgur.com/Ye1Kl9q.png (you can see > the number of element is not present) > > > > > > > > > > > > > > > > > > > > > > > > > > Any help > is welcome of course! :) > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On > 2020/03/12 21:34:12, Christofer Dutz <[email protected]> wrote: > > > > > > > > > > > > > > Hi > Etienne, > > > > > > > > > > > > > > > > > > > > > > > > > > > > that's > amazing news :-) ... congratulations :-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also > had a look at your mspec and I think you have done a great job with that. I > wasn't quite sure about the relation between CipRRData and CipExchange, but > your solution looks rock-solid. > > > > > > > > > > > > > > > > > > > > > > > > > > > > And now > reading that you even managed to get something working, that makes me very > happy. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tomorrow I'll be a little consumed with signing the contract with the KNX > foundation but I'll try to have a look at your fork. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > for your great work :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am > 12.03.20, 17:50 schrieb "Etienne Robinet" <[email protected]>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi > all, > > > > > > > > > > > > > > > again a productive day, I pushed to my branch and the driver support reading, > multiple reading and the camel component works (in karaf) and takes a List of > strings. Tested it on a different PLC and it also worked! Next I'm going to > implement the array readings and then maybe writing (tests needs to be done > too). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > > > > > > > > > > > > > On > 2020/03/12 07:18:32, Etienne Robinet <[email protected]> wrote: > > > > > > > > > > > > > > > > Hi Chris, > > > > > > > > > > > > > > > > yes that's what I thought so I managed to work around like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/etiennerobinet/plc4x/blob/eip/protocols/eip/src/main/resources/protocols/eip/eip.mspec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And this works for reading! I managed to make a quick test and read via the > tag name. Now my question is: can I create sub-types that are also > discriminated with sub-subtypes? That would allow to create the ReadRequest > only, as the fields before are mainly constant/implicit. > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2020/03/11 20:24:14, Christofer Dutz <[email protected]> wrote: > > > > > > > > > > > > > > > > > Hi Etienne, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > you are defining the type CipRRData twice ... once as one of the sub-types of > EipPacket and once as a dedicated discriminated type. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PS: I have no idea why I didn't finish writing this email and I just noticed > when closing everything down ... sorry for the late reply. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 11.03.20, 09:30 schrieb "Etienne Robinet" <[email protected]>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a quick question. I've been working on the CIP encapsulation but > hitting a problem with the mspec design. Here is the error I am facing: > https://i.imgur.com/iCfh59n.png > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The problem here is that this CipRRData should also be of type EipPacket. > When the command of an EipPacket is '0x66' this means SendRRData (for > Read/Write and Request/Response so I have to discriminate it on the sub > level). The problem is that after generation, CipRRData implements Message > but does not extend EipPacket. How should I do it? Here is the mspec: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [discriminatedType 'EipPacket' > > > > > > > > > > > > > > > > > [discriminator uint 16 'command'] > > > > > > > > > > > > > > > > > [implicit uint 16 'len' 'lengthInBytes - 24'] > > > > > > > > > > > > > > > > > [simple uint 32 'sessionHandle'] > > > > > > > > > > > > > > > > > [simple uint 32 'status'] > > > > > > > > > > > > > > > > > [array uint 8 'senderContext' count '8'] > > > > > > > > > > > > > > > > > [simple uint 32 'options'] > > > > > > > > > > > > > > > > > [typeSwitch 'command' > > > > > > > > > > > > > > > > > ['0x0065' EipConnectionRequest > > > > > > > > > > > > > > > > > [const uint 16 'protocolVersion' '0x01'] > > > > > > > > > > > > > > > > > [const uint 16 'flags' '0x00'] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > ['0x0066' EipDisconnectRequest > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > ['0x006F' CipRRData > > > > > > > > > > > > > > > > > [const uint 32 'EipInterface' '0x00000000'] > > > > > > > > > > > > > > > > > [const uint 8 'timeout' '0x0000'] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > [discriminatedType 'CipRRData' > > > > > > > > > > > > > > > > > [simple uint 8 'itemNb'] > > > > > > > > > > > > > > > > > [array CipItem 'items' length 'itemNb'] > > > > > > > > > > > > > > > > > [discriminator uint 8 'CipService'] > > > > > > > > > > > > > > > > > [typeSwitch 'CipService' > > > > > > > > > > > > > > > > > ['0x52' CipUnconnectedRequest > > > > > > > > > > > > > > > > > [simple CommandData 'data'] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > ['0xCC' CipReadResponse > > > > > > > > > > > > > > > > > [reserved uint 8 '0x0000'] > > > > > > > > > > > > > > > > > [simple uint 8 'status'] > > > > > > > > > > > > > > > > > [simple uint 8 'extStatus'] > > > > > > > > > > > > > > > > > [simple uint 8 'dataType'] > > > > > > > > > > > > > > > > > [array uint 8 'data' length 'dataType'] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [type 'CipItem' > > > > > > > > > > > > > > > > > [simple uint 16 'typeID'] > > > > > > > > > > > > > > > > > [simple uint 16 'size'] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [discriminatedType 'CommandData' > > > > > > > > > > > > > > > > > [reserved uint 8 '0x02'] > > > > > > > > > > > > > > > > > [reserved uint 8 '0x20'] // > setRequestPathLogicalClassSegment > > > > > > > > > > > > > > > > > [reserved uint 8 '0x06'] // set request class path > > > > > > > > > > > > > > > > > [reserved uint 8 '0x24'] // > setRequestPathLogicalInstanceSegment > > > > > > > > > > > > > > > > > [reserved uint 8 '0x01'] // setRequestPathInstance > > > > > > > > > > > > > > > > > [discriminator uint 8 'CipService'] > > > > > > > > > > > > > > > > > [typeSwitch 'CipService' > > > > > > > > > > > > > > > > > ['0x4C' CipReadRequest > > > > > > > > > > > > > > > > > [simple uint 8 'RequestPathSize'] > > > > > > > > > > > > > > > > > [reserved uint 8 '0x91'] > > > > > > > > > > > > > > > > > [array uint 8 'tag' length '(RequestPathSize*2) > - 1'] > > > > > > > > > > > > > > > > > [reserved uint 16 '0x0001'] //itemCount set to 1 for > now > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [enum int 16 'CIPDataTypeCode' [uint 8 'size'] > > > > > > > > > > > > > > > > > ['0X00C1' BOOL ['1']] > > > > > > > > > > > > > > > > > ['0X00CA' REAL ['4']] > > > > > > > > > > > > > > > > > ['0X00C4' DINT ['4']] > > > > > > > > > > > > > > > > > ['0X00C3' INT ['2']] > > > > > > > > > > > > > > > > > ['0X00C2' SINT ['1']] > > > > > > > > > > > > > > > > > ['0X02A0' STRUCTURED ['88']] > > > > > > > > > > > > > > > > > ['0X02A0' STRING ['88']] > > > > > > > > > > > > > > > > > ['0X02A0' STRING36 ['40']] > > > > > > > > > > > > > > > > > ['-1' UNKNOWN ['-1']] > > > > > > > > > > > > > > > > > ] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for any help! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > > On 2020/03/10 15:18:47, Etienne Robinet <[email protected]> wrote: > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > I've managed to implement the EIP Session Register/Unregister (used for > connected message which is best for high frequency fetching). I will push it > to my branch and create a document explaining my steps. > > > > > > > > > > > > > > > > > > Next I want to do was to to the CIP encapsulation part for accessing > tag by their name. The thing is, CIP is (from what I heard) proper to Allen > Bradley. Should I leave it in the EIP driver or modify and adapt the current > AB driver later on? For now I will continue on eip. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2020/03/10 14:41:42, Cesar Garcia <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can document the process step by step, you will surely find > observation > > > > > > > > > > > > > > > > > > > points. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am working with the handwritten S7 driver, but in the future I would > > > > > > > > > > > > > > > > > > > support the team in migrate to mspec, so the experience you will gain > with > > > > > > > > > > > > > > > > > > > the Etheret / IP is very important. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El mar., 10 mar. 2020 a las 9:17, Christofer Dutz (< > > > > > > > > > > > > > > > > > > > [email protected]>) escribió: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Etienne, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would strongly suggest you install the Antlr plugn for the IDE > you use. > > > > > > > > > > > > > > > > > > > > The problem is that ANTLR seems to gobble up a lot of errors and > tries to > > > > > > > > > > > > > > > > > > > > be smart in a lot of cases. > > > > > > > > > > > > > > > > > > > > Whenever I have problems like this I use the ANTLR visual parser to > parse > > > > > > > > > > > > > > > > > > > > a block of mspec (one type at a time) and try to narrow down the > cause. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 10.03.20, 13:31 schrieb "Etienne Robinet" <[email protected]>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > I've been struggling with implementing the EIP driver. I started > > > > > > > > > > > > > > > > > > > > writing the mspec after creating both a module for the protocol and > the one > > > > > > > > > > > > > > > > > > > > from the driver. I copied and adapted the pom(s) from the AB-ETH > but only > > > > > > > > > > > > > > > > > > > > the enum is generated. > > > > > > > > > > > > > > > > > > > > Here is a link to the forked branch: > > > > > > > > > > > > > > > > > > > > https://github.com/etiennerobinet/plc4x/tree/eip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've been studying the EIP/CIP protocol and now I am confident > what > > > > > > > > > > > > > > > > > > > > the packages should contain but I can not figure out how to > generate this > > > > > > > > > > > > > > > > > > > > with the templates. Am I missing something? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > *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: 0416-681.03.99* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cel: 0414-760.98.95* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Hotline Técnica SIEMENS: 0800 1005080* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Email: [email protected] > > > > > > > > > > > > > > > > > > > <[email protected]>* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
