HELP! Modbus Beginner


Thread Starter

Marie O' Brien

could someone please point me in the direction of where to start with learning about Modbus
i have the klockner moeller sucos program, if anyone has used that before, any tips would be handy!
a good site for beginners would be good, because i've looked at so many sites which all say the same thing, mostly theory, and don't indicate how i should start on working on it practically

any help at all would be much appreciated

marie o brien

i know any questions i ask sound rather silly to people but bear with me
in a modbus configuration i have been told to fix as part of my learning about modbus, there are digital inputs which have been assigned addresses of 42001-42044, do u know is there any reason why they couldnt be assigned to an address near the analogue inputs which have been given addresses down in the start of the 40,000 range
it seems to be in all the programs for the plc's here that 42,000 is being used for certain inputs

theres no extra inputs going to be added so thats not the problem
of course no one here can remember a sufficient amount about modbus to think of why it is 42,000 thats being used

Marie O' Brien

The 40000+ memory range does not have to be just analogs or just discretes - it's up to the device vendor to specify how each 16-bit address will be interpreted. There may be 'holes' in the memory map - these are addresses that do not have any meaning. For example, in my Modbus-capable black box I could have 40001 be an analog representing motor RPM, 40002 could be a 'hole', and 40003 could be a bitfield with each of 16 bits having a purpose.


marie o brien

what if i have a lot of plcs on one network does having "holes" like that cause delays , because we have problems here when one specific plc is running, and they've narrowed it down to the modbus as the root of the problem would having all the addresses closer together on all the plcs help any bit or is just useless
Thanks for the help
Marie O' Brien

From: marie o brien
>what if i have a lot of plcs on one network does having "holes" like that
>cause delays

Yes, for the best thoughput, pack the registers you want to read closely together.

>because we have problems here when one specific plc is
>running, and they've narrowed it down to the modbus as the root of the
>problem ...

Make sure the slave address of this PLC is not the same as another PLC on this network. Some Modbus slaves ( not the ones from Modicon )
will answer back to a Modbus master with error messages at inappropriate times. This will cause the problem I think you describe. Make sure the slave in question is configured for multi-point

>a good site for beginners would be good, because i've looked at so many
>sites which all say the same thing, mostly theory , and don't indicate how
>i should start on working on it practically

I hope the above information is helpful in solving your present problem, but I'm afraid there's no way to avoid learning the theory if you want to maintain a large Modbus network. Get a copy Modscan32 from *, and a Modbus slave. Set them up on your desk. You
will understand Modbus in a few days.

*( it works in demo mode but please buy it, it's ridiculously inexpensive
at about $50.00 and I'd like for them continue making great tools
like this. )

Jay Kirsch
Take the manual of Modbus from
In this document you have the structure of the data secuence for Modbus RTU and Modbus ASCII
I dont know the Moeller system, but if is similar to the Modicon system, you can read the codes for each error in the word of controlfor each communication. They are expressed in HEXA numbers.
About the only thing having 'holes' in the register addresses does is make you write a few instructions to get all the data. i have a device which uses 400001 thru 400010 and then 401000 to 401180, and I have to write 2 MSTR instructions to poll all of that data. But that's a 3rd-party device and that's how they laid it out. If you were doing it in a PLC you could lay them out sequentially and not have that problem.


It is probably good practice to group types of data in certain ranges.

Having said that, it is also VERY good practice (IMHO) to buffer all the data that is being transmitted or received via Modbus. Modbus writes,
particularly to coils, will over-ride any other information, even disables. By using a buffer, you can be sure that no inadvertent operations in the master are going to directly affect operations in the slave.

Buffering also means that the master program does not have to be altered every time there is a change in the PLC program - such as adding a debounce circuit on a discrete input. It becomes solely the PLC programmer's responsibility to make sure the relkevant data is stuffed into the right pigeonhole in the buffer.

And it gives the Modbus interface specifier the chance to optimise the communications, if that is important. By grouping all register values,
analogue or diigital or timer or whatever, that will say be used on one SCADA display, so that they are in adjacent 16-bit words, you can read them all in a single MODBUS transaction and minimise your overhead. On the other hand, if you want to use discrete bits from all over the memory map, you either have to communicate large chunks of unused data or have a whole lot of little messages with the associated overhead for each.

So my recommendation would be: select a chunk of currently unused memory, reserve it for a Modus communications buffer, and set up networks so that right data is placed where you want it.

First, a register called 42001 is sent "on the wire" as offset 2000. The 4xxxx is just a convention meaning this is a read/write 16-bit register.

Second, many products group point types by 1000's - so 40001+ may be 16-bit ints, 41001+ may be 32-floats (split into 2 x 16-bits), 42001+ may be bits (as you see), and 43001+ may be 16-char ASCII strings packed into 8 "registers" each.

This is just a convention which makes it easier for a remote program to "detect" which data types it's referencing. Of course there is no standard
here - plus as has been pointed out this prevents a single read from getting more than 1 type. So I'd say, your answer is that it's 42001 because that's what the designer thought was "best".

I once saw a product with 8 "inputs", so some well meaning designer called them 40001, 40251, ... up to 41751. The 2nd/3rd/etc registers in each group were some config parameters for each input - left lots of room for future
expansion in each group. But alas, this design FORCED 8 distinct reads of 1 register each to see the status of all 8 inputs!

- Lynn

Alastair Fordyce

There are some other posts which provide links but as a Moeller and Modbus user, here are some comments from experience. Moeller PLC's can communicate using Modbus protocol using two hardware options. PS416 rack PLC's can use the PS416-MOD-200 Modbus slave module. PS416 and other PS4 family PLC's can use the ZB4-501-UM4 Suconet:RS232 communications module with the S40AMK4 software application module. There are Modbus master and slave modules available within the application.

I would not recomend using the older S30 DOS software for programming the Moeller PS4 PLC's. While the DOS software is still available, the Windows based S40 software is much more powerful, is easier to use and has an ongoing development and support path.

If you don't have a copy of the S40 software, a demo version (fully functional except for PLC communications) is available from
The Modbus application module is available from
The same application is also available in German (s40amk4d.exe).
I haven't had any problems using the application module in either master or slave modes.
For other Modbus information, I suggest looking at the site.

Best regards,

Alastair Fordyce A.IPENZ, REA, NZCE,CQA
Systems Engineer
Bremca Industries Limited
PO Box 7169
tel +64 (3) 332 6370
fax +64 (3) 332 6377
e-mail [email protected]

Marie O' Brien

thanks alaister
actually they've been having problems with the communications between the sucos S30 (DOS based) and the plc's but only from the sucos loaded on the Win95, we have another 368 laptop(really old) which communicates fine using the same sucos
(version 2.1)

have u ever had problems with klockner moeller plc's running communications fine with the DCS for a couple of hours and then just dying away? people here are kinda confused as to whats going on