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
