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 <[email protected]> 於 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 <[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 > > > > > >
