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
