Hi All,
first off all, thanks for your work on the Beckhoff protocol. I don't think
that moving the encode/decode code into an abstract base class. However moving
them into a utility sounds more like an idea. I think with "prefix them with
endianness" you would mean something like one class "LeTypeEncoder" and
"BeTypeEncoder"? But I don't know if all PLCs encode their data the same way. I
would expect them not to, just to ensure they stay incompatible with others in
a maximal way __ But I guess there's no harm in moving the ode to an external
utility. We can always refactor things if we find out all others do it
differently than S7.
Advertising
S7 is Big Endian, as far as I remember, so your Little Endian would already be
a second implementation. Perhaps moving it into a dedicated Encoder component,
but leaving it alongside the driver for now, would be an option and to move it
to a more general location as soon as we need to share would be a better option.
What do you think?
Chris
Am 17.02.18, 11:24 schrieb "Sebastian Rühl"
<sebastian.ruehl...@googlemail.com>:
Hi,
Small update on this:
Writing data is still the SerializationUtils mockup but here is something
written how they transport data in ADS:
https://infosys.beckhoff.com/content/1033/tcsample_java/html/note.htm?id=8051365067801678853
<https://infosys.beckhoff.com/content/1033/tcsample_java/html/note.htm?id=8051365067801678853>
@Chris: Maybe we should move the encode/decode methods from Plc4XS7Protocol
to an Util/Abstract MessageToMessageCodec class, prefix them with endianness so
I can reuse them in my ADS Implementation. As far as I can see ADS uses also LE
for numeric values of the payload. What do you think (cc: @all)?.
I done the hamcrest migration so we good on this side and also did I work
through most of the issues in Sonar.
Sebastian
> Am 16.02.2018 um 19:11 schrieb Sebastian Rühl
<sebastian.ruehl...@googlemail.com>:
>
> Hi together,
>
> The last weeks I worked on the implementation of the Beckhoff Information
System TwinCAT ADS/AMS TCP protocol (The specification for this can be found
here:
https://infosys.beckhoff.com/english.php?content=../content/1033/tcadsamsspec/html/tcadsamsspec_intro.htm
<https://infosys.beckhoff.com/english.php?content=../content/1033/tcadsamsspec/html/tcadsamsspec_intro.htm>).
> This implementation reached finally a state where it was time to be
merged into master.
> Next steps (in my personal backlog but feel free ;) in developing this
further would be to work with some practical implementations as in the current
state it just uses java serialization to write binary data. In the linked
specification (eg.
https://infosys.beckhoff.com/content/1033/tcadsamsspec/html/tcadsamsspec_adscmd_write.htm?id=996851960799097164
<https://infosys.beckhoff.com/content/1033/tcadsamsspec/html/tcadsamsspec_adscmd_write.htm?id=996851960799097164>)
is nothing written what this data could be so there is currently no
serialization done like in the s7 protocol implementation. Another todo would
be to update the index.adoc as in its current state its just copy&paste from
s7. Moving to Hamcrest and improving the tests is another point.
> As always im trying to polish this the next weeks with some improvements.
>
> Sebastian
