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

Reply via email to