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
