Modbus Master or Slave

Good morning. I would like to know how one determines what will be Modbus Master or slave. In this demo system I have a RedLion HMI, Omron NJ PLC, a Moxa RS485 to Ethernet (for Omron PLC), and a Eurotherm 2404 Temp Controller. The Eurotherm is an older model and has only Modbus over RS485 for coms. The Omron uses Ethernet port only. The RedLion has both RS485 and Ethernet, capabilities. The Omron NJ is supposed to drive the Temp controller and the RedLion is used as display, and changes to temperature set point on the Eurotherm. The Eurotherm reports back to the Omron and it's value is displayed on the RedLion. The Moxa is simply a transparent means of getting the Omron NJ to understand the Eurotherm, using Modbus, taken from from the Moxa. In this case, what would you recommend for master and slave for this connection? If you could explain a little, that would be awesome, as I am learning. Thanks much.

I figured out my situation. This is actually a dumb question, if I could figure out how to delete it, I would. Sorry about that.

One thing about forums, is that it's not just today's question. Threads here are found by internet searches by people looking for answers and this deserves an answer because it is not an uncommon question.

My analysis is based on the fact that a multidrop, Modbus RTU over RS-485 network, by definition, can have one, and only one master in order to prevent network data 'collisions' and the resulting lost data transfers. Even though the PLC has Ethernet, its connection to the Modbus network is over RS-485 through the Moxa converter, so the network is not Modbus/TCP, it is Modbus RTU. Only one master.

The Eurotherm temperature controller is very likely a Modbus Slave only, it can not be a Modbus Master.

HMI's usually have both Modbus slave and Modbus master functionality. They are very often designated to be a Modbus Master.

The Omron PLC might or might not have Modbus master functionality.

Assuming that it does, either the HMI or PLC could be the Modbus master and control the data flow.

I'm not quite sure exactly what tasks "The Omron NJ is supposed to drive the Temp controller" are to be done in the PLC. As described, I see the Master tasks as:

- Read Setpoint (SP) from HMI or PLC, then Write the SP to the Eurotherm (if it originates in the PLC, then probably send it to the HMI also, for display.)
- Read temperature (PV) value from the Eurotherm
- Send Temperature (PV) value to the PLC and the HMI for display.

I see the residence/location of the Modbus Master as a function of which device is easiest to program, the PLC or the HMI.

The other one is a Modbus slave.

It's not a 'dumb question' and frequently need clairifying for some (glad you worked it out).

The names 'Master' (or 'Client') and 'Slave' (or 'Server') depends on individual message transactions. In some media (like RS485) the protocol (like Modbus) only allows for one unit to initiate all message transactions. This 'message initiator' is the 'Master' (or Client). It begins the message regardless whether the general flow of inforrmation is from the Client to the Server or from the Server to the Client. The target device is the 'reponder' and, for the purposes of this message trransaction. only 'speaks when spoken to'. Some protocols allow for a rotation of the 'Client' role among devices in a network based on the transfer of a special short message called a 'token'.

In other media, like Ethernet, than can be multiple seemingly simultaneous 'clients'. The 'seemingly' is because the speed of the CSMA/CD protocol (Carrier Sense Multiple Access / Collision Detection) on a 'lightly loaded' Ethernet network makes the message access seem always immediate. But for any single message transaction there is an 'initiator' and a 'responder'.

There is another consideration in the decision of whether your PLC program should be a the client (master) for a given transaction or the server (slave) - assuming such a choice is availabe - then your program should be the client/master to read information from another unit into your own memory space. If information mustt be transferred from your memory space to another PLC let it initiate (be the client/master) for that transaction.

Now, why do I say this? If you will ALWASY be using a fully documented version of the program then it is not as much of a worry. But let's say you go online without proper documentation and see a bit/value changing without any reference to it in the program and it doesn't appear to be a value controlled by an HMI. It could very well be that a message in anothe unit is writing to that memory space - but that won't be apparent just by looking at the undocumented program. It is much easier if you can find a READ type message in your own program which uses that memory location as a destination.

Since we are talking about future use of this thread I wanted to throw in 2 cents from something I run across all the time.

When you have a modbus network between just a PLC an an HMI, the HMI is almost always the master. People get confused because they think the PLC is the "smart" device and "master" sounds like it should be the smart thing.

It seems to help if you use the client / server terminology. Then you can progress to the idea that the server (slave) has the data... it serves it up to the client (master).

Also, when you start to talk about human actions at the HMI, it becomes very clear that the HMI must be the master. The PLC has no way of knowing when a person will press an HMI button or enter a value into a field. The HMI knows this and so it can immediately send the modbus commands to set or reset the bit or transfer the value to the PLC to put it in a register. If the PLC was the modbus master, it would have to continually read the entire data table in the HMI to see if anything changed. This would be very impractical.

Anyway, I have seen people confused by this enough that I thought I would mention it here.

Just did one with a Modbus TCP UPS on one side and an Omron CS1D (duplex) on the other. Sucked out the Modbus TCP stuff with the Modbus master in the Red Lion DSPLE and stuffed it into registers in the Omron with the Omron FINS driver. Took a while but now working well. The local distributor tells me you can even get 2 Modbus masters talking to each other.

Wow, thanks a lot guy's! Excellant instruction from each of you. Thnk you.

The Master asks, the Slave responds. The master wants the data and the slave has it. This is "old-style" modbus rtu (serial RS485 bus) nomenclature.


The Client asks, the Server responds. The client wants the data and the server has it. This is modbus tcp (ethernet) nomenclature.

BobB said:

Just did one with a Modbus TCP UPS on one side and an Omron CS1D (duplex) on the other. Sucked out the Modbus TCP stuff with the Modbus master in the Red Lion DSPLE and stuffed it into registers in the Omron with the Omron FINS driver. Took a while but now working well. The local distributor tells me you can even get 2 Modbus masters talking to each other.

Click to expand...

Yes Sir, I have this already running. You're correct, it was very easy. The unfortunate part is that the Eurotherm Temp Controller has only RS485 communication, this is the problem I am presented with and the reason I purchased the Moxa for the interface for the Omron NJ control and the Eurotherm Controller. When I go straight to the RedLion from the Eurotherm, it works great. Its getting the RedLion to take it from the Moxa that is causing trouble with me. Thank you everyone for your response, it is a great help.