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
puzzle me.
I think Modbus is an extremely simple protocol but we need to get a feeling for
it's usages.
It does seem as if the industry tends to wrap some aspects in software
bubble-wrap ... we gotta find out what's below.
Chris
Am 15.07.20, 15:23 schrieb "Niclas Hedhman" <nic...@hedhman.org>:
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 "4" instead "holding register". It is a "people thing",
not a technical one.
HTH
Niclas
On Wed, Jul 15, 2020 at 6:11 PM Christofer Dutz <christofer.d...@c-ware.de>
wrote:
> Hmmm ...
>
> Regarding: 10012 being a coil and 4xxxx 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 it before)
> Would you then just subtract 40000 from every register or would you just
> configure registers starting with numbers 40000?
>
> What do the others think? The address format does reference registers ...
> should we be doing the translation?
>
> I guess that the general use-case would be that someone has a look at his
> Modbus config and says that he wants "Register X"
> and not "The Register Y references" (which seems to be one less) ... I
> might even swing my vote in favor to using register numbers instead of
> addresses.
>
> But then I ask myself: How can I address register 0 in ModbusPal ... that
> would require an address that's impossible to send.
>
> Chris
>
>
> Am 15.07.20, 11:51 schrieb "Niclas Hedhman" <nic...@hedhman.org>:
>
> 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 equipment has RegNumbers and some are lacking the
> addresses. It is also common that the register type is part of the
> Register
> Number, such as 10012, where the first 1 indicates "coil" (IIRC). and
> holding registers are in 4xxxx. Ideally(!), this is also handled by
the
> register/address parser.
>
> Niclas
>
> On Wed, Jul 15, 2020 at 5:43 PM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > 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 we are reading an "address" we are correct and probably
as
> > ModusPAL says register number, that might be correct too?
> >
> > Chris
> >
> >
> > Am 15.07.20, 10:54 schrieb "Niclas Hedhman" <nic...@hedhman.org>:
> >
> > 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 Dutz <
> > christofer.d...@c-ware.de>
> > wrote:
> >
> > > ....
> > >
> > > While looking for more Infos I found out I once wrote a
> tutorial
> > page for
> > > PLC4X __
> > >
> > > https://plc4x.apache.org/users/plc4j/virtual-modbus.html
> > >
> > > I so totally hate searching the web and getting my answers
> answered
> > by
> > > myself.
> > >
> > > Chris
> > >
> > > Am 15.07.20, 08:31 schrieb "Christofer Dutz" <
> > christofer.d...@c-ware.de>:
> > >
> > > Hi Niclas,
> > >
> > > when preparing a workshop for the Building IoT we were
> looking
> > for
> > > something where you could simulate a Modbus Slave.
> > > Most of these were Windows only solutions, so ModbusPAL
> was one
> > of the
> > > very few solutions that were pure-java.
> > >
> > > Don't quite understand what the thing with the offset is
> however
> > ...
> > > should be easy to fix ... I mean if I say address 42 in PLC4X,
> > Wireshark
> > > says 42, but in Modbus Pal I think it has to be 43 ... don't
> quite
> > get it.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 15.07.20, 03:54 schrieb "Niclas Hedhman" <
> nic...@hedhman.org
> > >:
> > >
> > > What is ModbusPAL?
> > >
> > > The 1-offset in Modbus has caused a lot of confusion
> over the
> > > years.
> > >
> > > On Tue, Jul 14, 2020 at 11:03 PM Christofer Dutz <
> > > christofer.d...@c-ware.de>
> > > wrote:
> > >
> > > > Sorry for the noise ...
> > > >
> > > > this was a false positive ... the driver was doing
> things
> > > correctly.
> > > > It seems the ModbusPAL was just off by one ;-)
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > > Am 14.07.20, 15:51 schrieb "Christofer Dutz (Jira)"
<
> > > j...@apache.org>:
> > > >
> > > > Christofer Dutz created PLC4X-214:
> > > > -------------------------------------
> > > >
> > > > Summary: [Modbus] Holding register
> > addresses
> > > have an
> > > > offset of 1 (Not reading the correct address)
> > > > Key: PLC4X-214
> > > > URL:
> > > https://issues.apache.org/jira/browse/PLC4X-214
> > > > Project: Apache PLC4X
> > > > Issue Type: Bug
> > > > Components: Driver-Modbus
> > > > Affects Versions: 0.7.0
> > > > Reporter: Christofer Dutz
> > > > Assignee: Christofer Dutz
> > > > Fix For: 0.8.0
> > > >
> > > >
> > > > If I set holding the following holding registers
> to:
> > > >
> > > > 1000: 41
> > > > 1001: 42
> > > > 1002: 43
> > > >
> > > > And then read: holding-register:1001 ... I get
> the
> > value 43
> > > returned.
> > > >
> > > >
> > > >
> > > > --
> > > > This message was sent by Atlassian Jira
> > > > (v8.3.4#803005)
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>
