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" <[email protected]>:

    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 <[email protected]> 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 <[email protected]> 
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" <[email protected]>:
    > > 
    > >     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 
<[email protected]> 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" <[email protected]>:
    > >     > 
    > >     >     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 
<[email protected]> 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" 
<[email protected]>:
    > >     >     > 
    > >     >     >     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 
<[email protected]> 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" 
<[email protected]>:
    > >     >     >     > 
    > >     >     >     >     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 
<[email protected]> 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 
<[email protected]> 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" 
<[email protected]>:
    > >     >     >     >     > > 
    > >     >     >     >     > >     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 
<[email protected]> 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 
<[email protected]> 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 (<
    > >     >     >     >     > >     > > [email protected]>) 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" <[email protected]>:
    > >     >     >     >     > >     > > >
    > >     >     >     >     > >     > > >     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: 
[email protected]
    > >     >     >     >     > >     > > <[email protected]>*
    > >     >     >     >     > >     > > 
    > >     >     >     >     > >     > 
    > >     >     >     >     > >     
    > >     >     >     >     > > 
    > >     >     >     >     > > 
    > >     >     >     >     > 
    > >     >     >     >     
    > >     >     >     > 
    > >     >     >     > 
    > >     >     >     
    > >     >     > 
    > >     >     > 
    > >     >     
    > >     > 
    > >     > 
    > >     
    > > 
    > > 
    > 
    

Reply via email to