You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2018/09/04 09:21:50 UTC

[S7] Handling Bit-Strings

Hi all,

as I found out the differences of the different S7 types, i am currently implementing the parsing and serialization of these types.
Now there are 3 types of 1-byte values:

  *   BYTE
  *   SINT
  *   CHAR

At a first glance it seems strange that Siemens defined these, but it turned out that:

  *   BYTE = Bit string of 8 Boolean values
  *   SINT = 1 byte integer number
  *   CHAR = 1 character String

So now I’m thinking of how BYTE, WORD, DWORD and LWORD should be handled.

For the Integer and FloatingPointFieldItems I implemented getBoolean to return true, if the value is not 0.
However for the byte-strings it would make more sense to instead return more Boolean items, so reading 2 bytes for example would return 16 boolean values.

What are your thoughts on this matter?

Chris

Re: [S7] Handling Bit-Strings

Posted by Julian Feinauer <j....@pragmaticminds.de>.

Hi Chris,

sorry for the confusion. Yes, this is what you did (I somehow missed that).
And my naming is incorrect I mean "Array" not struct (which would be array, map, ...).
So my proposal is to go a bit further than what you do with getByte but to replace it with getField which again is a PlcField so we can support arrays of any types.

In my proposal I did not write about this struct stuff (as I thought this is what you do) but I note the "equivalent java class" for Byte as byte[8] and so on, this is what I meant.

It's getting more and more confusing...

Julian

Am 04.09.18, 11:37 schrieb "Christofer Dutz" <ch...@c-ware.de>:

    Hi Julian,
    
    isn't this exactly what I did?
    
    plcField.getNumValues(): int
    plcField.getByte(index: int): byte
    
    I couldn't see any reference to "struct" in your proposal.
    
    Maybe I am misunderstanding your "struct" as for me a "struct" is sort of like in C giving a structure to a byte array and interpreting some parts as byteX and the following as floatY and so on.
    If you are referring to this, I still think this should be implemented on top of PLC4X (JPA4PLC4X __)
    
    Chris
    
    
    Am 04.09.18, 11:30 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
    
        Hi Chris,
        
        in my inofficial documentation [1] I propose the internal representation to be byte[] (which I would return with get()).
        So for me all other getters should do "nothing".
        
        For me the "right" solution would be to implement "struct" types but I would do this after we finished your current round of refactoring.
        
        "Struct Types" would mean that the PlcField gets more methods, e.g.,
        
        PlcField.isArrayt() : Boolean
        PlcField.getArraySize(): int
        PlcField.getArrayItem(i): PlcField
        
        What do you think?
        
        Julian
        
        [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89070222
        
        Am 04.09.18, 11:22 schrieb "Christofer Dutz" <ch...@c-ware.de>:
        
            Hi all,
            
            as I found out the differences of the different S7 types, i am currently implementing the parsing and serialization of these types.
            Now there are 3 types of 1-byte values:
            
              *   BYTE
              *   SINT
              *   CHAR
            
            At a first glance it seems strange that Siemens defined these, but it turned out that:
            
              *   BYTE = Bit string of 8 Boolean values
              *   SINT = 1 byte integer number
              *   CHAR = 1 character String
            
            So now I’m thinking of how BYTE, WORD, DWORD and LWORD should be handled.
            
            For the Integer and FloatingPointFieldItems I implemented getBoolean to return true, if the value is not 0.
            However for the byte-strings it would make more sense to instead return more Boolean items, so reading 2 bytes for example would return 16 boolean values.
            
            What are your thoughts on this matter?
            
            Chris

Re: [S7] Handling Bit-Strings

Posted by Christofer Dutz <ch...@c-ware.de>.

Hi Julian,

isn't this exactly what I did?

plcField.getNumValues(): int
plcField.getByte(index: int): byte

I couldn't see any reference to "struct" in your proposal.

Maybe I am misunderstanding your "struct" as for me a "struct" is sort of like in C giving a structure to a byte array and interpreting some parts as byteX and the following as floatY and so on.
If you are referring to this, I still think this should be implemented on top of PLC4X (JPA4PLC4X __)

Chris


Am 04.09.18, 11:30 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:

    Hi Chris,
    
    in my inofficial documentation [1] I propose the internal representation to be byte[] (which I would return with get()).
    So for me all other getters should do "nothing".
    
    For me the "right" solution would be to implement "struct" types but I would do this after we finished your current round of refactoring.
    
    "Struct Types" would mean that the PlcField gets more methods, e.g.,
    
    PlcField.isArrayt() : Boolean
    PlcField.getArraySize(): int
    PlcField.getArrayItem(i): PlcField
    
    What do you think?
    
    Julian
    
    [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89070222
    
    Am 04.09.18, 11:22 schrieb "Christofer Dutz" <ch...@c-ware.de>:
    
        Hi all,
        
        as I found out the differences of the different S7 types, i am currently implementing the parsing and serialization of these types.
        Now there are 3 types of 1-byte values:
        
          *   BYTE
          *   SINT
          *   CHAR
        
        At a first glance it seems strange that Siemens defined these, but it turned out that:
        
          *   BYTE = Bit string of 8 Boolean values
          *   SINT = 1 byte integer number
          *   CHAR = 1 character String
        
        So now I’m thinking of how BYTE, WORD, DWORD and LWORD should be handled.
        
        For the Integer and FloatingPointFieldItems I implemented getBoolean to return true, if the value is not 0.
        However for the byte-strings it would make more sense to instead return more Boolean items, so reading 2 bytes for example would return 16 boolean values.
        
        What are your thoughts on this matter?
        
        Chris

Re: [S7] Handling Bit-Strings

Posted by Julian Feinauer <j....@pragmaticminds.de>.

Hi Chris,

in my inofficial documentation [1] I propose the internal representation to be byte[] (which I would return with get()).
So for me all other getters should do "nothing".

For me the "right" solution would be to implement "struct" types but I would do this after we finished your current round of refactoring.

"Struct Types" would mean that the PlcField gets more methods, e.g.,

PlcField.isArrayt() : Boolean
PlcField.getArraySize(): int
PlcField.getArrayItem(i): PlcField

What do you think?

Julian

[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89070222

Am 04.09.18, 11:22 schrieb "Christofer Dutz" <ch...@c-ware.de>:

    Hi all,
    
    as I found out the differences of the different S7 types, i am currently implementing the parsing and serialization of these types.
    Now there are 3 types of 1-byte values:
    
      *   BYTE
      *   SINT
      *   CHAR
    
    At a first glance it seems strange that Siemens defined these, but it turned out that:
    
      *   BYTE = Bit string of 8 Boolean values
      *   SINT = 1 byte integer number
      *   CHAR = 1 character String
    
    So now I’m thinking of how BYTE, WORD, DWORD and LWORD should be handled.
    
    For the Integer and FloatingPointFieldItems I implemented getBoolean to return true, if the value is not 0.
    However for the byte-strings it would make more sense to instead return more Boolean items, so reading 2 bytes for example would return 16 boolean values.
    
    What are your thoughts on this matter?
    
    Chris