Hello Chris, Sorry for the late reply, but I've been a little busy lately. By the way, I received an offer of to be a committer from PLC4X PCM(sent by Hub) a few days ago, and I have already submitted the iCLA document, so I would like to thank the PLC4X team for their trust in me. To get back to the point, after your explanation I have a clearer understanding of coil and register, I thought before that coil storage is also continuous storage, so we read regitster's INT and read 16bit coil is the same. I agree with what you said that we should be writing up how we expect different things to be read, and I will improve my code when we determine how to do that.
Christofer Dutz <[email protected]> 於 2022年10月14日 週五 晚上9:34寫道： > 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 > > > > > >
