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