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" <[email protected]>:

    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" <[email protected]>:
    
        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" 
<[email protected]>:
        
            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
            
            
        
        
    
    

Reply via email to