[jira] [Created] (PLC4X-343) Issue with Modbus Write -- PLC Connection Exception: Error Creating Channel
Maximilian created PLC4X-343:
Summary: Issue with Modbus Write -- PLC Connection Exception:
Error Creating Channel
Key: PLC4X-343
URL: https://issues.apache.org/jira/browse/PLC4X-343
Project: Apache PLC4X
Issue Type: Bug
Components: Driver-Modbus
Affects Versions: 0.9.1
Reporter: Maximilian
Attachments: image-2022-05-30-13-31-56-320.png, mb1.png, mb2.png,
mb3.png
Hi!
Thanks for supporting this library.
I'd like to seek your advice on an issue I'm having surrounding *writing* to
Modbus registers.
I have a code snippet as follows:
!image-2022-05-30-13-31-56-320.png!
I'm able to make about ~100 requests successfully, until I encounter a{{{} PLC
Connection Exception: Error creating channel error{}}}. This is consistent with
multiple tries.
I've tried using {{CachedDriverManagers }}/ {{{}PooledDriverManagers{}}}, but
this will result in a NullPointerException when I tried to use its
{{PlcConnection }}object to create a {{{}PlcWriteRequest.Builder{}}}.
Essentially, the "builder" object is null:
!mb2.png!
However, I'm able to create {{PlcReadRequest }}builders for reading data; no
{{{}NullPointerExceptions{}}}:
This is how I'm creating the {{{}CachedDriverManager{}}}:
!mb3.png!
I've noticed that I will never encounter a maximum buffer limit reached for
connections created from the {{{}CachedDriverManager{}}}, used to make Modbus
read requests. Hence, I considered using connections created from the
CachedDriverManger to make Modbus write requests, {*}however I get a
NullPointerException for the "builder"{*}.
Hope you could help point me in the right direction, been stuck at this for a
couple of days.
Thanks!
Regards,
Max
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
Re: Subscription Simulation
Andy, I'm not sure if you're aware but there is a scraper https://plc4x.apache.org/users/tools/scraper.html which you can use to continuously poll data even when the driver doesn't support subscriptions. On Mon, May 30, 2022 at 7:42 AM Łukasz Dywicki wrote: > The simulation of subscriptions require probably more options than just > "event" or so. You probably need to configure higher frequency for > polling and ideally manage thread pool for that independently from > netty/connection itself to have control over its reliability. > > If I could have one suggestion.. try making it via decoration of > connection/driver. It gives you most of the flexibility without going to > close with driver. > > I made some decorator support earlier. Base structure is here: > > https://github.com/ConnectorIO/connectorio-addons/tree/master/bundles/org.connectorio.plc4x.decorator/src/main/java/org/connectorio/plc4x/decorator > example of "retry" logic for connection read/write/subscribe: > > https://github.com/ConnectorIO/connectorio-addons/blob/master/bundles/org.connectorio.plc4x.decorator.retry/src/main/java/org/connectorio/plc4x/decorator/retry/RetryDecorator.java > > If you find it useful for your thing we can move it into develop and > maintain together. > > Best, > Łukasz > > > On 29.05.2022 23:34, Andy Grebe wrote: > > hmmm... I should probably push those CIP changes first :) > > > > On Wed, May 25, 2022 at 10:14 AM Christofer Dutz < > christofer.d...@c-ware.de> > > wrote: > > > >> Hi Andy, > >> > >> It still is our plan :-) > >> > >> Just nobody did it yet ;-) > >> > >> Chris > >> > >> -Original Message- > >> From: Andy Grebe > >> Sent: Mittwoch, 25. Mai 2022 15:58 > >> To: dev@plc4x.apache.org > >> Subject: Subscription Simulation > >> > >> From the Getting Started guide, So if a protocol doesn’t support > >> subscription based communication it is our goal to simulate this by > polling > >> in the background so it is transparent for the users. > >> > >> Has this been implemented for any of the protocols? > >> > >> Thanks, > >> Andy > >> > > >
Re: Subscription Simulation
The simulation of subscriptions require probably more options than just "event" or so. You probably need to configure higher frequency for polling and ideally manage thread pool for that independently from netty/connection itself to have control over its reliability. If I could have one suggestion.. try making it via decoration of connection/driver. It gives you most of the flexibility without going to close with driver. I made some decorator support earlier. Base structure is here: https://github.com/ConnectorIO/connectorio-addons/tree/master/bundles/org.connectorio.plc4x.decorator/src/main/java/org/connectorio/plc4x/decorator example of "retry" logic for connection read/write/subscribe: https://github.com/ConnectorIO/connectorio-addons/blob/master/bundles/org.connectorio.plc4x.decorator.retry/src/main/java/org/connectorio/plc4x/decorator/retry/RetryDecorator.java If you find it useful for your thing we can move it into develop and maintain together. Best, Łukasz On 29.05.2022 23:34, Andy Grebe wrote: hmmm... I should probably push those CIP changes first :) On Wed, May 25, 2022 at 10:14 AM Christofer Dutz wrote: Hi Andy, It still is our plan :-) Just nobody did it yet ;-) Chris -Original Message- From: Andy Grebe Sent: Mittwoch, 25. Mai 2022 15:58 To: dev@plc4x.apache.org Subject: Subscription Simulation From the Getting Started guide, So if a protocol doesn’t support subscription based communication it is our goal to simulate this by polling in the background so it is transparent for the users. Has this been implemented for any of the protocols? Thanks, Andy
Re: Subscription Simulation
hmmm... I should probably push those CIP changes first :) On Wed, May 25, 2022 at 10:14 AM Christofer Dutz wrote: > Hi Andy, > > It still is our plan :-) > > Just nobody did it yet ;-) > > Chris > > -Original Message- > From: Andy Grebe > Sent: Mittwoch, 25. Mai 2022 15:58 > To: dev@plc4x.apache.org > Subject: Subscription Simulation > > From the Getting Started guide, So if a protocol doesn’t support > subscription based communication it is our goal to simulate this by polling > in the background so it is transparent for the users. > > Has this been implemented for any of the protocols? > > Thanks, > Andy >
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 () 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.automat...@siemens.com *
RE: [DISCUSS] how to read bool and bool-arrays?
Hi ... I just wrote down everything here:
https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields
Chris
-Original Message-
From: Christofer Dutz
Sent: Sonntag, 29. Mai 2022 18:09
To: dev@plc4x.apache.org
Subject: RE: [DISCUSS] how to read bool and bool-arrays?
Ups ... sorry ... yeah ... the 17bits was miss-typed, should have been 16
-Original Message-
From: jl hong
Sent: Donnerstag, 5. Mai 2022 06:01
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] how to read bool and bool-arrays?
Sorry, I forgot to answer in English, embarrassing
I also think this is a good choice.
Excuse me, is the following example with 17 bits a miscalculation?
5:BOOL: X (17 bit)
5:BOOL[5]: X (17 bit)
5.0:BOOL[5]: X (17 bit)
5.3:BOOL[5]: 000X0 (17 bit)
5.14:BOOL[5]: 00XX (16 bit) XXX0 (16 bit)
Also, there is another case, let me confirm, 5.5:BOOL:
0X00, is this correct?
Christofer Dutz 於 2022年4月29日 週五 下午5:12寫道：
> Almost forgot replying ... stupid when you read emails on the run ...
> they get marked "read" and you forget about them :-(
>
> I would personally opt for doing something similar to S7 ... that we
> add a ".{bit-address}" which is only valid if the datatype is "BOOL".
> This offset allows a value between 0 and 15.
>
> I would then also opt for starting at the highest level bit (the most
> left
> one) as bit 0.
> So, when reading, I would do this (X being "Using the bit": 0 being
> "skipping the bit"):
> 5:BOOL: X
> 5:BOOL[5]: X
> 5.0:BOOL[5]: X
> 5.3:BOOL[5]: 000X0
> 5.14:BOOL[5]: 00XX XXX0 In the result the
> left-most bit would be index 0 in the resulting list ...
> with growing indexes while going right.
>
> Chris
>
>
>
> -Original Message-
> From: jl hong
> Sent: Mittwoch, 27. April 2022 05:42
> To: dev@plc4x.apache.org
> Subject: Re: [DISCUSS] how to read bool and bool-arrays?
>
> Hello everyone,
> I write to the bool value just now,
>
> 1、
> b := []bool{true, true, true, true, true, true, true, true, false,
> false, false, false, false, false, false, false} // Prepare a
> write-request writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "46:BOOL[16]", b).
> Build()
>
> it will write 46 to
>
> 2、
> b := []bool{true, true, true}
> // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "46:BOOL[3]", b).
> Build()
>
> When the length is less than 16, it will "bad access: nil
> dereference", the reason is readWriteModel.CastModbusPDUError() not
> catch the **ModbusPDU type.
> I saw the child error is ModbusErrorCode_ILLEGAL_DATA_VALUE (3)
>
> 3、
> When the length is great than 16(I just tested 17), the result like
> 1、case,
> no effect on 47
>
> I just synchronize the information to everyone
>
> Łukasz Dywicki 於 2022年4月23日 週六 上午1:42寫道：
>
> > Hello Chris, Myhongk, Stephen,
> > I would say.. watch how others do it.. openHAB modbus binding for
> > example has an additional parameter of "offset", so you can read
> > status bit and ie. float value on remaining 15 or 31 bits separately.
> > While I haven't seen such strange encoding of floats (but I saw it
> > in CANopen), the bit encoded alarm flags are quite popular.
> > Especially in modbus land.
> > I see two ways to approach problem:
> > 1) force values to be read as an bit array, then you can adjust
> > offset in a caller code or define offset.
> > 2) define an offset parameter for fields, then we probably need to
> > think how to align that.
> > Bit is essentially a boolean so it should fly always without
> > touching how booleans work. I found it earlier that booleans are
> > read as kind of bitset, but that was (I think) aligned by Chris sometime
> > ago.
> >
> > Cheers,
> > Łukasz
> >
> > On 22.04.2022 13:18, Christofer Dutz wrote:
> > > Hi Stephen,
> > >
> > > Well, it sort of touches that area ... generally big endian/little
> > endian handles the byte order ... so this would more have an effect
> > on the order of the bytes inside the register too. In general I
> > would love to handle BE/LE as an option on the connection string. So
> > per default it's Big Endian (As the spec says), but you could switch
> > to LE,
> if you need to.
> > >
> > > Chris
> > >
> > >
> > >
> > > -Original Message-
> > > From: Stephen Snow
> > > Sent: Freitag, 22. April 2022 12:57
> > > To: dev@plc4x.apache.org
> > > Subject: Re: [DISCUSS] how to read bool and bool-arrays?
> > >
> > > Hi Chris and Myhongk, et al
> > >
> > > Depending on the processor (this would include embedded IIOT
> > > devices)
> > they could be big or little endian, which may complicate matters for
> > the modbus driver. Being able to set this as a parameter when using
>
RE: [DISCUSS] Let's settle on how to deal with BYTE, WORD, ...
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 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 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 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] how to read bool and bool-arrays?
Ups ... sorry ... yeah ... the 17bits was miss-typed, should have been 16
-Original Message-
From: jl hong
Sent: Donnerstag, 5. Mai 2022 06:01
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] how to read bool and bool-arrays?
Sorry, I forgot to answer in English, embarrassing
I also think this is a good choice.
Excuse me, is the following example with 17 bits a miscalculation?
5:BOOL: X (17 bit)
5:BOOL[5]: X (17 bit)
5.0:BOOL[5]: X (17 bit)
5.3:BOOL[5]: 000X0 (17 bit)
5.14:BOOL[5]: 00XX (16 bit) XXX0 (16 bit)
Also, there is another case, let me confirm, 5.5:BOOL:
0X00, is this correct?
Christofer Dutz 於 2022年4月29日 週五 下午5:12寫道：
> Almost forgot replying ... stupid when you read emails on the run ...
> they get marked "read" and you forget about them :-(
>
> I would personally opt for doing something similar to S7 ... that we
> add a ".{bit-address}" which is only valid if the datatype is "BOOL".
> This offset allows a value between 0 and 15.
>
> I would then also opt for starting at the highest level bit (the most
> left
> one) as bit 0.
> So, when reading, I would do this (X being "Using the bit": 0 being
> "skipping the bit"):
> 5:BOOL: X
> 5:BOOL[5]: X
> 5.0:BOOL[5]: X
> 5.3:BOOL[5]: 000X0
> 5.14:BOOL[5]: 00XX XXX0 In the result the
> left-most bit would be index 0 in the resulting list ...
> with growing indexes while going right.
>
> Chris
>
>
>
> -Original Message-
> From: jl hong
> Sent: Mittwoch, 27. April 2022 05:42
> To: dev@plc4x.apache.org
> Subject: Re: [DISCUSS] how to read bool and bool-arrays?
>
> Hello everyone,
> I write to the bool value just now,
>
> 1、
> b := []bool{true, true, true, true, true, true, true, true, false,
> false, false, false, false, false, false, false} // Prepare a
> write-request writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "46:BOOL[16]", b).
> Build()
>
> it will write 46 to
>
> 2、
> b := []bool{true, true, true}
> // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "46:BOOL[3]", b).
> Build()
>
> When the length is less than 16, it will "bad access: nil
> dereference", the reason is readWriteModel.CastModbusPDUError() not
> catch the **ModbusPDU type.
> I saw the child error is ModbusErrorCode_ILLEGAL_DATA_VALUE (3)
>
> 3、
> When the length is great than 16(I just tested 17), the result like
> 1、case,
> no effect on 47
>
> I just synchronize the information to everyone
>
> Łukasz Dywicki 於 2022年4月23日 週六 上午1:42寫道：
>
> > Hello Chris, Myhongk, Stephen,
> > I would say.. watch how others do it.. openHAB modbus binding for
> > example has an additional parameter of "offset", so you can read
> > status bit and ie. float value on remaining 15 or 31 bits separately.
> > While I haven't seen such strange encoding of floats (but I saw it
> > in CANopen), the bit encoded alarm flags are quite popular.
> > Especially in modbus land.
> > I see two ways to approach problem:
> > 1) force values to be read as an bit array, then you can adjust
> > offset in a caller code or define offset.
> > 2) define an offset parameter for fields, then we probably need to
> > think how to align that.
> > Bit is essentially a boolean so it should fly always without
> > touching how booleans work. I found it earlier that booleans are
> > read as kind of bitset, but that was (I think) aligned by Chris sometime
> > ago.
> >
> > Cheers,
> > Łukasz
> >
> > On 22.04.2022 13:18, Christofer Dutz wrote:
> > > Hi Stephen,
> > >
> > > Well, it sort of touches that area ... generally big endian/little
> > endian handles the byte order ... so this would more have an effect
> > on the order of the bytes inside the register too. In general I
> > would love to handle BE/LE as an option on the connection string. So
> > per default it's Big Endian (As the spec says), but you could switch
> > to LE,
> if you need to.
> > >
> > > Chris
> > >
> > >
> > >
> > > -Original Message-
> > > From: Stephen Snow
> > > Sent: Freitag, 22. April 2022 12:57
> > > To: dev@plc4x.apache.org
> > > Subject: Re: [DISCUSS] how to read bool and bool-arrays?
> > >
> > > Hi Chris and Myhongk, et al
> > >
> > > Depending on the processor (this would include embedded IIOT
> > > devices)
> > they could be big or little endian, which may complicate matters for
> > the modbus driver. Being able to set this as a parameter when using
> > the driver in an app being built which may talk to many modbus
> > devices of either endian arrangement would likely be beneficial.
> > Byte swapping in PLC land is common in communication between
> > PLC's/PC's and periphery devices or other control elements.
> > >
> > > I don't know if that is what you're
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 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 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, ...
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 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
[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
