This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.

Speeding up Modbus/TCP

24 September 2017

Rob Hulsebos argues that Modbus/TCP users should think carefully before migrating to a more modern, Ethernet-based protocol, purely to increase speed.

Modbus/TCP, the ‘Ethernet’ version of the old faithful serial Modbus/RTU (and Modbus/ASCII) versions have been with us for over a decade. If you are familiar with the serial Modbus versions, Modbus/TCP will not be difficult to learn. However, those familiar with the serial Modbus versions often assume that Modbus/TCP has the same limitations with regard to master/slave behaviour, fixed roles, single master only, slow speed due to master and slave turnaround times, slow polling cycles, etc.

Due to the flexibility of TCP, all these limitations are not necessary. Modbus/TCP allows for more innovative ways of working, if only the protocol stacks would use them. Probably the single reason that most implementations do not do this, is because they are revamped serial Modbus implementations. They come up with the same limitations, which are completely unnecessary and limit the power of Modbus/TCP. Below I will show how to take advantage of Modbus/TCP implementations, giving a more flexible and faster Modbus, improving the responsiveness of applications, without any change to the protocol.

Master/slave roles
In serial Modbus, there is always one device configured to be the ‘master’ on the network, and all others are ‘slave’. These roles cannot change dynamically. The drawback of being a slave is that these devices cannot communicate among each other.

In TCP, all devices are created equal. Every device can communicate with every other device on the network (if they agree on a common protocol, such as Modbus). This means that the master/slave distinction is no longer necessary. Modbus/TCP has renamed these roles as ‘client’ and ‘server’, but the name change has no functional consequences.

An innovative implementation of a Modbus/TCP stack can offer more functionality. A device can run a client and server implementation simultaneously on TCP. A device can also have multiple client roles, multiple server roles, and multiple client and server roles simultaneously. This allows for a hierarchical network architecture, where a device is server to one device, and is client to other devices. This gives considerable freedom in designing large systems. There is no longer a need to create a star-like communication architecture. No central device, no bottlenecks, no extra programming effort, better scalability, no single point of failure.

At this point some might be arguing that this can be done on serial Modbus too! This is true, but it cannot be done on the same network. For each master role or slave role, you need a network interface card, and a separate network infrastructure.

No more polling
In serial Modbus, the only way for a master to become aware of a change in a sensor or input, or the presence of an alarm, etc. is to regularly ‘poll’ a slave. Although polling is simple, it takes up network bandwidth and processing time on the master and the slaves. It is not uncommon for dozens of poll cycles to be executed before data changes once.

If each device is able to autonomously decide to communicate with another device, the consequence of this freedom is that polling is no longer necessary – if a device has something of interest to report to another device, it can behave as a client and just send the information. If data is not changed, send nothing. This means that for every change in data only one Modbus communication cycle is necessary, immediately after it is known that data must be sent. Apart from the gain in network use and processing time, there is no more delay due to the polling cycle, allowing for faster response on events.

Less slave delay
In serial Modbus, after a master has sent a command to a slave, the master must wait for the answer from that slave. In the meantime, nothing much happens on the network, wasting bandwidth. One slow slave can negatively influence the communication speed from the master to the other slaves. 

In TCP, the protocol gives a separate communication channel between a client and all the slaves. The client can send a message to a slow server but does not have to wait for an answer – the other clients can be sent messages in the meantime. So Modbus/TCP allows for parallel communication from the client to all its servers. TCP assures that the replies from the slaves can be matched to the corresponding commands, so there is no fear of confusion.

This parallel communication increases the effective use of the network, and decreases the polling time. Each device can have its own polling time. Slow devices do not delay the faster devices. 

In serial Modbus, a master can only send a new command to a slave if the previous command was processed by the slave and the response message has been completely received. The master must then process the response, and can only then transmit a new command to the same slave. In the meantime, the slave is doing nothing (for the duration of the transmission of the response, the processing time of the master, and the duration of the transmission of the next command).

When two devices communicate in TCP, both have a queue of data to the other party. Each one reads as much data as it needs from the queue, processes it, and repeats this cycle. This allows a client to send multiple commands to a server; as long as they are not processed by the server TCP keeps both messages in its queue. So a client can fire multiple commands in a row quickly.

The server can now extract one message from its queue of incoming commands, and process it. After the response is sent back to the client, the server can immediately extract the next message from the queue  (still waiting there) and start processing it. It is efficient, because the server does not have to wait for the client to process a response, decide on the next command to be sent, wait for the next command to arrive, etc, as is the case in serial Modbus.

It is useful when a client needs to send a batch of commands that are not depending on each other – for example read a group of holding registers which are not sequential in memory (otherwise a single Modbus/TCP command would have sufficed).

Not real time, but still fast
TCP/IP was not designed to operate in real time. However, this does not mean it is slow. It is bad software-implementations that make TCP slow. An example of this is the Nagle algorithm, designed in the 80’s as an optimisation for doing terminal I/O on slow networks (10 Mbit/s at the time). By default, the Nagle algorithm is still active on every TCP implementation. Luckily it can be shut off, but only following instructions of the application software. It must be done correctly on the client and on the server side. If only one half disables the Nagle algorithm, communication one way will be quick, but the other way it will be slow.

An easy way to inadvertently invoke the Nagle algorithm is to implement Modbus/TCP protocol stack in such a way that network messages sent in two pieces, after which the protocol stack waits for a response from the server. This ‘write, write, read’ is often easily programmed in Modbus/TCP, where each network message consist of a six-byte header, followed by the function code related data. Although logical from a programmer’s point-of-view, it kills performance. 

No changes needed
Modifying existing protocols is difficult, due to compatibility issues. But we are lucky: all of the suggested improvements can be done without changes to Modbus/TCP. It just requires better use of TCP. Of course, the protocol stacks must be changed (perhaps completely rewritten), but no changes are necessary for Modbus/TCP itself. This makes that introduction of the new features can be done device-by-device.

If you are a dissatisfied Modbus user and planning to migrate to a more modern (Ethernet-based) protocol, think twice as this is not necessarily Modbus/TCP’s fault. If Modbus/TCP implementations make good use of the capabilities of TCP, it allows for much more flexibility in communication architecture, and a much higher speed than with implementations that only mimic serial Modbus capabilities. 

Rob Hulsebos is a specialist in datacommunications. He has been active in industrial networks since 1993, both as vendor and end-user and has authored several books about industrial networks. He can be contacted on r.hulsebos@onsnet.nu


Most Viewed Articles...

Print this page | E-mail this page