Hi Etienne,
I would suggest you create a Pull Request for your changes so we can pull them
in.
We can then work on finalizing this together.
Chris
Am 17.03.20, 11:22 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
Hi Chris,
the problem was the <parameter> tag was a parameter from COTP and not
propper to XML. Just removed it and it found the right parameters. I pushed the
test for Parser/Serializer for Read&Write Response/Request. The only little
issue I have is with the parsing from the Java Object to an XML string (to
compare). It seems like it still has some difficulties to correctly parse a
byte[]; for the rest everything should be OK.
What needs to be done more on the driver?
Etienne
On 2020/03/17 08:00:49, Christofer Dutz <christofer.d...@c-ware.de> wrote:
> Hi Etienne,
>
> sorry for the late response ... couldn't read the image on my phone, but
on the computer it's fine.
>
> In your case the root element needs to be EipConnectionRequest and not
EipRequest.
>
> I have to admit I too haven't completely grasped all the details of how
Jackson parses and serializes stuff.
> But usually I paste an empty xml representation (in your case an empty
EipPacket element) and put in the bytes.
> Then I run the test and obviously it fails complaining about what it
parsed and that it looks different.
> I manually examine if the xml is correct and replace the empty element
with the printed out verson.
>
> Chris
>
>
>
> Am 16.03.20, 17:20 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
>
> Hi again,
> I started also to test serializer and parser. Here is the problem I
am facing: https://i.imgur.com/stmEqlm.png
> On the left you see the testcase, on the right the code in the
ProtocolLogic. I don't know what I a m doing wrong, but from the log it seems
it does only look for the parameters I am giving?
>
> Etienne
> On 2020/03/16 15:38:33, Etienne Robinet <43...@etu.he2b.be> wrote:
> > Hi Chris,
> > I did a similar test for reading a tag. As I never did such tests
before, I don't know if the method is correct, but the results are similar to
the ones I get running the same test for the s7. I also pushed this to my fork.
Tomorrow I will try to do some tests on the PLC to see if I can perform
fetching a lot of data (like I did on the s7) and if the writing works.
> >
> > Etienne
> >
> > On 2020/03/16 13:47:53, Christofer Dutz <christofer.d...@c-ware.de>
wrote:
> > > Hi Etienne,
> > >
> > > You probably pulled in a SNAPSHOT from our maven repo ... if this
is newer than yours, Maven usually pulls new versions the first time you build
on every day. ... yes this can be annoying ;-)
> > >
> > > Chris
> > >
> > > Am 16.03.20, 14:41 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
> > >
> > > Hi,
> > > Ok I see, seems to be resolved once rebuilt. But how does it
come that it generates the getLengthInBits() before I updated it?
> > >
> > > Etienne
> > > On 2020/03/16 13:10:24, Christofer Dutz
<christofer.d...@c-ware.de> wrote:
> > > > Hi Etienne,
> > > >
> > > > it's there ... have a look:
> > > >
https://github.com/apache/plc4x/blob/develop/plc4j/spi/src/main/java/org/apache/plc4x/java/spi/generation/Message.java
> > > >
> > > > The problem is that you checked out your fork. That doesn't
update automatically if someone pushes anything to our repo.
> > > > You manually have to do that.
> > > >
> > > > Please check "Keeping your fork up to date" on
https://plc4x.apache.org/developers/contributing.html
> > > >
> > > > Hope that helps.
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > > Am 16.03.20, 13:50 schrieb "Etienne Robinet"
<43...@etu.he2b.be>:
> > > >
> > > > Hi Chris,
> > > >
> > > > buy how do I stop it from generating the error? He
calls the getLengthInBits on an implmentation of Message so that is where the
error happens (also the @Override). I checked the Message interface and there
is no such metho, also checked the pojo-template and couldn't find the method.
I did not had that before when generating sources (I think since I ran some
tests on the PLC).
> > > > Etienne
> > > > On 2020/03/16 12:46:48, Christofer Dutz
<christofer.d...@c-ware.de> wrote:
> > > > > Hi Etienne,
> > > > >
> > > > > well the getLengthInBytes is still there ... it just
calls the getLengthInBits and divides that by 8.
> > > > > The reason was that with the Firmata driver we first
had a protocol where the getLengthInBytes returned 0 because one datatype
didn't have a full multiple of 8 as content. This made getLengthInBytes return
0 instead of 1.
> > > > >
> > > > > In general nothing should have changed as the
getLengthInBytes still exists. It's just that there is an additional
getLengthInBits.
> > > > >
> > > > > Chris
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Am 16.03.20, 13:19 schrieb "Etienne Robinet"
<43...@etu.he2b.be>:
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > Thanks for the advice I will try to find a way
for that.
> > > > > I tried executing some tests but I realisedI got
an error on runtime. After looking at the generated source, this is what I have:
> > > > > https://i.imgur.com/LflQvpw.png
> > > > > Why does the getLengthInBytes method got swapped
by getLengthInBits? The error comes that he is looking for the
gteLengthInBits() on a Message, and the @Override is also wrong.
> > > > >
> > > > > Etienne
> > > > > On 2020/03/16 11:46:53, Christofer Dutz
<christofer.d...@c-ware.de> wrote:
> > > > > > Hi Etienne,
> > > > > >
> > > > > > well there must be some way to distinguish the
two ... perhaps using more than one field to discriminate the types?
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > >
> > > > > >
> > > > > > Am 16.03.20, 12:01 schrieb "Etienne Robinet"
<43...@etu.he2b.be>:
> > > > > >
> > > > > > Hi Chris,
> > > > > > I will have a look to build the tests for
the parser/serializer.
> > > > > >
> > > > > > I have another question. In Cip when data
is too large and wont fit into a signle packet (>500 bytes), we use
fragmentedRequest. The problem I'm facing is: ReadFragmentedService and
UnconnectedRequest have the same service number 0x52.
> > > > > > From the structure, the UnconnectedRequest
contains the fragmentedServiceRequest; but the responses are at the same
'level' as the UnconnectedRequest. So I don't know for now how to implement
this and if we even need it (but I still find a good option);
> > > > > >
> > > > > > Etienne
> > > > > > On 2020/03/16 10:35:34, Christofer Dutz
<christofer.d...@c-ware.de> wrote:
> > > > > > > Hi Etienne,
> > > > > > >
> > > > > > > I would also suggest you have a look at
the unit-test framework I built for testing the parsers, serializers and the
model.
> > > > > > >
> > > > > > >
plc4j/drivers/s7/src/test/java/org/apache/plc4x/java/s7/readwrite/S7DriverTestsuite.java
> > > > > > >
plc4j/drivers/s7/src/test/resources/testsuite/S7DriverTestsuite.xml
> > > > > > >
> > > > > > > I'm currently still working on an
integration test-suite that will test the protocol component using pre-defined
messages:
> > > > > > >
> > > > > > >
plc4j/drivers/s7/src/test/java/org/apache/plc4x/java/s7/readwrite/S7ParserSerializerTestsuite.java
> > > > > > >
plc4j/drivers/s7/src/test/resources/testsuite/S7ParserSerializerTestsuite.xml
> > > > > > >
> > > > > > > But I wouldn't call that production ready
yet as I was distracted by other work and have to check where I dropped the
ball last time.
> > > > > > >
> > > > > > > Chris
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Am 16.03.20, 11:28 schrieb "Etienne
Robinet" <43...@etu.he2b.be>:
> > > > > > >
> > > > > > > Hi Chris,
> > > > > > > this did also the trick and looks far
more clean, thanks for the help on that!
> > > > > > >
> > > > > > > I am now working on the writing,
might have a look on connected messages afterwards. The fact is that now I'm
doing home office so it will be a bit trickier to test, but I might get a
solution in the following days.
> > > > > > > Stay safe,
> > > > > > >
> > > > > > > Etienne
> > > > > > > On 2020/03/13 17:09:06, Christofer
Dutz <christofer.d...@c-ware.de> wrote:
> > > > > > > > Hi Etienne,
> > > > > > > >
> > > > > > > > I just took the version before your
last commit and applied the pattern how you pass along the arguments.
> > > > > > > > Please have a look ... I haven't
compiled the spec, but it should work. As you can see, if you want to use the
> > > > > > > > arguments inside a sub-type, you
have to re-declare the variable (identical name and type) in the sub-type.
> > > > > > > >
> > > > > > > >
> > > > > > > > //
> > > > > > > > // Licensed to the Apache Software
Foundation (ASF) under one
> > > > > > > > // or more contributor license
agreements. See the NOTICE file
> > > > > > > > // distributed with this work for
additional information
> > > > > > > > // regarding copyright ownership.
The ASF licenses this file
> > > > > > > > // to you under the Apache
License, Version 2.0 (the
> > > > > > > > // "License"); you may not use
this file except in compliance
> > > > > > > > // with the License. You may
obtain a copy of the License at
> > > > > > > > //
> > > > > > > > //
http://www.apache.org/licenses/LICENSE-2.0
> > > > > > > > //
> > > > > > > > // Unless required by applicable
law or agreed to in writing,
> > > > > > > > // software distributed under the
License is distributed on an
> > > > > > > > // "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY
> > > > > > > > // KIND, either express or
implied. See the License for the
> > > > > > > > // specific language governing
permissions and limitations
> > > > > > > > // under the License.
> > > > > > > > //
> > > > > > > >
> > > > > > > >
//////////////////////////////////////////////////////////////////
> > > > > > > > ///EthernetIP Header of size 24
> > > > > > > >
/////////////////////////////////////////////////////////////////
> > > > > > > >
> > > > > > > > [discriminatedType 'EipPacket'
> > > > > > > > [discriminator uint 16
'command']
> > > > > > > > [implicit uint 16 'len'
'lengthInBytes - 24']
> > > > > > > > [simple uint 32
'sessionHandle']
> > > > > > > > [simple uint 32 'status']
> > > > > > > > [array uint 8
'senderContext' count '8']
> > > > > > > > [simple uint 32
'options']
> > > > > > > > [typeSwitch 'command'
> > > > > > > > ['0x0065'
EipConnectionRequest
> > > > > > > > [const uint 16
'protocolVersion' '0x01']
> > > > > > > > [const uint 16
'flags' '0x00']
> > > > > > > > ]
> > > > > > > > ['0x0066'
EipDisconnectRequest
> > > > > > > > ]
> > > > > > > > ['0x006F' CipRRData
[uint 16 'len']
> > > > > > > > [reserved uint
32 '0x00000000']
> > > > > > > > [reserved uint
16 '0x0000']
> > > > > > > > [simple CipExchange
'exchange' ['len-6']]
> > > > > > > > ]
> > > > > > > > ]
> > > > > > > > ]
> > > > > > > > [type 'CipExchange' [uint 16
'exchangeLen']
> > > > > > > > [const uint 16
'itemCount' '0x0002'] //2 items
> > > > > > > > [const uint 32
'nullPtr' '0x0'] //NullPointerAddress
> > > > > > > > [const uint 16
'UnconnectedData' '0x00B2'] //Connection Manager
> > > > > > > > [implicit uint 16
'size' 'lengthInBytes - 8 - 2'] //remove fields above and
routing
> > > > > > > > [simple CipService
'service' ['exchangeLen - 10'] ]
> > > > > > > > ]
> > > > > > > >
> > > > > > > > [discriminatedType 'CipService'
[uint 16 'serviceLen']
> > > > > > > > [discriminator uint 8
'service']
> > > > > > > > [typeSwitch 'service'
> > > > > > > > ['0x4C' CipReadRequest
> > > > > > > > [simple int 8
'RequestPathSize']
> > > > > > > > [array int 8
'tag' length '(RequestPathSize*2)']
> > > > > > > > [simple uint 16
'elementNb']
> > > > > > > > ]
> > > > > > > > ['0xCC' CipReadResponse
[uint 16 'serviceLen']
> > > > > > > > [reserved uint
8 '0x00']
> > > > > > > > [simple uint
8 'status']
> > > > > > > > [simple uint
8 'extStatus']
> > > > > > > > [enum
CIPDataTypeCode 'dataType']
> > > > > > > > [array int
8 'data' length 'serviceLen-6']
> > > > > > > > ]
> > > > > > > > ['0x0A'
MultipleServiceRequest [uint 16 'serviceLen']
> > > > > > > > [const int 8
'RequestPathSize' '0x02']
> > > > > > > > [const uint 32
'RequestPath' '0x01240220'] //Logical Segment: Class(0x20) 0x02,
Instance(0x24) 01 (Message Router)
> > > > > > > > [simple Services
'data' ['serviceLen - 6 ']]
> > > > > > > > ]
> > > > > > > > ['0x8A'
MultipleServiceResponse [uint 16 'serviceLen']
> > > > > > > > [reserved uint
8 '0x0']
> > > > > > > > [simple uint
8 'status']
> > > > > > > > [simple uint
8 'extStatus']
> > > > > > > > [simple Services
'data' ['serviceLen - 4']]
> > > > > > > > ]
> > > > > > > > ['0x0052'
CipUnconnectedRequest
> > > > > > > > [reserved uint
8 '0x02']
> > > > > > > > [reserved uint
8 '0x20'] // setRequestPathLogicalClassSegment
> > > > > > > > [reserved uint
8 '0x06'] // set request class path
> > > > > > > > [reserved uint
8 '0x24'] // setRequestPathLogicalInstanceSegment
> > > > > > > > [reserved uint
8 '0x01'] // setRequestPathInstance
> > > > > > > > [reserved uint
16 '0x9D05'] //Timeout 5s
> > > > > > > > [implicit uint
16 'messageSize' 'lengthInBytes - 10 - 4'] //substract above and routing
> > > > > > > > [simple
CipService 'service']
> > > > > > > > [const uint
16 'route' '0x0001']
> > > > > > > > [simple int
8 'backPlane']
> > > > > > > > [simple int
8 'slot']
> > > > > > > > ]
> > > > > > > > ]
> > > > > > > > ]
> > > > > > > >
> > > > > > > > [type 'Services' [uint 16
'servicesLen']
> > > > > > > > [simple uint 16 'serviceNb']
> > > > > > > > [array uint 16
'offsets' count 'serviceNb']
> > > > > > > > [array CipService 'services'
count 'serviceNb' ['servicesLen/serviceNb'] ]
> > > > > > > > ]
> > > > > > > >
> > > > > > > > [enum uint 16 'CIPDataTypeCode'
[uint 8 'size']
> > > > > > > > ['0X00C1' BOOL
['1']]
> > > > > > > > ['0X00CA' REAL
['4']]
> > > > > > > > ['0X00C4' DINT
['4']]
> > > > > > > > ['0X00C3' INT
['2']]
> > > > > > > > ['0X00C2' SINT
['1']]
> > > > > > > > ['0X02A0' STRUCTURED
['88']]
> > > > > > > > ['0X02A0' STRING
['88']]
> > > > > > > > ['0X02A0' STRING36
['40']]
> > > > > > > > ['-1' UNKNOWN
['-1']]
> > > > > > > > ]
> > > > > > > >
> > > > > > > >
> > > > > > > > Hope that helps,
> > > > > > > > Chris
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Am 13.03.20, 17:09 schrieb "Etienne
Robinet" <43...@etu.he2b.be>:
> > > > > > > >
> > > > > > > > Hi all,
> > > > > > > > sorry for double-posting, but I
found the fix. For me the code does not look that 'sexy' now but it works. I do
not know if I can make it better but for now I will stick to this :) I pushed
it to the 'eip' branch of my fork.
> > > > > > > > Have a nice weekend,
> > > > > > > >
> > > > > > > > Etienne
> > > > > > > > On 2020/03/13 14:48:35, Etienne
Robinet <43...@etu.he2b.be> wrote:
> > > > > > > > > Hi,
> > > > > > > > > Thanks for the advice. I am
trying to pass the length down the subclasses, but I'm stuck. This does not
work as it seems:
> > > > > > > > >
https://i.imgur.com/77bbdBN.png CipRRData does not know what 'len' is nor its
value as it seems.
> > > > > > > > >
> > > > > > > > > I wanted to inspire mysefl
from the CotpPayload, but unfortunately, the first byte of the whole packet is
a discriminator (command).
> > > > > > > > >
> > > > > > > > > Etienne
> > > > > > > > > On 2020/03/13 13:52:16,
Christofer Dutz <christofer.d...@c-ware.de> wrote:
> > > > > > > > > > Hi Etienne,
> > > > > > > > > >
> > > > > > > > > > I think you can solve your
problem in two ways.
> > > > > > > > > > In all you need to pass
down the length of the packet in total from the root type (which knows the
length).
> > > > > > > > > > 1) You keep on just reading
bytes and parse in the protocol logic class (Like in the S7 driver or KNX)
> > > > > > > > > > 2) You directly parse
PlcValues (using "dataIo" types)
> > > > > > > > > >
> > > > > > > > > > I would prefer option 2 but
1 is simpler. The reason I'm doing 1) in S7 and KNX is that I need to know the
type from the request to decode in the S7 case and in the KNX case I need to
know the type from an external source in order to decode it.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Chris
> > > > > > > > > >
> > > > > > > > > > Am 13.03.20, 14:45 schrieb
"Etienne Robinet" <43...@etu.he2b.be>:
> > > > > > > > > >
> > > > > > > > > > Yes this is exactly
what I need. If I get the remaining bytes, I can know the element numbers as I
have their type!
> > > > > > > > > >
> > > > > > > > > > Etienne
> > > > > > > > > >
> > > > > > > > > > On 2020/03/13 13:40:09,
Julian Feinauer <j.feina...@pragmaticminds.de> wrote:
> > > > > > > > > > > Hey,
> > > > > > > > > > >
> > > > > > > > > > > there ist he
possibility to get the remaining size oft he bytes of the message. Does that
help?
> > > > > > > > > > > Otherwise I misread
your question.
> > > > > > > > > > >
> > > > > > > > > > > Julian
> > > > > > > > > > >
> > > > > > > > > > > Am 13.03.20, 14:37
schrieb "Etienne Robinet" <43...@etu.he2b.be>:
> > > > > > > > > > >
> > > > > > > > > > > Hi Julian,
> > > > > > > > > > > so how should I
declare this field in the mspec if I can not get its size?
> > > > > > > > > > > Thank you,
> > > > > > > > > > >
> > > > > > > > > > > Etienne
> > > > > > > > > > >
> > > > > > > > > > > On 2020/03/13
13:35:52, Julian Feinauer <j.feina...@pragmaticminds.de> wrote:
> > > > > > > > > > > > Hi Etienne,
> > > > > > > > > > > >
> > > > > > > > > > > > first,
Congratulations on your Progress!
> > > > > > > > > > > > To you question:
> > > > > > > > > > > > This is a
common issue with many protocols.
> > > > > > > > > > > > We solve that
in the protocol layer by keeping the request until we get the response (see for
Example how we did it for S7).
> > > > > > > > > > > > So you cannot
solve that in mpsec at compile time but have to decode the byte[] you get with
the Information from the Request.
> > > > > > > > > > > >
> > > > > > > > > > > > Hope that helps!
> > > > > > > > > > > > Julian
> > > > > > > > > > > >
> > > > > > > > > > > > Am 13.03.20,
14:02 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Chris,
> > > > > > > > > > > > I have yet
another question. When sending a request for multiple elements (let's say 10
elements of an array), you get a response from the PLC with all the data at the
end of the packet. The problem is, in the request there is the number of
elements we want, but not in the response. So so the protocol knows how many
elements there are in the response packet, but not the packet itself. This is
quite a problem as for the parse, we need to know the length of the 'data'
array containing the response data (for now it was only depending on the type,
but I would need type*elements).
> > > > > > > > > > > >
> > > > > > > > > > > > I tested a
bit by modifying the generated IO, and 1 way to do it is to get the remaining
bytes and divide this by the datatype size. I just wanted to ask if someone
would know how to declare this in the mspec, as I don't want to touch at the
template. I also thought about having an attribute on the response, but I don't
know how to put an attribute that won't get parsed/serialized. Hope I am clear
enough, but this is a code sample that worked (modifying generated sources):
> > > > > > > > > > > >
https://i.imgur.com/Xm6DxEZ.png (notice the error but this code works if I
write it myself)
> > > > > > > > > > > > And here is
how I put it in the mspec: https://i.imgur.com/Ye1Kl9q.png (you can see the
number of element is not present)
> > > > > > > > > > > >
> > > > > > > > > > > > Any help is
welcome of course! :)
> > > > > > > > > > > > Etienne
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On
2020/03/12 21:34:12, Christofer Dutz <christofer.d...@c-ware.de> wrote:
> > > > > > > > > > > > > Hi
Etienne,
> > > > > > > > > > > > >
> > > > > > > > > > > > > that's
amazing news :-) ... congratulations :-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Also had
a look at your mspec and I think you have done a great job with that. I wasn't
quite sure about the relation between CipRRData and CipExchange, but your
solution looks rock-solid.
> > > > > > > > > > > > >
> > > > > > > > > > > > > And now
reading that you even managed to get something working, that makes me very
happy.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Tomorrow
I'll be a little consumed with signing the contract with the KNX foundation but
I'll try to have a look at your fork.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks
for your great work :)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Chris
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Am
12.03.20, 17:50 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi
all,
> > > > > > > > > > > > > again
a productive day, I pushed to my branch and the driver support reading,
multiple reading and the camel component works (in karaf) and takes a List of
strings. Tested it on a different PLC and it also worked! Next I'm going to
implement the array readings and then maybe writing (tests needs to be done
too).
> > > > > > > > > > > > >
> > > > > > > > > > > > >
Etienne
> > > > > > > > > > > > >
> > > > > > > > > > > > > On
2020/03/12 07:18:32, Etienne Robinet <43...@etu.he2b.be> wrote:
> > > > > > > > > > > > > > Hi
Chris,
> > > > > > > > > > > > > > yes
that's what I thought so I managed to work around like this:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
https://github.com/etiennerobinet/plc4x/blob/eip/protocols/eip/src/main/resources/protocols/eip/eip.mspec
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > And
this works for reading! I managed to make a quick test and read via the tag
name. Now my question is: can I create sub-types that are also discriminated
with sub-subtypes? That would allow to create the ReadRequest only, as the
fields before are mainly constant/implicit.
> > > > > > > > > > > > > >
Etienne
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On
2020/03/11 20:24:14, Christofer Dutz <christofer.d...@c-ware.de> wrote:
> > > > > > > > > > > > > > >
Hi Etienne,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
you are defining the type CipRRData twice ... once as one of the sub-types of
EipPacket and once as a dedicated discriminated type.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
Chris
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
PS: I have no idea why I didn't finish writing this email and I just noticed
when closing everything down ... sorry for the late reply.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
Am 11.03.20, 09:30 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
Hi all,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
I have a quick question. I've been working on the CIP encapsulation but
hitting a problem with the mspec design. Here is the error I am facing:
https://i.imgur.com/iCfh59n.png
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
The problem here is that this CipRRData should also be of type EipPacket.
When the command of an EipPacket is '0x66' this means SendRRData (for
Read/Write and Request/Response so I have to discriminate it on the sub level).
The problem is that after generation, CipRRData implements Message but does not
extend EipPacket. How should I do it? Here is the mspec:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
[discriminatedType 'EipPacket'
> > > > > > > > > > > > > > >
[discriminator uint 16 'command']
> > > > > > > > > > > > > > >
[implicit uint 16 'len' 'lengthInBytes - 24']
> > > > > > > > > > > > > > >
[simple uint 32 'sessionHandle']
> > > > > > > > > > > > > > >
[simple uint 32 'status']
> > > > > > > > > > > > > > >
[array uint 8 'senderContext' count '8']
> > > > > > > > > > > > > > >
[simple uint 32 'options']
> > > > > > > > > > > > > > >
[typeSwitch 'command'
> > > > > > > > > > > > > > >
['0x0065' EipConnectionRequest
> > > > > > > > > > > > > > >
[const uint 16 'protocolVersion' '0x01']
> > > > > > > > > > > > > > >
[const uint 16 'flags' '0x00']
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
['0x0066' EipDisconnectRequest
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
['0x006F' CipRRData
> > > > > > > > > > > > > > >
[const uint 32 'EipInterface' '0x00000000']
> > > > > > > > > > > > > > >
[const uint 8 'timeout' '0x0000']
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
[discriminatedType 'CipRRData'
> > > > > > > > > > > > > > >
[simple uint 8 'itemNb']
> > > > > > > > > > > > > > >
[array CipItem 'items' length 'itemNb']
> > > > > > > > > > > > > > >
[discriminator uint 8 'CipService']
> > > > > > > > > > > > > > >
[typeSwitch 'CipService'
> > > > > > > > > > > > > > >
['0x52' CipUnconnectedRequest
> > > > > > > > > > > > > > >
[simple CommandData 'data']
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
['0xCC' CipReadResponse
> > > > > > > > > > > > > > >
[reserved uint 8 '0x0000']
> > > > > > > > > > > > > > >
[simple uint 8 'status']
> > > > > > > > > > > > > > >
[simple uint 8 'extStatus']
> > > > > > > > > > > > > > >
[simple uint 8 'dataType']
> > > > > > > > > > > > > > >
[array uint 8 'data' length 'dataType']
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
[type 'CipItem'
> > > > > > > > > > > > > > >
[simple uint 16 'typeID']
> > > > > > > > > > > > > > >
[simple uint 16 'size']
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
[discriminatedType 'CommandData'
> > > > > > > > > > > > > > >
[reserved uint 8 '0x02']
> > > > > > > > > > > > > > >
[reserved uint 8 '0x20'] //
setRequestPathLogicalClassSegment
> > > > > > > > > > > > > > >
[reserved uint 8 '0x06'] // set request class path
> > > > > > > > > > > > > > >
[reserved uint 8 '0x24'] //
setRequestPathLogicalInstanceSegment
> > > > > > > > > > > > > > >
[reserved uint 8 '0x01'] // setRequestPathInstance
> > > > > > > > > > > > > > >
[discriminator uint 8 'CipService']
> > > > > > > > > > > > > > >
[typeSwitch 'CipService'
> > > > > > > > > > > > > > >
['0x4C' CipReadRequest
> > > > > > > > > > > > > > >
[simple uint 8 'RequestPathSize']
> > > > > > > > > > > > > > >
[reserved uint 8 '0x91']
> > > > > > > > > > > > > > >
[array uint 8 'tag' length '(RequestPathSize*2) - 1']
> > > > > > > > > > > > > > >
[reserved uint 16 '0x0001'] //itemCount set to 1 for now
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
[enum int 16 'CIPDataTypeCode' [uint 8 'size']
> > > > > > > > > > > > > > >
['0X00C1' BOOL ['1']]
> > > > > > > > > > > > > > >
['0X00CA' REAL ['4']]
> > > > > > > > > > > > > > >
['0X00C4' DINT ['4']]
> > > > > > > > > > > > > > >
['0X00C3' INT ['2']]
> > > > > > > > > > > > > > >
['0X00C2' SINT ['1']]
> > > > > > > > > > > > > > >
['0X02A0' STRUCTURED ['88']]
> > > > > > > > > > > > > > >
['0X02A0' STRING ['88']]
> > > > > > > > > > > > > > >
['0X02A0' STRING36 ['40']]
> > > > > > > > > > > > > > >
['-1' UNKNOWN ['-1']]
> > > > > > > > > > > > > > >
]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
Thanks for any help!
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
Etienne
> > > > > > > > > > > > > > >
On 2020/03/10 15:18:47, Etienne Robinet <43...@etu.he2b.be> wrote:
> > > > > > > > > > > > > > >
> Hi all,
> > > > > > > > > > > > > > >
> I've managed to implement the EIP Session Register/Unregister (used for
connected message which is best for high frequency fetching). I will push it to
my branch and create a document explaining my steps.
> > > > > > > > > > > > > > >
> Next I want to do was to to the CIP encapsulation part for accessing tag by
their name. The thing is, CIP is (from what I heard) proper to Allen Bradley.
Should I leave it in the EIP driver or modify and adapt the current AB driver
later on? For now I will continue on eip.
> > > > > > > > > > > > > > >
>
> > > > > > > > > > > > > > >
> Etienne
> > > > > > > > > > > > > > >
>
> > > > > > > > > > > > > > >
> On 2020/03/10 14:41:42, Cesar Garcia <cesar.gar...@ceos.com.ve> wrote:
> > > > > > > > > > > > > > >
> > Hi,
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > You can document the process step by step, you will surely find
observation
> > > > > > > > > > > > > > >
> > points.
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > I am working with the handwritten S7 driver, but in the future I would
> > > > > > > > > > > > > > >
> > support the team in migrate to mspec, so the experience you will gain with
> > > > > > > > > > > > > > >
> > the Etheret / IP is very important.
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > Best regards,
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > El mar., 10 mar. 2020 a las 9:17, Christofer Dutz (<
> > > > > > > > > > > > > > >
> > christofer.d...@c-ware.de>) escribió:
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > > Hi Etienne,
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > > I would strongly suggest you install the Antlr plugn for the IDE you
use.
> > > > > > > > > > > > > > >
> > > The problem is that ANTLR seems to gobble up a lot of errors and tries
to
> > > > > > > > > > > > > > >
> > > be smart in a lot of cases.
> > > > > > > > > > > > > > >
> > > Whenever I have problems like this I use the ANTLR visual parser to
parse
> > > > > > > > > > > > > > >
> > > a block of mspec (one type at a time) and try to narrow down the cause.
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > > Chris
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > > Am 10.03.20, 13:31 schrieb "Etienne Robinet" <43...@etu.he2b.be>:
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > > Hi all,
> > > > > > > > > > > > > > >
> > > I've been struggling with implementing the EIP driver. I started
> > > > > > > > > > > > > > >
> > > writing the mspec after creating both a module for the protocol and the
one
> > > > > > > > > > > > > > >
> > > from the driver. I copied and adapted the pom(s) from the AB-ETH but
only
> > > > > > > > > > > > > > >
> > > the enum is generated.
> > > > > > > > > > > > > > >
> > > Here is a link to the forked branch:
> > > > > > > > > > > > > > >
> > > https://github.com/etiennerobinet/plc4x/tree/eip
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > > I've been studying the EIP/CIP protocol and now I am confident what
> > > > > > > > > > > > > > >
> > > the packages should contain but I can not figure out how to generate
this
> > > > > > > > > > > > > > >
> > > with the templates. Am I missing something?
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > > Etienne
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> > >
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > --
> > > > > > > > > > > > > > >
> > *CEOS Automatización, C.A.*
> > > > > > > > > > > > > > >
> > *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
> > > > > > > > > > > > > > >
> > *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
> > > > > > > > > > > > > > >
> > *Ing. César García*
> > > > > > > > > > > > > > >
> > *Cel: 0416-681.03.99*
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > *Cel: 0414-760.98.95*
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > *Hotline Técnica SIEMENS: 0800 1005080*
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
> > *Email: support.aan.automat...@siemens.com
> > > > > > > > > > > > > > >
> > <support.aan.automat...@siemens.com>*
> > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > >
>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>
>
