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