Hi again, I've just send it. Etienne
Le mar. 17 mars 2020 à 14:01, Julian Feinauer <[email protected]> a écrit : > Hi, > > it is, yes (first paragraph) and the mail is correct. > A scan suffices : ) > > Julian > > Am 17.03.20, 14:00 schrieb "Christofer Dutz" <[email protected]>: > > Hi Etienne, > > I think it's [email protected] ... > should be mentioned in the document. > > Chris > > > Am 17.03.20, 13:51 schrieb "Robinet, Etienne" <[email protected]>: > > Hi Julian, > where should I send it once signed? > > Etienne > > Le mar. 17 mars 2020 à 13:34, Julian Feinauer < > [email protected]> > a écrit : > > > Hi, > > > > awesome work Etienne. > > Just a quick note from me... did you already sign a ICLA with > the Apache > > Foundation? If not you should do that now, otherwise we can not > accept this > > big (and awesome!!) contribution. > > > > You can find more information here: > https://www.apache.org/licenses/ > > Direkt Link tot he ICLA: https://apache.org/licenses/icla.pdf > > > > Best > > Julian > > > > Am 17.03.20, 13:30 schrieb "Etienne Robinet" <[email protected] > >: > > > > 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]>* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
