Guess it should be possible for plc4x to interpret INT as two shorts long as
four... In that case it could probably also handle half precision floats (16
bit), full floats and double, if the encoding is somewhat standard (which I
assume it's not)
Chris
Von: Nicl
To make things worse, there is equipment on the market with both 32-bit
numbers as well IEEE floats.
And many clients are incapable of doing something meaningful with those...
And then there is equipment that uses one register to indicate the
magnitude of one or more other registers, say 1="divi
Hi Ben and Otto,
First off all, thank you Ben for that very detailed explanation. It does seem
as if we should extend the parser to support the different numeric variants. I
don't see any problems in supporting both the hex-like one as well as the pure
numeric one.
I think we have 6 separate m
Don’t forget embedded protocols are possible,
different devices format floats differently
some devices don’t want persistent connections
etc etc
On July 15, 2020 at 20:48:39, Ben Hutcheson (ben.hut...@gmail.com) wrote:
Hi,
Answering some of the questions:-
*I guess what would be interesting, wo
Hi,
Answering some of the questions:-
*I guess what would be interesting, would be what address is going over the
wire for "30001" for example.*
The address that gets sent over the wire is the address starting from 0 i.e
31 would be address 0. I didn't know that.
*Also as a register is always
Let me try again; There is no 3 addresses in the products. It is a
notation written with text, by people. the first written digit convey the
type. That's it.
Long time ago, back when the Modbus came to life it was simply a memory
area that one could read and possibly write. And then docume
Hi Niclas,
Protocol-wise the numbers could be up to 65535 as they use an unsigned 16 bit
integer as an address.
I guess what would be interesting, would be what address is going over the wire
for "30001" for example.
Also as a register is always a 16 bit value, the increments by two sort of
pu
It is a common format in equipment documentation. I am currently working
with an electric meter. See screenshot from its manual;
https://ipfs.subutai.io/ipfs/QmPsra6ExrkSX9GCYWgHa6CTfJbBnddLVXJ3NmJjmAYrAk
At protocol level, there are no such "high numbers", just that the industry
got used to write
Hi Ben,
please excuse this potentially stupid question ... so would you suggest we leave
things the way they are or should we change something?
Right now we're using the modbus address syntax, ignoring any potential mapping
strategy.
I guess we might think about adding different address parser
Hi,
I've new but been listening to this conversation, this issue always pops up
when setting up Modbus communications.
I would vote for the API using the modbus register 41, 01, etc..
The translation between modbus registers and the address in the
PLC/simulator is handled within the devi
Hmmm ...
Regarding: 10012 being a coil and 4 a register.
Well the coils and registers are completely different things ... They are
accessed via completely different requests.
That might be some sort of convenience convention, but I wouldn't call that a
standard (I've actually never seen i
Personall, I prefer that Register Numbers are used in APIs and that the
address is only seen if you analyze the over-the-wire format, but maybe
that is just me. A big reason for this is that any interface presented to
an operator would need to use RegNumbers, as most (possibly all)
documentation of
Hmm .. so are we doing it correctly?
I mean Wireshark isn't the ideal reference here as I have several valid packets
in the KNX space, where WireShark just says "corrupt package".
So if you enter an "holding-register:42" address it tries to read the register
number 43 in ModbusPAL.
I guess as
The issue with 1-offset is that the "Register Number" found in
documentation is at an "Address" one position less. So Reg 41 has Address
40. Som libraries expect Register Numbers and some expect Register Address.
And every so often, one mixes that up.
On Wed, Jul 15, 2020 at 2:53 PM Christofer Dut
14 matches
Mail list logo
