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>*
    >     >     >     > >     >     >     >     > >     > > 
    >     >     >     > >     >     >     >     > >     > 
    >     >     >     > >     >     >     >     > >     
    >     >     >     > >     >     >     >     > > 
    >     >     >     > >     >     >     >     > > 
    >     >     >     > >     >     >     >     > 
    >     >     >     > >     >     >     >     
    >     >     >     > >     >     >     > 
    >     >     >     > >     >     >     > 
    >     >     >     > >     >     >     
    >     >     >     > >     >     > 
    >     >     >     > >     >     > 
    >     >     >     > >     >     
    >     >     >     > >     > 
    >     >     >     > >     > 
    >     >     >     > >     
    >     >     >     > > 
    >     >     >     > > 
    >     >     >     > 
    >     >     >     
    >     >     > 
    >     >     > 
    >     >     
    >     > 
    >     > 
    >     
    > 
    > 
    

Reply via email to