Re: [DISCUSS] how to read bool and bool-arrays?

[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
> > >
> >
>