You are right, lets do it that way. I missed that S7 is Big Endian so I will
move it to a Util class in ADS and then we might move it to the driver base
once we know we can reuse it (same for S7).
> Am 19.02.2018 um 10:37 schrieb Christofer Dutz <christofer.d...@c-ware.de>:
> 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.
> 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?
> Am 17.02.18, 11:24 schrieb "Sebastian Rühl"
> Small update on this:
> Writing data is still the SerializationUtils mockup but here is something
> written how they transport data in ADS:
> @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.
>> Am 16.02.2018 um 19:11 schrieb Sebastian Rühl
>> 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
>> 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.
>> 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
>> As always im trying to polish this the next weeks with some improvements.