Bit-Addresses
Currently we're handling bit data inside byte or word alligned data by reading from the end of the byte/word.
So in general: 1 = b00000001 = true and 0 = b00000000 = false.
However this works fine till we reach 8 or 16 bits, that we want to read. However how is the data interpreted, if we read 9 oor 17 bits?
Will we be reading:
- 0000000X XXXXXXXX?
- XXXXXXXX X0000000?
- XXXXXXXX 0000000X?
We should clearly define this.
I personally would be in favor of starting with the most significant bit and then adding more to the right.
In this case:
- BOOL[1]: X0000000
- BOOL[2]: XX000000
- BOOL[6]: XXXXXX00
- BOOL[9]: XXXXXXXX X0000000
In order to be able to address different bits, we should add a bit-offset similar to S7:
- 50000:BOOL: X000000000000000
- 50000:BOOL[5]: XXXXX00000000000
- 50000.0:BOOL[5]: XXXXX00000000000
- 50000.3:BOOL[5]: 000XXXXX00000000
- 50000.14:BOOL[5]: 000000000000000000XX XXX0000000000000
Handling BYTE, WORD, DWORD, LWORD Datatypes
In IEC61131-3 (https://en.wikipedia.org/wiki/IEC_61131-3) BYTE, WORD, DWORD and LWORD are defined as Bit-Strings.
However, in PLC4X we some-times treat BYTE as a numeric value. I think this is a problem, as in this case it is not defined if this a signed or unsigned and this generally can vary between programming languages. In Java a "byte" is a signed 8 bit integer, in Go and C it is an unsigned integer.
In mspec we introduced a field type "byte" to simplify passing along of raw data (like the content of a file). Some protocols also have this concept of raw data.
I would therefore propose to strictly handle BYTE, WORD, DWORD and LWORD as bit strings and to introduce a new type "RAW".
A PlcRAW would ideally default to a byte[] as it is defined in the corresponding programming language. So in java it would be an array of signed 8 bit integers and in Go it would be one of unsigned 8 bit integers.
The BYTE, WORD, DWORD and LWORD PlcValues should throw errors when trying to use them to write or read numeric values. The error message should mention the matching numeric types.
The error message could be something like:
"Exception trying to access bit-string field of type BYTE numerically. Please use USINT (unsigned 8 bit integer) or SINT (signed 8 bit integer) instead."