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/05/29 14:48:01 UTC
[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
Re: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ...
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Cesar,
Thanks for that input. I'll try digging through it.
But I think we have to distinguish between the datatypes on the plc and the datatypes in the plc4x api.
Is live to use pure iec61131 for the communication between the api and the user application. The drivers than should take care of the "reality mapping"
But that's just my opinion, that is love to hear more thoughts on.
I'd hate to have BYTE in one driver to deliver something else than with an other driver.
Chris
Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>
________________________________
From: Cesar Garcia <ce...@ceos.com.ve>
Sent: Sunday, May 29, 2022 10:51:46 PM
To: Apache PLC4X <de...@plc4x.apache.org>
Subject: Re: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ...
Hello Chris,
The application of IEC61131-3 for PLC manufacturers has always been a
history of "what I have and do not want to change" with respect to "what
should be".
The best example is my dear Simatic, which Siemens says complies with
IEC61131-3 [1], but when you go to reality it doesn't look anything like
it. that's why there are brave hearts like Oscat function libraries [2]
that try to even things out, but that's another story.
We should follow a bit the new neighbors in the neighborhood, like PLCNext
[3], and indicate our degree of compatibility.
My proposal for this case would be to ensure that our libraries are at
least compatible with the recommendations of IEC61131-3-2013, shown in*
"Figure 11 – Data type conversion rules – implicit and/or explicit
(Summary)"*.
For example, implement an abstract object type PlcValue, which already
implements the conversion on the received buffer from the PLC and which
triggers an exception if the conversion cannot be carried out. In the case
of Netty's ByteBuf [4] it does this transparently.
With this we can give the users of the libraries, the implicit and implicit
conversion in a transparent way.
My grain of sand
[1]
https://cache.industry.siemens.com/dl/files/748/109476748/att_845621/v1/IEC_61131_compliance_en_US.pdf
[2] http://www.oscat.de/
[3] https://www.plcnext.help/te/PLCnext_RuntimeAvailable_data_types.htm
[4] https://netty.io/4.1/api/io/netty/buffer/ByteBuf.html
El dom, 29 may 2022 a las 10:48, Christofer Dutz (<ch...@c-ware.de>)
escribió:
> 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
>
>
--
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*
*Cel: +58 414-760.98.95*
*Hotline Técnica SIEMENS: 0800 1005080*
*Email: support.aan.automation@siemens.com
<su...@siemens.com>*
Re: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ...
Posted by Cesar Garcia <ce...@ceos.com.ve>.
Hello Chris,
The application of IEC61131-3 for PLC manufacturers has always been a
history of "what I have and do not want to change" with respect to "what
should be".
The best example is my dear Simatic, which Siemens says complies with
IEC61131-3 [1], but when you go to reality it doesn't look anything like
it. that's why there are brave hearts like Oscat function libraries [2]
that try to even things out, but that's another story.
We should follow a bit the new neighbors in the neighborhood, like PLCNext
[3], and indicate our degree of compatibility.
My proposal for this case would be to ensure that our libraries are at
least compatible with the recommendations of IEC61131-3-2013, shown in*
"Figure 11 – Data type conversion rules – implicit and/or explicit
(Summary)"*.
For example, implement an abstract object type PlcValue, which already
implements the conversion on the received buffer from the PLC and which
triggers an exception if the conversion cannot be carried out. In the case
of Netty's ByteBuf [4] it does this transparently.
With this we can give the users of the libraries, the implicit and implicit
conversion in a transparent way.
My grain of sand
[1]
https://cache.industry.siemens.com/dl/files/748/109476748/att_845621/v1/IEC_61131_compliance_en_US.pdf
[2] http://www.oscat.de/
[3] https://www.plcnext.help/te/PLCnext_RuntimeAvailable_data_types.htm
[4] https://netty.io/4.1/api/io/netty/buffer/ByteBuf.html
El dom, 29 may 2022 a las 10:48, Christofer Dutz (<ch...@c-ware.de>)
escribió:
> 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
>
>
--
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*
*Cel: +58 414-760.98.95*
*Hotline Técnica SIEMENS: 0800 1005080*
*Email: support.aan.automation@siemens.com
<su...@siemens.com>*
RE: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ...
Posted by Christofer Dutz <ch...@c-ware.de>.
I wrote down all the bit, byte etc. related stuff here:
https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields
As I saw that in Can and KNX there are some types where byte is used for transporting raw data, I would propose to add a new type: "RAW" which is then implemented to use the programming language's default byte interpretation.
Chris
-----Original Message-----
From: Christofer Dutz <ch...@c-ware.de>
Sent: Sonntag, 29. Mai 2022 17:56
To: dev@plc4x.apache.org
Subject: RE: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ...
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 <ch...@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 <ch...@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
RE: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ...
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ch...@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 <ch...@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
RE: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ...
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ch...@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