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. 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 à 14:41, Robinet, Etienne <43...@etu.he2b.be> a écrit :
> Hi again,
> I've just send it.
>
> Etienne
>
> Le mar. 17 mars 2020 à 14:01, Julian Feinauer <
> j.feina...@pragmaticminds.de> 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" <christofer.d...@c-ware.de
>> >:
>>
>> 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>*
>> > > > > > > > > > > > >
>> > >
>> > > > > > >
>> > > > > > > > > > > > >
>> > >
>> > > > > >
>> > > > > > > > > > > > >
>> > >
>> > > > >
>> > > > > > > > > > > > >
>> > >
>> > > > >
>> > > > > > > > > > > > >
>> > >
>> > > > >
>> > > > > > > > > > > > >
>> > >
>> > > >
>> > > > > > > > > > > > >
>> > >
>> > >
>> > > > > > > > > > > > >
>> > >
>> > >
>> > > > > > > > > > > > >
>> > >
>> > >
>> > > > > > > > > > > > >
>> > >
>> > > > > > > > > > > > >
>> > >
>> > > > > > > > > > > > >
>> > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
>>
>>
