Separation of MODBUS Devices

M

Thread Starter

Matthew Raterman

Is there any set of rules/guidance/best practices for separating Modbus devices that are communicating to a single Master? I have project were there are several Modbus TCP/IP devices that are connected to the host DCS through a Modbus TCP card. This card can handle up to 256 devices, but due to concern of failure, etc., it is preferred to separate these device out onto multiple cards. I'm looking for suggestions/best practices that could be used as a design guideline for determining what devices will go together on what card based on controlled equipment, device type, manufacturer, interface criticallity, etc.
 
Here are two things to consider:

Process equipment considerations:
As example, in a lead/lag arrangement, the lead pump is connected to one master while the lag pump is connected to the other master. In this way, a pump can be started if a Modbus card fails.

Network topology:
Depending how you decide to partition your I/O (based on above), and the pre-existing network infrastructure, you may need to reconfigure or add additional switches to satisfy any redundancy requirements you identify.

Just a side thought:
Depending on your control system, increasing the number of communications cards might not increase the throughput network. The bottleneck in this case is actually the CPU to which the card is linked. For the AC800M, for example, CPU loading increases as the number of devices attached to a CI867 increases. Foxboro FDSIs generally behave the same way.
 
Presumably each Modbus TCP card has its own setting for timeout?

I'd separate known slow responders from those that are quick responders.

For instance, the pH meter, run by an 8 bit micro that struggles to reply over RTU in less than 2 seconds at 1200 baud, which then connects through a wired modem to the main panel, then through a wireless connection, then a serial/ethernet server so that its effective reply time is on the order of 3 seconds might not belong on the same connection as coriolis that whose controller is looking for 20 updates per second so the batch controller won't have to wait 3+ seconds in the middle of a batch for its next Coriolis update.

I'm not aware of a best practices document, but someone on the forum might know of one.
 
Hi,

There is also the alternative to use Modbus RTU/TCP concentrators.
Where you offload the main Master. If you have 100 slaves connected to one master, you can use let's say 10 gateways (Concentrators) and get much better update times. Since each gateway will handle 10 slaves and your main master will only need to read/write to 10 devices, instead of 100..

My 2 cents.

Patrick Lansdorf
 
Top