Re: Generating Drivers

2020-03-18 Thread Christofer Dutz
I'd just do the entire tutorial with the EIP from the start ... no need to disguise anything here. And this way a user can have a look at the full module if he likes. Chris Am 18.03.20, 15:00 schrieb "Etienne Robinet" <43...@etu.he2b.be>: Hi Chris, so you think of starting with the

Re: Generating Drivers

2020-03-18 Thread Christofer Dutz
Hi Etienne, I think Otto is right. You start off the tutorial by building a driver for the Brol Then your mspec module provides "eip" public String getProtocolCode() { return "eip"; } So in theory the code generator will be looking for a "Brol" module and all it has is a "eip"

Re: Generating Drivers

2020-03-18 Thread Etienne Robinet
Hi Chris, so you think of starting with the MSPEC, then the Configuration & the Driver to end with the Logic? Of course you can convert it to publish it! :) @Otto what do you mean? I took example on the EIP to show how it could look like because the code depends on the protocol you're

Re: Generating Drivers

2020-03-18 Thread Otto Fowler
That page is really nice! You need to take a pass and remove the EIP references though. Nice job On March 18, 2020 at 07:20:26, Etienne Robinet (43...@etu.he2b.be) wrote: Hi all, I finished the EipFieldHandler with the basic types, and also the document I talked about yesterday. You can

Re: Generating Drivers

2020-03-18 Thread Christofer Dutz
Hi Etienne, I guess all we are missing is that we get notice from secretary@ that your ICLA is on file as the whole contribution is well above the "minor contribution" threshold ;-) Regarding your documentation. It looks really good ... the only thing I would probably suggest to change (if

Re: Generating Drivers

2020-03-18 Thread Etienne Robinet
Hi all, I finished the EipFieldHandler with the basic types, and also the document I talked about yesterday. You can have a look here as it is on my branch. https://github.com/etiennerobinet/plc4x/blob/develop/Writing%20generated%20Driver.md What do we need more now to merge this to the dev

Re: Generating Drivers

2020-03-17 Thread Christofer Dutz
That's more than we could ask for and very happy you're doing it. Your contribution is extremely appreciated. Chris Am 17.03.20, 15:49 schrieb "Robinet, Etienne" <43...@etu.he2b.be>: Hi, I was documenting the whole process and I noticed I forgot something, the EIPFieldHandler.

Re: Generating Drivers

2020-03-17 Thread Robinet, Etienne
Hi, I was documenting the whole process and I noticed I forgot something, the EIPFieldHandler. This will be used to encode the values of the read request right? I will have a look at this tomorrow, then I can send you also the document I am working on if you want. Etienne Le mar. 17 mars 2020 à

Re: Generating Drivers

2020-03-17 Thread Robinet, Etienne
Hi again, I've just send it. Etienne Le mar. 17 mars 2020 à 14:01, Julian Feinauer 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" : > > Hi Etienne, > > I think it's

Re: Generating Drivers

2020-03-17 Thread Julian Feinauer
Hi, it is, yes (first paragraph) and the mail is correct. A scan suffices : ) Julian Am 17.03.20, 14:00 schrieb "Christofer Dutz" : Hi Etienne, I think it's secret...@apache.org ... should be mentioned in the document. Chris Am 17.03.20, 13:51 schrieb

Re: Generating Drivers

2020-03-17 Thread Christofer Dutz
Hi Etienne, I think it's secret...@apache.org ... should be mentioned in the document. Chris Am 17.03.20, 13:51 schrieb "Robinet, Etienne" <43...@etu.he2b.be>: Hi Julian, where should I send it once signed? Etienne Le mar. 17 mars 2020 à 13:34, Julian Feinauer

Re: Generating Drivers

2020-03-17 Thread Robinet, Etienne
Hi Julian, where should I send it once signed? Etienne Le mar. 17 mars 2020 à 13:34, Julian Feinauer 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

Re: Generating Drivers

