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