You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2022/02/05 18:39:54 UTC
Inconsistencies with the BitString types BYTE, WORD, DWORD and LWORD
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
Re: Inconsistencies with the BitString types BYTE, WORD, DWORD and LWORD
Posted by Christofer Dutz <ch...@c-ware.de>.
Well with BYTE,
I really think we should use it as bit string and not as an alias for USINT. Cause quite often you want to for example read all digital inputs at once... Then reading a BYTE from %I results in exactly what it is: a list of boolean values that represent the digital inputs.
Is it's a numeric value the user has to manually convert it.
However I would add exceptions to the getShort etc, that suggest using USINT or SINT instead for numeric values.
I'll commit my changes into a branch and we can go through it together.
I think handling things consistently throughout all drivers, as that's the promise plc4x gives users.
Chris
Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>
________________________________
From: Ben Hutcheson <be...@gmail.com>
Sent: Saturday, February 5, 2022 11:04:09 PM
To: dev@plc4x.apache.org <de...@plc4x.apache.org>
Subject: Re: Inconsistencies with the BitString types BYTE, WORD, DWORD and LWORD
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 <ch...@c-ware.de>
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
>
Re: Inconsistencies with the BitString types BYTE, WORD, DWORD and LWORD
Posted by Ben Hutcheson <be...@gmail.com>.
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 <ch...@c-ware.de>
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
>