Today is...
Sunday, April 21, 2019
Welcome to the Modbus Community, about
the world's leading automation protocol.
Polling Slaves from 2 Masters
Can devices configured as Modbus Slaves send data to 2 separate Masters?
By Sean Campbell on 18 March, 2019 - 8:20 am

I have 6 devices capable of Modbus Communications; 3 boiler combustion controllers, a generator controller and 2 automatic transfer switches. I'm currently receiving data from the boiler combustion controllers via a prosoft communications module as part of a Rockwell Automation Contrologix system. The generator and automatic transfer switches will be interfaced with a BMS. Is it possible to poll the combustion controllers from the BMS as well as the Contrologix system?

Not from a single RS-485 bus - that violates one of the Modbus Standard RULES - only one Master. It's not an arbitrary rule - with two masters there will collisions of commands and replies and the result is really bad communications.

Although currently operating as Modbus RTU masters, either the Contrologix or the BMS is likely to have the functionality of being a Modbus RTU slave on a different RS-485 port. Only one needs that functionality, then the remaining Master can either write to, or read the one with the slave functionality for the needed needed data points, depending on which has the slave functionality. But you'll have to research that.

If that does not spin out, then there are commercial "bus moderator" modules that store and forward Modbus RTU commands from masters to avoid collisions on the 485 bus. I know Miille Applied Research has one, http://www.miille.com/

By Fred Loveless on 18 March, 2019 - 10:59 am

No it is not possible to have 2 Modbus Masters talking to the same serial slave device. The Slave has no way to know which of the 2 masters makes the request. You could use a Modbus TCP to Modbus RTU Serial gateway. This allows multiple connections to the Modbus TCP interface, and it would manage the serial communications to the serial device.

Modbus TCP to RTU gateway is a solution but the you need to change all masters to connect to the TCP side, slaves can stay on the RTU side.
If the complete network is RTU, then it's better to share the slaves with as splitter like the TSH series from ICP DAS.

https://www.icpdas-usa.com/documents/WhitePaper-Multiple-Modbus-RTU-Masters-Sharing-One-Slave.pdf

I'm a little confused in how this is set up. Do you have 2 networks 1 for prosoft 1 for bms, or is this 1 network that you would like to have both polling masters poll? Could you clarify?

By Sean Campbell on 18 March, 2019 - 3:08 pm

It would be 2 networks, one for BMS and 1 for prosoft.

If I were to do this with one of our products, I would use a 266-500-220. Connect your masters to port 1 and port 4. Slaves connect to Port 2 and port 3. Set your master ports to passthru. Then poll each network for data you are wanting each master to look at on the other sides. You can create a database that is read only or R/W to tie each point to the slaves. The masters would continue to poll your networks while also polling our database http://www.miille.com/pdfs/din266-p00.pdf .

As others have stated you can have only 1 master.

However it can be done by emulating a separate slave for each master. You need a device which polls the real slave(s) and builds and maintains a table of the required values, and then presents two virtualised slaves to the two (or more) masters.

We have done this many times. It is a custom development job; it has to be if it is to work properly. We have a four port product called a PPC which can do this.

As stated, you already have an AB PLC talking to 3 of the devices, have it poll the remaining devices and if necessary add another Prosoft module and have the BMS poll the PLC for whatever information it needs.

This assumes two things - (1) that the PLC can use multiple Prosoft modules and (2) that the BMS can be configured at the register level and doesn't simply use templates for the devices. If this is the case, you may have to arrange the Modbus info in the PLC to exactly mimic the expected location of the data in the BMS.