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
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"
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
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
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
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
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.
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 à
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
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
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
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
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
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
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
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
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
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
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
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
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:
>
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.,
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
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:
50 matches
Mail list logo