2020-03-17 Thread Julian Feinauer
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

Re: Generating Drivers

2020-03-17 Thread Etienne Robinet
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 wrote: > Hi Etienne, > > I would suggest you create a Pull

Re: Generating Drivers

2020-03-17 Thread Christofer Dutz
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" <43...@etu.he2b.be>: Hi Chris, the problem was the tag was a parameter from COTP and not

Re: Generating Drivers

2020-03-17 Thread Etienne Robinet
Hi Chris, the problem was the 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 Response/Request. The only little issue I have is with the parsing from the Java Object to an XML string (to

Re: Generating Drivers

2020-03-17 Thread Christofer Dutz
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

Re: Generating Drivers

2020-03-16 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-16 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-16 Thread Christofer Dutz
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" <43...@etu.he2b.be>: Hi, Ok

Re: Generating Drivers

2020-03-16 Thread Etienne Robinet
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 wrote: > Hi Etienne, > > it's there ... have a look: >

Re: Generating Drivers

2020-03-16 Thread Christofer Dutz
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

Re: Generating Drivers

2020-03-16 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-16 Thread Christofer Dutz
Hi Etienne, From the error you are having, have you updated PLC4X and re-built it? I think your fork has become outdated ... I would suggest to pull the latest changes from upstream. Chris Am 16.03.20, 13:19 schrieb "Etienne Robinet" <43...@etu.he2b.be>: Hi Chris, Thanks for

Re: Generating Drivers

2020-03-16 Thread Christofer Dutz
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

Re: Generating Drivers

2020-03-16 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-16 Thread Christofer Dutz
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" <43...@etu.he2b.be>: Hi Chris, I will have a look to build the tests for the parser/serializer.

Re: Generating Drivers

2020-03-16 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-16 Thread Christofer Dutz
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

Re: Generating Drivers

2020-03-16 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-13 Thread Christofer Dutz
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

Re: Generating Drivers

2020-03-13 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-13 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-13 Thread Christofer Dutz
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

Re: Generating Drivers

2020-03-13 Thread Etienne Robinet
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 wrote: > Hey, > > there ist he possibility to get the remaining size oft he bytes of the > message. Does that help? > Otherwise

Re: Generating Drivers

2020-03-13 Thread Christofer Dutz
Hi Etienne, Having a look at your code example. It looks as you simply want to gobble up the remaining bytes of the response and simply store that in a byte[]. You are using "length". The semantics is that the parser will check if the number of bytes given in the expression has been read. If

Re: Generating Drivers

2020-03-13 Thread Julian Feinauer
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" <43...@etu.he2b.be>: Hi Julian, so how should I declare this field in the mspec if I can not get

Re: Generating Drivers

2020-03-13 Thread Etienne Robinet
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 wrote: > Hi Etienne, > > first, Congratulations on your Progress! > To you question: > This is a common issue with many protocols. > We solve that

Re: Generating Drivers

2020-03-13 Thread Julian Feinauer
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

Re: Generating Drivers

2020-03-13 Thread Etienne Robinet
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.

Re: Generating Drivers

2020-03-12 Thread Etienne Robinet
Hi Chris, Thanks for that! At the end of the process I will document everything so it will be easier for all to understand, adapt or improve it. Etienne > Le 12 mars 2020 à 22:34, Christofer Dutz a écrit : > > Hi Etienne, > > that's amazing news :-) ... congratulations :-) > > Also had a

Re: Generating Drivers

2020-03-12 Thread Christofer Dutz
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

Re: Generating Drivers

2020-03-12 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-12 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-11 Thread Christofer Dutz
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

Re: Generating Drivers

2020-03-11 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-10 Thread Etienne Robinet
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

Re: Generating Drivers

2020-03-10 Thread Cesar Garcia
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.,

Re: Generating Drivers

2020-03-10 Thread Christofer Dutz
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

Generating Drivers

2020-03-10 Thread Etienne Robinet
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: