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 <j.feina...@pragmaticminds.de>
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" <43...@etu.he2b.be>:
>
> 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 <christofer.d...@c-ware.de>
> 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" <43...@etu.he2b.be>:
> >
> > 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 <
> christofer.d...@c-ware.de> 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" <
> 43...@etu.he2b.be>:
> > >
> > > 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
<43...@etu.he2b.be>
> 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 <
> christofer.d...@c-ware.de> 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" <
> 43...@etu.he2b.be>:
> > > > >
> > > > > 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 <
> christofer.d...@c-ware.de> 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" <
> 43...@etu.he2b.be>:
> > > > > >
> > > > > > 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 <
> christofer.d...@c-ware.de> 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" <43...@etu.he2b.be>:
> > > > > > >
> > > > > > > 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 <christofer.d...@c-ware.de> 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" <43...@etu.he2b.be>:
> > > > > > > >
> > > > > > > > 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 <christofer.d...@c-ware.de> 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" <43...@etu.he2b.be>:
> > > > > > > > >
> > > > > > > > > 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 <christofer.d...@c-ware.de> 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" <43...@etu.he2b.be>:
> > > > > > > > > >
> > > > > > > > > > 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 <43...@etu.he2b.be> 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 <christofer.d...@c-ware.de> 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" <43...@etu.he2b.be>:
> > > > > > > > > > > >
> > > > > > > > > > > > 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 <j.feina...@pragmaticminds.de>
> 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" <43...@etu.he2b.be>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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 <j.feina...@pragmaticminds.de>
> 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" <43...@etu.he2b.be>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> 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 <christofer.d...@c-ware.de>
> 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" <43...@etu.he2b.be>:
> > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > >
> > 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 <43...@etu.he2b.be> 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 <
> christofer.d...@c-ware.de> 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" <43...@etu.he2b.be
> >:
> > > > > > > > > > > > > >
> > > >
> > > > > > > > > > > > > >
> > > > 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 <43...@etu.he2b.be>
> 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 <
> cesar.gar...@ceos.com.ve> 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 (<
> > > > > > > > > > > > > >
> > > > > > christofer.d...@c-ware.de>) 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" <
> 43...@etu.he2b.be>:
> > > > > > > > > > > > > >
> > > > > > >
> > > > > > > > > > > > > >
> > > > > > > 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: support.aan.automat...@siemens.com
> > > > > > > > > > > > > >
> > > > > > <support.aan.automat...@siemens.com>*
> > > > > > > > > > > > > >
> > > > > >
> > > > > > > > > > > > > >
> > > > >
> > > > > > > > > > > > > >
> > > >
> > > > > > > > > > > > > >
> > > >
> > > > > > > > > > > > > >
> > > >
> > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
