
Visit our shop for nerds in control lifestyle products.
- PC reliability?
- Windows, real time
- PID loops
- PCs vs. PLCs
- Replacing people
- MS 'monopoly'?
- Software quality
- Where do we go from here?
- Why pay?
-- Blair
www.control.com/rss
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
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.
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.
Paul...
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.
- Wireless: Free software enhances remote keyless entry security
- Radioland: Wireless spread spectrum, frequency hopping, data radio devices
- NEMA publishes code for electrical metering; ZigBee for wireless smart metering
- Free webinar on Zigbee for embedded systems
- WirelessHART compliance verification receiver available
- PTO reports high growth, cross-industry collaboration
- Wireless helps Hexion with smoke detection, control room reporting
- Wireless networks for water and wastewater plant: easy, timely info access
- Chemical company processes critical data via wireless Ethernet
- Enclosures: Improve NEMA designs, enclose wireless equipment, keep cabinets cool
Users of this site are benefiting from open source technologies, including PHP, PostgreSQL and Apache. Be happy.
Patronize our advertisers!



