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 <[email protected]>
Sent: Mittwoch, 27. April 2022 05:42
To: [email protected]
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 <[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
> >
>
