HI Lukas, I generally agree with that assumption. I just thought that in S7 for example you can read 8 digital IOs in one BYTE by reading %I0:BYTE, for example and I could imagine that people would love to do something similar in Modbus.
Chris From: Łukasz Dywicki <[email protected]> Date: Friday, 14. October 2022 at 11:11 To: [email protected] <[email protected]> Subject: Re: BOOLeans ;-) Not sure if it is a valid assumption, but if we have a single bit (bool) value in given address then getting 5 bools out of it is kind of odd. Shouldn't we just construct a request with coil:1:BOOL, coil:2:BOOL etc. to not confuse people more? I know we can get multiple values through single modbus poll, but then it is still a range of coils rather than an array. Virtually it is a coil:1..5:BOOL and not coil:1:BOOL[5]. Best, Łukasz On 14.10.2022 15:34, Christofer Dutz wrote: > Hi Ji, > > well … I know that you can theoretically interpret 8 digital inputs as a > byte, but Coils in my understanding are usually directly mapped to digital > inputs on the Modbus device. So a COIL is technically just a bit … so with > “coil:1:BOOL[5], you’d be reading coil:1:BOOL, coil:2:BOOL, coil:3:BOOL, > coil:4:BOOL, coil:5:BOOL. It would become “problematic if someone started > reading coil:1:BOOL[5] and coil:3:BOOL[5] as he’d be reading stuff double. > Wasn’t objecting this, just wanted to point it out. > > I guess the reason your INT differs from BOOL-array is that you might be > using a LittleEndian PLC and there two-byte values are read in a different > order. > > Does that help? > > I really think we should be writing up how we expect different things to be > read and then to ensure all drivers follow that schema. > > Chris > > From: jl hong <[email protected]> > Date: Friday, 14. October 2022 at 00:55 > To: [email protected] <[email protected]> > Subject: Re: BOOLeans ;-) > Hi, Chris. > I'm sorry to interrupt your trip. > 1. Regarding "a coil is a single-valued boolean ...... Not sure what the > offset means here?" issue, I just tried it and it works like any other data > type, but there are 2 small issues to deal with. > (1) When we read the INT type, it returns a binary sort of "AB CD", while > the BOOL type returns "BA DC", so we need to deal with the binary before > reading the BOOL. > (2) The Quantity needs to be added to Offset. > > 2. How to represent the offset and the number of arrays, I think it's fine, > as long as it's clearly described. > > Christofer Dutz <[email protected]> 於 2022年10月13日 週四 晚上10:10寫道： > >> Well, I guess mostly I‘ve seen it more treated like: If there’s no “..” >> the number is the size of the array, … if there’s a “..” then the prefix is >> the offset. And yes: the Golang approach is again very different to what I >> have seen be used in industrial automation. >> >> Chris >> >> From: Sebastian Rühl <[email protected]> >> Date: Thursday, 13. October 2022 at 09:06 >> To: [email protected] <[email protected]> >> Subject: Re: BOOLeans ;-) >> In some language I saw that being used as ranges: >> >> BOOL[5] would be one bool at index 5 >> BOOL[:5] would be 5 bools till index 5 >> BOOL[3:5] would be 3 bools from index 3 to 5 >> BOOL[2:] would be all bools from index 2 >> BOOL[:-1] would be all bools till the last index -1 >> >> So maybe I'm wrong, but when you write 50000.3:BOOL[5] you mean >> 50000.3:BOOL[:5], right? >> >> Sebastian >> >> On 2022/10/13 13:40:08 Christofer Dutz wrote: >>> Hi all, >>> >>> seems we got a PR where someone implemented my proposal for handling >> Booleans ( >> https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields >> ) >>> For Modbus in Go (https://github.com/apache/plc4x/pull/545) >>> >>> I think we should probably finish some of the discussions on this and >> document them in the project. >>> >>> With the latest discussions on the Browse API and how to deal with >> (muti-dimensional) arrays … I think probably a notation: >>> >>> 50000:BOOL[3..8] >>> >>> Would be better than: >>> >>> 50000.3:BOOL[5] >>> >>> What do you think? >>> >>> Chris >>> >>
