Hi Chris, 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).
Sebastian > 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? > > 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 > > >
