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 <[email protected]> 於 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 <[email protected]>
> > Sent: Freitag, 22. April 2022 12:57
> > To: [email protected]
> > 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
> >
>
