And I just stumbled over something related to this: If we have a dataIo case of type "List", then we currently can't control the type of the individual elements. Currently the code uses the default PlcValue type defined for a given "uint 8" or "float 32" type. But this might not be what we want.
So possibly switching from using "List" to the desired datatype and then to simply check if the field providing the "value" element is a "simple" or "array" field in order to decice if a PlcList or PlcXYZ should be used. Chris -----Original Message----- From: Christofer Dutz <christofer.d...@c-ware.de> Sent: Sonntag, 29. Mai 2022 17:01 To: dev@plc4x.apache.org Subject: RE: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ... And I guess we would also have to discuss what's going to be the default behaviour when reading something like: BYTE[3] ... will this be 3 lists of each 8 bits, one list of 24 bits, or a list of 3 signed/unsigned values. Chris -----Original Message----- From: Christofer Dutz <christofer.d...@c-ware.de> Sent: Sonntag, 29. Mai 2022 16:48 To: dev@plc4x.apache.org Subject: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ... Hi all, today again I'm wasting lots of time trying to align the way we are handling bit strings :-( According to IEC61131 the types: BYTE, WORD, DWORD and LWORD are bit strings ... therefore series of bits. However, many people treat BYTE as a numeric value. That's actually what USINT (Unsigned small int) and SINT (small int) are for. BYTE doesn't specify if signed or unsigned. In Java for example it would be signed, in go and C it would be unsigned. Now we did extend the BYTE, WORD, DWORD and LWORD with a getBooleanArray() method, however this doesn't really work nicely, as it's not part of the API and you explicitly have to cast it to PlcBYTE etc. in order to use it. And a PlcBYTE is not a list type. In parallel I did have the PlcBitString type, which was a List type and correctly handled the bit-stringyness. So, I would like to discuss with you all, how we are going to deal with these in the future and then do a VOTE on that and stick with it. My opinion is, that BYTE, WORD, DWORD and LWORD should be bit-strings and hereby Lists of Boolean values. If someone wants to read the numeric values on the PlcValues by using the getXYZ methods, they should fire exceptions telling the user that this is a BitString and if he wants to use a numeric value, he should use the numeric counterpart (and tell him which options there are: Like USINT for unsigned 8 bit, SINT for 8 bit signed instead of BYTE, ...). This mixing up of types is making it a nightmare to consistently maintain over multiple languages. What's your opinion on this? Chris