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/04/22 10:26:29 UTC
[DISCUSS] how to read bool and bool-arrays?
Hi all,
Myhongk just brought up an issue in the Modbus driver, which I think could probably also come up in other protocols.
When reading a BOOL or BOOL[] the driver generally reads chunks of 16 bits (words). Now we need to define how we count the bits.
Currently when reading a simple BOOL we do this (0 = skipped, 1 = read):
00000000 00000001
So, the least significant bit is the value and the ones before are skipped.
When reading an array, we currently start at the end. So reading BOOL[6] would be this:
11111100 00000000
In this case we start at the most significant bits.
Both variants have its logic and it's downsides.
Downside by starting at the least significant bits is as soon as we read more than 16 bits.
So, if we read BOOL[19] we'd probably have this
XXXXXXXX XXXXXXXX 00000000 00000XXX
Where the indexes in the array would probably be:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X X 18 17 16
Or would it be different?
Another option would be to start at the end of the last word read and to count "from right to left"
If we start at the most significant bits, it would make things easier for multiple elements, as we'd have this for BOOL[19]:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X X X X X X
But we would have only read the register value: 32768 or 0x8000 as "True".
Would be cool to know what's the default industry way to do thins (I'm sort of expecting an "it depends").
Possibly we could make it configurable (Which would complicate things a bit).
Another thing is ... in S7 we can address parts of a byte as BOOL by using a Bit address ... would it be cool to extend the Modbus to allow this too?
So something like this would work:
500001.4:BOOL[3]
Which would return (assuming we start counting at the most significant bit):
X X X X X 1 2 3 X X X X X X X X
Feedback highly appreciated :-)
Chris
RE: [DISCUSS] how to read bool and bool-arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ch...@c-ware.de>
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 <my...@gmail.com>
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?
50000:BOOL: X0000000000000000 (17 bit)
50000:BOOL[5]: XXXXX000000000000 (17 bit)
50000.0:BOOL[5]: XXXXX000000000000 (17 bit)
50000.3:BOOL[5]: 000XXXXX000000000 (17 bit)
50000.14:BOOL[5]: 000000000000000000XX (16 bit) XXX0000000000000 (16 bit)
Also, there is another case, let me confirm, 50000.5:BOOL:
00000X0000000000, is this correct?
Christofer Dutz <ch...@c-ware.de> 於 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"):
> 50000:BOOL: X0000000000000000
> 50000:BOOL[5]: XXXXX000000000000
> 50000.0:BOOL[5]: XXXXX000000000000
> 50000.3:BOOL[5]: 000XXXXX000000000
> 50000.14:BOOL[5]: 00000000000000XX XXX0000000000000 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 <my...@gmail.com>
> 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", "400006:BOOL[16]", b).
> Build()
>
> it will write 400006 to 1111111100000000
>
> 2、
> b := []bool{true, true, true}
> // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "400006: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 400007
>
> I just synchronize the information to everyone
>
> Łukasz Dywicki <lu...@code-house.org> 於 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 <s4...@gmail.com>
> > > 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 referring to, but it sure
> > > sounds
> > like endian issues I have encountered in the past (and still today).
> > >
> > > Be well,
> > >
> > > Stephen
> > > On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
> > >> Hi all,
> > >>
> > >> Myhongk just brought up an issue in the Modbus driver, which I
> > >> think could probably also come up in other protocols.
> > >>
> > >> When reading a BOOL or BOOL[] the driver generally reads chunks
> > >> of
> > >> 16 bits (words). Now we need to define how we count the bits.
> > >>
> > >> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> > >> read):
> > >>
> > >> 00000000 00000001
> > >>
> > >> So, the least significant bit is the value and the ones before
> > >> are skipped.
> > >>
> > >> When reading an array, we currently start at the end. So reading
> > >> BOOL[6] would be this:
> > >>
> > >> 11111100 00000000
> > >>
> > >> In this case we start at the most significant bits.
> > >>
> > >> Both variants have its logic and it's downsides.
> > >>
> > >> Downside by starting at the least significant bits is as soon as
> > >> we read more than 16 bits.
> > >> So, if we read BOOL[19] we'd probably have this
> > >>
> > >> XXXXXXXX XXXXXXXX 00000000 00000XXX
> > >>
> > >> Where the indexes in the array would probably be:
> > >>
> > >> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X
> > >> X 18 17 16
> > >>
> > >> Or would it be different?
> > >>
> > >> Another option would be to start at the end of the last word read
> > >> and to count "from right to left"
> > >>
> > >>
> > >> If we start at the most significant bits, it would make things
> > >> easier for multiple elements, as we'd have this for BOOL[19]:
> > >>
> > >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
> > >> X X X X X
> > >>
> > >> But we would have only read the register value: 32768 or 0x8000
> > >> as "True".
> > >>
> > >>
> > >> Would be cool to know what's the default industry way to do thins
> > >> (I'm sort of expecting an "it depends").
> > >> Possibly we could make it configurable (Which would complicate
> > >> things a bit).
> > >>
> > >> Another thing is ... in S7 we can address parts of a byte as BOOL
> > >> by using a Bit address ... would it be cool to extend the Modbus
> > >> to allow this too?
> > >>
> > >> So something like this would work:
> > >>
> > >> 500001.4:BOOL[3]
> > >>
> > >> Which would return (assuming we start counting at the most
> > >> significant
> > >> bit):
> > >>
> > >> X X X X X 1 2 3 X X X X X X X X
> > >>
> > >>
> > >> Feedback highly appreciated :-)
> > >>
> > >> Chris
> > >
> >
>
RE: [DISCUSS] how to read bool and bool-arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
Ups ... sorry ... yeah ... the 17bits was miss-typed, should have been 16
-----Original Message-----
From: jl hong <my...@gmail.com>
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?
50000:BOOL: X0000000000000000 (17 bit)
50000:BOOL[5]: XXXXX000000000000 (17 bit)
50000.0:BOOL[5]: XXXXX000000000000 (17 bit)
50000.3:BOOL[5]: 000XXXXX000000000 (17 bit)
50000.14:BOOL[5]: 000000000000000000XX (16 bit) XXX0000000000000 (16 bit)
Also, there is another case, let me confirm, 50000.5:BOOL:
00000X0000000000, is this correct?
Christofer Dutz <ch...@c-ware.de> 於 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"):
> 50000:BOOL: X0000000000000000
> 50000:BOOL[5]: XXXXX000000000000
> 50000.0:BOOL[5]: XXXXX000000000000
> 50000.3:BOOL[5]: 000XXXXX000000000
> 50000.14:BOOL[5]: 00000000000000XX XXX0000000000000 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 <my...@gmail.com>
> 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", "400006:BOOL[16]", b).
> Build()
>
> it will write 400006 to 1111111100000000
>
> 2、
> b := []bool{true, true, true}
> // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "400006: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 400007
>
> I just synchronize the information to everyone
>
> Łukasz Dywicki <lu...@code-house.org> 於 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 <s4...@gmail.com>
> > > 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 referring to, but it sure
> > > sounds
> > like endian issues I have encountered in the past (and still today).
> > >
> > > Be well,
> > >
> > > Stephen
> > > On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
> > >> Hi all,
> > >>
> > >> Myhongk just brought up an issue in the Modbus driver, which I
> > >> think could probably also come up in other protocols.
> > >>
> > >> When reading a BOOL or BOOL[] the driver generally reads chunks
> > >> of
> > >> 16 bits (words). Now we need to define how we count the bits.
> > >>
> > >> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> > >> read):
> > >>
> > >> 00000000 00000001
> > >>
> > >> So, the least significant bit is the value and the ones before
> > >> are skipped.
> > >>
> > >> When reading an array, we currently start at the end. So reading
> > >> BOOL[6] would be this:
> > >>
> > >> 11111100 00000000
> > >>
> > >> In this case we start at the most significant bits.
> > >>
> > >> Both variants have its logic and it's downsides.
> > >>
> > >> Downside by starting at the least significant bits is as soon as
> > >> we read more than 16 bits.
> > >> So, if we read BOOL[19] we'd probably have this
> > >>
> > >> XXXXXXXX XXXXXXXX 00000000 00000XXX
> > >>
> > >> Where the indexes in the array would probably be:
> > >>
> > >> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X
> > >> X 18 17 16
> > >>
> > >> Or would it be different?
> > >>
> > >> Another option would be to start at the end of the last word read
> > >> and to count "from right to left"
> > >>
> > >>
> > >> If we start at the most significant bits, it would make things
> > >> easier for multiple elements, as we'd have this for BOOL[19]:
> > >>
> > >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
> > >> X X X X X
> > >>
> > >> But we would have only read the register value: 32768 or 0x8000
> > >> as "True".
> > >>
> > >>
> > >> Would be cool to know what's the default industry way to do thins
> > >> (I'm sort of expecting an "it depends").
> > >> Possibly we could make it configurable (Which would complicate
> > >> things a bit).
> > >>
> > >> Another thing is ... in S7 we can address parts of a byte as BOOL
> > >> by using a Bit address ... would it be cool to extend the Modbus
> > >> to allow this too?
> > >>
> > >> So something like this would work:
> > >>
> > >> 500001.4:BOOL[3]
> > >>
> > >> Which would return (assuming we start counting at the most
> > >> significant
> > >> bit):
> > >>
> > >> X X X X X 1 2 3 X X X X X X X X
> > >>
> > >>
> > >> Feedback highly appreciated :-)
> > >>
> > >> Chris
> > >
> >
>
Re: [DISCUSS] how to read bool and bool-arrays?
Posted by jl hong <my...@gmail.com>.
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?
50000:BOOL: X0000000000000000 (17 bit)
50000:BOOL[5]: XXXXX000000000000 (17 bit)
50000.0:BOOL[5]: XXXXX000000000000 (17 bit)
50000.3:BOOL[5]: 000XXXXX000000000 (17 bit)
50000.14:BOOL[5]: 000000000000000000XX (16 bit) XXX0000000000000 (16 bit)
Also, there is another case, let me confirm, 50000.5:BOOL:
00000X0000000000, is this correct?
Christofer Dutz <ch...@c-ware.de> 於 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"):
> 50000:BOOL: X0000000000000000
> 50000:BOOL[5]: XXXXX000000000000
> 50000.0:BOOL[5]: XXXXX000000000000
> 50000.3:BOOL[5]: 000XXXXX000000000
> 50000.14:BOOL[5]: 00000000000000XX XXX0000000000000
> 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 <my...@gmail.com>
> 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", "400006:BOOL[16]", b).
> Build()
>
> it will write 400006 to 1111111100000000
>
> 2、
> b := []bool{true, true, true}
> // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "400006: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 400007
>
> I just synchronize the information to everyone
>
> Łukasz Dywicki <lu...@code-house.org> 於 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 <s4...@gmail.com>
> > > 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 referring to, but it sure sounds
> > like endian issues I have encountered in the past (and still today).
> > >
> > > Be well,
> > >
> > > Stephen
> > > On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
> > >> Hi all,
> > >>
> > >> Myhongk just brought up an issue in the Modbus driver, which I
> > >> think could probably also come up in other protocols.
> > >>
> > >> When reading a BOOL or BOOL[] the driver generally reads chunks of
> > >> 16 bits (words). Now we need to define how we count the bits.
> > >>
> > >> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> > >> read):
> > >>
> > >> 00000000 00000001
> > >>
> > >> So, the least significant bit is the value and the ones before are
> > >> skipped.
> > >>
> > >> When reading an array, we currently start at the end. So reading
> > >> BOOL[6] would be this:
> > >>
> > >> 11111100 00000000
> > >>
> > >> In this case we start at the most significant bits.
> > >>
> > >> Both variants have its logic and it's downsides.
> > >>
> > >> Downside by starting at the least significant bits is as soon as we
> > >> read more than 16 bits.
> > >> So, if we read BOOL[19] we'd probably have this
> > >>
> > >> XXXXXXXX XXXXXXXX 00000000 00000XXX
> > >>
> > >> Where the indexes in the array would probably be:
> > >>
> > >> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X
> > >> X 18 17 16
> > >>
> > >> Or would it be different?
> > >>
> > >> Another option would be to start at the end of the last word read
> > >> and to count "from right to left"
> > >>
> > >>
> > >> If we start at the most significant bits, it would make things
> > >> easier for multiple elements, as we'd have this for BOOL[19]:
> > >>
> > >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
> > >> X X X X X
> > >>
> > >> But we would have only read the register value: 32768 or 0x8000 as
> > >> "True".
> > >>
> > >>
> > >> Would be cool to know what's the default industry way to do thins
> > >> (I'm sort of expecting an "it depends").
> > >> Possibly we could make it configurable (Which would complicate
> > >> things a bit).
> > >>
> > >> Another thing is ... in S7 we can address parts of a byte as BOOL
> > >> by using a Bit address ... would it be cool to extend the Modbus to
> > >> allow this too?
> > >>
> > >> So something like this would work:
> > >>
> > >> 500001.4:BOOL[3]
> > >>
> > >> Which would return (assuming we start counting at the most
> > >> significant
> > >> bit):
> > >>
> > >> X X X X X 1 2 3 X X X X X X X X
> > >>
> > >>
> > >> Feedback highly appreciated :-)
> > >>
> > >> Chris
> > >
> >
>
Re: [DISCUSS] how to read bool and bool-arrays?
Posted by jl hong <my...@gmail.com>.
我也觉得这个选择挺好的.
请问下, 以下的示例有17个bit 是 写错了吗?
50000:BOOL: X0000000000000000 (17 bit)
50000:BOOL[5]: XXXXX000000000000 (17 bit)
50000.0:BOOL[5]: XXXXX000000000000 (17 bit)
50000.3:BOOL[5]: 000XXXXX000000000 (17 bit)
50000.14:BOOL[5]: 00000000000000XX(16 bit) XXX0000000000000 (16 bit)
另外, 还有一种情况, 我确认下, 50000.5:BOOL: 00000X0000000000, 这样没错吧?
Christofer Dutz <ch...@c-ware.de> 於 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"):
> 50000:BOOL: X0000000000000000
> 50000:BOOL[5]: XXXXX000000000000
> 50000.0:BOOL[5]: XXXXX000000000000
> 50000.3:BOOL[5]: 000XXXXX000000000
> 50000.14:BOOL[5]: 00000000000000XX XXX0000000000000
> 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 <my...@gmail.com>
> 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", "400006:BOOL[16]", b).
> Build()
>
> it will write 400006 to 1111111100000000
>
> 2、
> b := []bool{true, true, true}
> // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "400006: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 400007
>
> I just synchronize the information to everyone
>
> Łukasz Dywicki <lu...@code-house.org> 於 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 <s4...@gmail.com>
> > > 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 referring to, but it sure sounds
> > like endian issues I have encountered in the past (and still today).
> > >
> > > Be well,
> > >
> > > Stephen
> > > On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
> > >> Hi all,
> > >>
> > >> Myhongk just brought up an issue in the Modbus driver, which I
> > >> think could probably also come up in other protocols.
> > >>
> > >> When reading a BOOL or BOOL[] the driver generally reads chunks of
> > >> 16 bits (words). Now we need to define how we count the bits.
> > >>
> > >> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> > >> read):
> > >>
> > >> 00000000 00000001
> > >>
> > >> So, the least significant bit is the value and the ones before are
> > >> skipped.
> > >>
> > >> When reading an array, we currently start at the end. So reading
> > >> BOOL[6] would be this:
> > >>
> > >> 11111100 00000000
> > >>
> > >> In this case we start at the most significant bits.
> > >>
> > >> Both variants have its logic and it's downsides.
> > >>
> > >> Downside by starting at the least significant bits is as soon as we
> > >> read more than 16 bits.
> > >> So, if we read BOOL[19] we'd probably have this
> > >>
> > >> XXXXXXXX XXXXXXXX 00000000 00000XXX
> > >>
> > >> Where the indexes in the array would probably be:
> > >>
> > >> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X
> > >> X 18 17 16
> > >>
> > >> Or would it be different?
> > >>
> > >> Another option would be to start at the end of the last word read
> > >> and to count "from right to left"
> > >>
> > >>
> > >> If we start at the most significant bits, it would make things
> > >> easier for multiple elements, as we'd have this for BOOL[19]:
> > >>
> > >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
> > >> X X X X X
> > >>
> > >> But we would have only read the register value: 32768 or 0x8000 as
> > >> "True".
> > >>
> > >>
> > >> Would be cool to know what's the default industry way to do thins
> > >> (I'm sort of expecting an "it depends").
> > >> Possibly we could make it configurable (Which would complicate
> > >> things a bit).
> > >>
> > >> Another thing is ... in S7 we can address parts of a byte as BOOL
> > >> by using a Bit address ... would it be cool to extend the Modbus to
> > >> allow this too?
> > >>
> > >> So something like this would work:
> > >>
> > >> 500001.4:BOOL[3]
> > >>
> > >> Which would return (assuming we start counting at the most
> > >> significant
> > >> bit):
> > >>
> > >> X X X X X 1 2 3 X X X X X X X X
> > >>
> > >>
> > >> Feedback highly appreciated :-)
> > >>
> > >> Chris
> > >
> >
>
RE: [DISCUSS] how to read bool and bool-arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
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"):
50000:BOOL: X0000000000000000
50000:BOOL[5]: XXXXX000000000000
50000.0:BOOL[5]: XXXXX000000000000
50000.3:BOOL[5]: 000XXXXX000000000
50000.14:BOOL[5]: 00000000000000XX XXX0000000000000
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 <my...@gmail.com>
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", "400006:BOOL[16]", b).
Build()
it will write 400006 to 1111111100000000
2、
b := []bool{true, true, true}
// Prepare a write-request
writeRequest, err := connection.WriteRequestBuilder().
AddQuery("field1", "400006: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 400007
I just synchronize the information to everyone
Łukasz Dywicki <lu...@code-house.org> 於 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 <s4...@gmail.com>
> > 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 referring to, but it sure sounds
> like endian issues I have encountered in the past (and still today).
> >
> > Be well,
> >
> > Stephen
> > On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
> >> Hi all,
> >>
> >> Myhongk just brought up an issue in the Modbus driver, which I
> >> think could probably also come up in other protocols.
> >>
> >> When reading a BOOL or BOOL[] the driver generally reads chunks of
> >> 16 bits (words). Now we need to define how we count the bits.
> >>
> >> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> >> read):
> >>
> >> 00000000 00000001
> >>
> >> So, the least significant bit is the value and the ones before are
> >> skipped.
> >>
> >> When reading an array, we currently start at the end. So reading
> >> BOOL[6] would be this:
> >>
> >> 11111100 00000000
> >>
> >> In this case we start at the most significant bits.
> >>
> >> Both variants have its logic and it's downsides.
> >>
> >> Downside by starting at the least significant bits is as soon as we
> >> read more than 16 bits.
> >> So, if we read BOOL[19] we'd probably have this
> >>
> >> XXXXXXXX XXXXXXXX 00000000 00000XXX
> >>
> >> Where the indexes in the array would probably be:
> >>
> >> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X
> >> X 18 17 16
> >>
> >> Or would it be different?
> >>
> >> Another option would be to start at the end of the last word read
> >> and to count "from right to left"
> >>
> >>
> >> If we start at the most significant bits, it would make things
> >> easier for multiple elements, as we'd have this for BOOL[19]:
> >>
> >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
> >> X X X X X
> >>
> >> But we would have only read the register value: 32768 or 0x8000 as
> >> "True".
> >>
> >>
> >> Would be cool to know what's the default industry way to do thins
> >> (I'm sort of expecting an "it depends").
> >> Possibly we could make it configurable (Which would complicate
> >> things a bit).
> >>
> >> Another thing is ... in S7 we can address parts of a byte as BOOL
> >> by using a Bit address ... would it be cool to extend the Modbus to
> >> allow this too?
> >>
> >> So something like this would work:
> >>
> >> 500001.4:BOOL[3]
> >>
> >> Which would return (assuming we start counting at the most
> >> significant
> >> bit):
> >>
> >> X X X X X 1 2 3 X X X X X X X X
> >>
> >>
> >> Feedback highly appreciated :-)
> >>
> >> Chris
> >
>
Re: [DISCUSS] how to read bool and bool-arrays?
Posted by jl hong <my...@gmail.com>.
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", "400006:BOOL[16]", b).
Build()
it will write 400006 to 1111111100000000
2、
b := []bool{true, true, true}
// Prepare a write-request
writeRequest, err := connection.WriteRequestBuilder().
AddQuery("field1", "400006: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 400007
I just synchronize the information to everyone
Łukasz Dywicki <lu...@code-house.org> 於 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 <s4...@gmail.com>
> > 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 referring to, but it sure sounds
> like endian issues I have encountered in the past (and still today).
> >
> > Be well,
> >
> > Stephen
> > On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
> >> Hi all,
> >>
> >> Myhongk just brought up an issue in the Modbus driver, which I think
> >> could probably also come up in other protocols.
> >>
> >> When reading a BOOL or BOOL[] the driver generally reads chunks of 16
> >> bits (words). Now we need to define how we count the bits.
> >>
> >> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> >> read):
> >>
> >> 00000000 00000001
> >>
> >> So, the least significant bit is the value and the ones before are
> >> skipped.
> >>
> >> When reading an array, we currently start at the end. So reading
> >> BOOL[6] would be this:
> >>
> >> 11111100 00000000
> >>
> >> In this case we start at the most significant bits.
> >>
> >> Both variants have its logic and it's downsides.
> >>
> >> Downside by starting at the least significant bits is as soon as we
> >> read more than 16 bits.
> >> So, if we read BOOL[19] we'd probably have this
> >>
> >> XXXXXXXX XXXXXXXX 00000000 00000XXX
> >>
> >> Where the indexes in the array would probably be:
> >>
> >> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X
> >> X 18 17 16
> >>
> >> Or would it be different?
> >>
> >> Another option would be to start at the end of the last word read and
> >> to count "from right to left"
> >>
> >>
> >> If we start at the most significant bits, it would make things easier
> >> for multiple elements, as we'd have this for BOOL[19]:
> >>
> >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
> >> X X X X X
> >>
> >> But we would have only read the register value: 32768 or 0x8000 as
> >> "True".
> >>
> >>
> >> Would be cool to know what's the default industry way to do thins (I'm
> >> sort of expecting an "it depends").
> >> Possibly we could make it configurable (Which would complicate things
> >> a bit).
> >>
> >> Another thing is ... in S7 we can address parts of a byte as BOOL by
> >> using a Bit address ... would it be cool to extend the Modbus to allow
> >> this too?
> >>
> >> So something like this would work:
> >>
> >> 500001.4:BOOL[3]
> >>
> >> Which would return (assuming we start counting at the most significant
> >> bit):
> >>
> >> X X X X X 1 2 3 X X X X X X X X
> >>
> >>
> >> Feedback highly appreciated :-)
> >>
> >> Chris
> >
>
Re: [DISCUSS] how to read bool and bool-arrays?
Posted by Łukasz Dywicki <lu...@code-house.org>.
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 <s4...@gmail.com>
> 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 referring to, but it sure sounds like endian issues I have encountered in the past (and still today).
>
> Be well,
>
> Stephen
> On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
>> Hi all,
>>
>> Myhongk just brought up an issue in the Modbus driver, which I think
>> could probably also come up in other protocols.
>>
>> When reading a BOOL or BOOL[] the driver generally reads chunks of 16
>> bits (words). Now we need to define how we count the bits.
>>
>> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
>> read):
>>
>> 00000000 00000001
>>
>> So, the least significant bit is the value and the ones before are
>> skipped.
>>
>> When reading an array, we currently start at the end. So reading
>> BOOL[6] would be this:
>>
>> 11111100 00000000
>>
>> In this case we start at the most significant bits.
>>
>> Both variants have its logic and it's downsides.
>>
>> Downside by starting at the least significant bits is as soon as we
>> read more than 16 bits.
>> So, if we read BOOL[19] we'd probably have this
>>
>> XXXXXXXX XXXXXXXX 00000000 00000XXX
>>
>> Where the indexes in the array would probably be:
>>
>> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X
>> X 18 17 16
>>
>> Or would it be different?
>>
>> Another option would be to start at the end of the last word read and
>> to count "from right to left"
>>
>>
>> If we start at the most significant bits, it would make things easier
>> for multiple elements, as we'd have this for BOOL[19]:
>>
>> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
>> X X X X X
>>
>> But we would have only read the register value: 32768 or 0x8000 as
>> "True".
>>
>>
>> Would be cool to know what's the default industry way to do thins (I'm
>> sort of expecting an "it depends").
>> Possibly we could make it configurable (Which would complicate things
>> a bit).
>>
>> Another thing is ... in S7 we can address parts of a byte as BOOL by
>> using a Bit address ... would it be cool to extend the Modbus to allow
>> this too?
>>
>> So something like this would work:
>>
>> 500001.4:BOOL[3]
>>
>> Which would return (assuming we start counting at the most significant
>> bit):
>>
>> X X X X X 1 2 3 X X X X X X X X
>>
>>
>> Feedback highly appreciated :-)
>>
>> Chris
>
RE: [DISCUSS] how to read bool and bool-arrays?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <s4...@gmail.com>
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 referring to, but it sure sounds like endian issues I have encountered in the past (and still today).
Be well,
Stephen
On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
> Hi all,
>
> Myhongk just brought up an issue in the Modbus driver, which I think
> could probably also come up in other protocols.
>
> When reading a BOOL or BOOL[] the driver generally reads chunks of 16
> bits (words). Now we need to define how we count the bits.
>
> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> read):
>
> 00000000 00000001
>
> So, the least significant bit is the value and the ones before are
> skipped.
>
> When reading an array, we currently start at the end. So reading
> BOOL[6] would be this:
>
> 11111100 00000000
>
> In this case we start at the most significant bits.
>
> Both variants have its logic and it's downsides.
>
> Downside by starting at the least significant bits is as soon as we
> read more than 16 bits.
> So, if we read BOOL[19] we'd probably have this
>
> XXXXXXXX XXXXXXXX 00000000 00000XXX
>
> Where the indexes in the array would probably be:
>
> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X X
> X 18 17 16
>
> Or would it be different?
>
> Another option would be to start at the end of the last word read and
> to count "from right to left"
>
>
> If we start at the most significant bits, it would make things easier
> for multiple elements, as we'd have this for BOOL[19]:
>
> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
> X X X X X
>
> But we would have only read the register value: 32768 or 0x8000 as
> "True".
>
>
> Would be cool to know what's the default industry way to do thins (I'm
> sort of expecting an "it depends").
> Possibly we could make it configurable (Which would complicate things
> a bit).
>
> Another thing is ... in S7 we can address parts of a byte as BOOL by
> using a Bit address ... would it be cool to extend the Modbus to allow
> this too?
>
> So something like this would work:
>
> 500001.4:BOOL[3]
>
> Which would return (assuming we start counting at the most significant
> bit):
>
> X X X X X 1 2 3 X X X X X X X X
>
>
> Feedback highly appreciated :-)
>
> Chris
Re: [DISCUSS] how to read bool and bool-arrays?
Posted by Stephen Snow <s4...@gmail.com>.
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 referring to, but it sure sounds
like endian issues I have encountered in the past (and still today).
Be well,
Stephen
On Fri, 2022-04-22 at 10:26 +0000, Christofer Dutz wrote:
> Hi all,
>
> Myhongk just brought up an issue in the Modbus driver, which I think
> could probably also come up in other protocols.
>
> When reading a BOOL or BOOL[] the driver generally reads chunks of 16
> bits (words). Now we need to define how we count the bits.
>
> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> read):
>
> 00000000 00000001
>
> So, the least significant bit is the value and the ones before are
> skipped.
>
> When reading an array, we currently start at the end. So reading
> BOOL[6] would be this:
>
> 11111100 00000000
>
> In this case we start at the most significant bits.
>
> Both variants have its logic and it's downsides.
>
> Downside by starting at the least significant bits is as soon as we
> read more than 16 bits.
> So, if we read BOOL[19] we'd probably have this
>
> XXXXXXXX XXXXXXXX 00000000 00000XXX
>
> Where the indexes in the array would probably be:
>
> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X X X X X
> X X 18 17 16
>
> Or would it be different?
>
> Another option would be to start at the end of the last word read and
> to count "from right to left"
>
>
> If we start at the most significant bits, it would make things easier
> for multiple elements, as we'd have this for BOOL[19]:
>
> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X
> X X X X X X X X
>
> But we would have only read the register value: 32768 or 0x8000 as
> "True".
>
>
> Would be cool to know what's the default industry way to do thins
> (I'm sort of expecting an "it depends").
> Possibly we could make it configurable (Which would complicate things
> a bit).
>
> Another thing is ... in S7 we can address parts of a byte as BOOL by
> using a Bit address ... would it be cool to extend the Modbus to
> allow this too?
>
> So something like this would work:
>
> 500001.4:BOOL[3]
>
> Which would return (assuming we start counting at the most
> significant bit):
>
> X X X X X 1 2 3 X X X X X X X X
>
>
> Feedback highly appreciated :-)
>
> Chris