Member Login
member
passwd
remember me on this computer.

- join now -

Search

Neat Stuff

Visit our shop for nerds in control lifestyle products.

Cool stuff
Select a topic of interest:
...and press:
Fortune
The best laid plans of mice and men are usually about equal.
-- Blair
RSS Feed
RSS feed Use this link to get an RSS feed of the Control.com article flow, for private, non-commercial use only:
www.control.com/rss
Select a Page Style
Select one of the following styles:
- BluFu
- Classic
(cookies required)
from the Automation List department...
Number of MODBUS Slaves over TCP
Communications topic
advertisement
Posted by AHK on 18 June, 2008 - 7:58 pm
Max number of Modbus slaves that can be accessed over serial links is 256. Is this limit still vaild when we use MODBUS/TCP. if not does it mean that Modbus master keep a dedicated open connection with each and every MODBUS slave on a TCP network.

Posted by Mark on 19 June, 2008 - 9:36 am
Hello,
Yes and no. TCP is a connection based protocol.

1. The master could open a connection, issue a request, receive the reply and close the connection.

2. The master could open a connection and issue request until the connection is closed by the master or the slave.

3. The master could open several connections, slave dependent, issue request and close the connections.

4. Other methods.

Depending on the data needs the most common, IMHO, would be #1 and #2.

#1 for infrequent data transfer and #2 for continuous data transfer.

The number of concurrent connections a slave would accept is slave dependent.

HTH,
Mark
http://www.peakhmi.com

Posted by Michael Griffin on 19 June, 2008 - 9:37 am
A separate TCP connection is maintained between the master and each slave. The Modbus/TCP protocol itself has no limit for the number of slaves. The address of the slave is the Ethernet IP address. There is a "unit id", but that field isn't used for Ethernet transmissions.

However, the implementation of a particular master may have a limit to the number of slaves that it is willing to talk to. This isn't a limitation of the protocol itself, but rather a limitation of the hardware and software resources available in the master. The designer might limit the number of connections as a very rough means of limiting the communications load.

Posted by AHK on 20 June, 2008 - 12:50 pm
Hello, thank you very much for the clarification/confirmation.

With Serial Modbus it is possible to calculate the estimated number of slaves that can be servers by a single master based on the number of IO’s Registers in each slave, the polling frequency and the communication line speed. I would appreciate some help on how to do the same calculation when we use MODBUS/TCP.

Posted by Paul Wacker on 21 June, 2008 - 3:54 pm
The same calculation can be used for Modbus serial devices connected to Modbus Gateway, if you are only interested in polling cycle time. Just add up the cycle times for each Modbus serial network. Yes, there is some potential overhead in the Modbus Gateway, and network latency, but this should be negligible as compared to the slow serial communications speeds.

Paul...

Posted by Michael Griffin on 21 June, 2008 - 3:55 pm
With serial Modbus, you are limited by the baud rate of the serial cable. Modbus/TCP is operating over Ethernet with more than 3 orders of magnitude (for 100 Mbit) greater bandwidth. The bottleneck has therefore moved from the communications channel to the slave hardware and the master software.

What you want to know is the response time of each server (slave), and also how the client (master) works. The response time of the slave is how long a slave takes to respond to a request. This is a characteristic of the slave hardware and firmware design, not the Modbus/TCP protocol. The manufacturer should be able to give you a number for that.

A client (master) can work two different ways. One way is to simply poll each server (slave) one at a time and wait for a response before proceeding to the next one. That is how serial masters work. In this case, the total time to poll all the slaves is the sum of the response times for each of them.

The other way is for the master to poll all the slaves in parallel. That is, it simply sends out requests to all the slaves simultaneously and waits for the replies to come in from each of them. It analogous to having a separate serial port for each serial slave. In this case, the time for a complete poll is simply the longest response time for any individual slave. In fact, you may no longer have a single overall polling cycle, but rather a separate independent polling cycle for each slave.

In the second case, your limit is determined by the response time of each slave, the available network bandwidth (e.g. what other network traffic is taking up bandwidth), and how much CPU processing power is available to the master. If you are doing this on a PC, you might need to monitor the CPU usage to see how much it is being loaded down.

For the master, the author of the software should be able to tell you how it works (one at a time, or in parallel), and also give you some idea of how much load it can take in terms of transactions per second (or some other such measurement).

I have written a Modbus/TCP client/server combination that runs on a PC (http://sourceforge.net/projects/mblogic/). For one of the tests I did when writing this project, I compared polling for 16 coils to polling for 64 coils. There was no measurable difference between the two cases in terms of CPU load. This seems to indicate that the number of polls per second matters much more than the amount of data being transferred.

This means that when you are reading data from a slave, it can be more efficient (at least for the software that I wrote) to transfer a single larger block of coils or registers and then ignore some of them, than to make several smaller reads for just the data you need.

What the above means, is that there isn't a simple single answer to your question. However, you should be able to get data from the manufacturers of the devices you are using on which to base an estimate. If they can't give you that information, then you need to avoid that hardware or else do your own testing.

From Control Engineering magazine...
Related articles from Control Engineering magazine
Above articles copyright 2008 Reed Business Information. Subject to its Terms of Use.

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2008 Control Technology Corporation. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, PostgreSQL and Apache. Be happy.

Advertisement
Our Advertisers
Help keep our servers running...
Patronize our advertisers!