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