Hi, I definitely think that all the drivers should be returning the same format as each other for each data type, I think that is more important than the format they are returned in.
However, generally from what I have seen BYTE, WORD, etc... datatypes get returned as basically unsigned integer or byteish types, then it is up to the user to represent that however they wish. If I write one byte I would expect when reading it, using the same data type, it would return 1 byte not an array of 8 bits. IEC 61131-3 v2 2003 has a few references in there about how they should be handled. It would be interesting to get a hold of the 2013 revision though. This shows that they should be handled as integer values > 1.3.43 integer literal: literal which directly represents a value of > type SINT, INT, DINT, LINT, BOOL, BYTE, WORD, DWORD, or LWORD, as defined > in 2.3.1. > This then mentions they should be handled as bit string > 17 BYTE Bit string of length 8 8 j,g A bit string the gets defined as > 1.3.11 bit string: data element consisting of one or more bits. All a bit vague. For OPCUA, when writing values to a server (Assuming BYTE types, and binary encoding) they should be writing them in groups of 8 bits with the length specifier indicating the number of groups of 8 bits, not the number of bits. At the moment when reading them they get returned as java byte values. Ben On Sun, Feb 6, 2022 at 4:40 AM Christofer Dutz <[email protected]> wrote: > Hi all, > > while working on the tests for the Proxy protocol, I stumbled in some pits > regarding the encoding of the BitString values. > > So, the IEC61131ValueHandler didn't utilize the BitString PlcValue types, > but use the PlcBYTE, which is generally identical to PlcUSINT. > I know some drivers correctly used the bit strings for the IEC types (as > the IEC spec describes them) ... after fixing this I noticed some other > drivers going red (Modbus, OPC-UA, ...) > I fixed the issue in the Modbus test-suite as this was not 100% correct, > but with OPC-UA I'm a bit unsure (However it does use the > IEC61131ValueHandler too) ... I am not sure if here the same naming > convention is expected as here, I can see this: > > case "BYTE": > case "BITARR8": > case "USINT": > case "UINT8": > case "BIT8": > List<Short> tmpBYTE = new ArrayList<>(length); > for (int i = 0; i < length; i++) { > tmpBYTE.add((short) valueObject.getIndex(i).getByte()); > } > > If you ask me, BYTE and BITARR8 should be BitStrings too (Especially > BITARR8 ... and obviously also the 16, 32 and 64 bit versions) > > Would it be ok to streamline this throughout our drivers? > > Chris >
