One of the oldest digital communication protocols is also the most popular, and for good reason. You should get to know Modbus. Modbus is the fundamental network protocol used in most industrial applications today. It is universal, open and an easy to use protocol. Modbus has been around industries for over 30 years, but it’s still the dominant voluntary standard used in almost all major industrial process control, instrumentation and automation products in the market today.

New industrial products such as PLC, PAC, I/O devices, and meters may have an Ethernet, serial or even perhaps wireless interface, but Modbus is still the preferred protocol The pivotal advantage of Modbus is that it can run over virtually all communication media, including twisted pair wires, wireless, fibre optics, Ethernet, telephone modems, cell phones and microwave which would imply that a Modbus connection could be easily established on a new or existing factory floor. 

What is MODBUS ?

The Modbus protocol was developed in 1979 by Modicon, incorporated, for industrial automation systems and Modicon programmable controllers. It has since become an industry standard method for the transfer of discrete/ analog I/O information and register data between industrial control and monitoring devices. Modbus is now a widely-accepted, open, public-domain protocol that requires a license, but does not require royalty payment to its owner.

Modbus devices communicate using a master-slave (client-server) technique in which only one device (the master/client) can initiate transactions (called queries). The other devices (slaves/servers) respond by supplying the requested data to the master, or by taking the action requested in the query. A slave is any peripheral device (I/O transducer, valve, network drive, or other measuring device) which processes information and sends its output to the master using Modbus. The  I/O Modules form slave/server devices, while a typical master device is a host computer running appropriate application software. Other devices may function as both clients (masters) and servers (slaves).

Types of Modbus Communication Protocol

Modbus serial protocol (the original version) is a master/slave protocol, e.g. one master that controls the Modbus data transactions with multiple slaves that respond to the master’s requests to read from or write data to the slaves. Network architectures are shown Figures 1.

Modbus TCP, also known as Modbus TCP/IP, uses a client/server architecture. Network architectures are shown Figures 2. (below)

Figure 1: Modbus Serial Architecture

In a standard Modbus serial network, there is only one master and as many as 247 slaves, each with a unique slave address. And there are two types of serial Modbus, Modbus RTU and ASCII.

The difference between Modbus RTU and Modbus ASCII

There are just two basic transmission ways found in RTU, ASCII and MODBUS connections. These transmission modes determine the way in which the MODBUS messages are coded. In ASCII format, the messages are readable, whereas in RTU the messages are in binary coding and cannot be read while monitoring. The trade off is the RTU messages are smaller-size, which allows for more data exchange in an identical time period. One must be aware that all nodes within one MODBUS network should be of exactly the same transmission style, meaning MODBUS ASCII cannot communicate with MODBUS RTU and vice versa.

Properties of Modbus ASCII and Modbus RTU

Modbus TCP (Ethernet)

Modbus TCP is often referred to as Modbus over Ethernet. Modbus TCP (also ModbusTCP/IP) is simply the Modbus RTU protocol with a TCP interface that runs on Ethernet. The Modbus messaging structure is the application protocol that defines the rules for organizing and interpreting the data independent of the data transmission medium. TCP/IP refers to the Transmission Control Protocol and Internet Protocol, which provides the transmission medium for Modbus TCP/IP messaging.

This enables Modbus/TCP devices to immediately and easily connect and communicate over existing Ethernet and fibre networks. Modbus/TCP also allows many more addresses than RS485, the use of multiple Masters and speeds in the gigabit range. While Modbus RTU has a limitation of 247 nodes per network, Modbus/TCP networks can have as many slaves as the physical layer can handle. Often this number is somewhere around 1,024. Ethernet’s rapid adoption within the process control and automation industry has allowed Modbus/TCP to become the most widely used, fastest growing and supported industrial protocol over Ethernet. Network architectures are shown Figures 2.

Figure 2: Modbus TCP Architecture

Unlike Modbus RTU and Modbus ASCII, Modbus/TCP will allow multiple Clients to poll the same Server device simultaneously. This is permitted because over Ethernet via TCP/IP, multiple messages can be sent, buffered and delivered without the requirement of token passing or total bus control, which is often the case with many RS485 and RS422 protocols.

Addressing and messaging

Modbus memory addressing is generally organized around 16-bit registers that contain 16 coils or on/off (0/1) states or integer values in 16-bit registers (input/output or holding registers). While some devices will use their own Modbus addressing, typical Modbus addressing can be seen in Figure 3.

Figure 3: Typical Serial Transaction

Modbus messaging is based on what is called an application data unit (ADU) and a Protocol Data Unit (PDU). The Modbus message includes the slave/server address for the slave/server involved, a function code, data start addresses, and the data being sent to (written) or to be send back (read) to the master/client, with an error checksum at the end (CRC/LRC/Checksum). The size of the serial Modbus PDU is limited by the size constraint that was inherited from the first Modbus serial network implementation of 256 bytes. Modbus slave addresses are limited to 1-255. Addresses 1-247 are available to the user and addresses 248-255 are reserved.

A typical Modbus serial data transaction is shown in Figure 3. The Modbus TCP data transactions are essentially the same except the server address is an IP address, there is some Ethernet overhead, and the error checksum is different. Modbus data can include starting data addresses, data quantity or count, and actual data that is read or is to be written. If the Modbus slave/server has a problem with the master/client request, the slave/server will issue an error response back to the master/client.

In the Modbus TCP/IP message format, the Modbus PDU is typically wrapped into the Ethernet package and consists of the Modbus function code and the Modbus data request. The slave address and error code (CRC) are typically not needed as the Modbus TCP/IP packet is routed by the network to the desired IP address (unless there is to be a connection into a serial network), and the error check is done as part of the Ethernet packet.

The Function Code defines the command that the slave device is to execute, such as read data, accept data, report status, etc.

Properties of Function Code

Wireless Modbus

The cost savings in installation costs (wiring infrastructure) is the pivotal benefit for using wireless devices in industrial applications. Wireless technology enables process control engineers to quickly and cost effectively obtain real-time data from anywhere in the field/factory floor or perhaps various other remote locations at any time which is essential for an industrial automation and process control system.

Modbus via wireless is transparent to the control system or host and the slave devices. The host system doesn’t know if a wireless Modbus network exists, as it doesn’t have to deal with it. When a Modbus master makes a request to a slave and the packets arrive at the transmitting radio, that radio will usually re-order the packets and encrypt them before transmission. Once the RF (Radio Frequency) packets are received by the “slave” radio, it de-encrypts them and puts them back in order to represent a valid Modbus Packet.

Assuming that the packet has not been damaged or corrupted, it will then be sent to the destined slave. The slave will respond back to the Master and the process starts again. It is important to pay special attention to a Modbus communication parameter called “timeout.” Timeout is the amount of time that the Modbus master will wait for a response from a slave device before attempting a re-transmission. Depending on how well the radio is communicating, packets can be delayed causing an unnecessary amount of retries and retransmits. Today most of these parameters can be managed for efficient transfer of Modbus packets. However, it is essential to conduct a proper radio site survey that include signal strength and spectrum noise analysis before implementing a wireless Modbus network to alleviate any communication problems.

A Modbus network can be set up fairly easily to work over a wireless link as shown in figure 4. Essentially, all the wireless link does is replacing the twisted pair cables with a transmitter/receiver at each end of the network. That is essential so you can consult some industrial wireless Daviteq specialist to assist you in selecting the right wireless hardware for your industrial applications.

 

Popularity of Modbus

On the market today, most control and automation devices are supported with the Modbus protocol. Typical as temperature sensor, pressure sensor, temperature controller,PLC,inverter… In addition ,with the growing growth of the iot community, more and more electrical and electronic devices have been using the Modbus protocol. We are not too unfamiliar with such cult brands : Schneider, Mitsubishi, ABB, Seimens, Omron, Selec,…

Below are a few product pictures on the market using Modbus protocol

Modbus and IoT in the future

The protocol which commonly used in IoT as a local interface to manage devices is Modbus. In the different way, Modbus is also the most pervasive communications protocol in building  industrial and automation and the most commonly available means of connecting automated electronic devices, that’s IoT (Internet of Things). Why did that happen? Why did Modbus have such an impact on the Industrial Automation industry as well as IoT that it survives to this day as one of the leading industrial networks of the 21st century? There are several reasons.

Modbus is the first widely accepted fieldbus standard. In a short time, hundreds of vendors implemented the Modbus messaging system in their devices and Modbus became the de facto standard for industrial communication networks.

Standard transports. The transport layer for Modbus RTU commands is also simple to understand. It uses RS485, a differential communication standard which supports up to 32 nodes in a multi-dropped bus configuration. RS485 provided noise immunity superior to the RS232 electrical standard.

Modbus implements a very simple data representation. Modbus is very easy to understand. Its primary purpose is simply to move data between an RTU Master device (a Client in Modbus TCP) and an RTU Slave device (a Server in Modbus TCP).

Another reason Modbus was so successful was the fact that it could be so readily understood by non-programmers. Engineers who built glue machines, meters, measuring devices, and such could easily understand the concept of coils/registers and the simple commands to read and write them.

In short: While ‘more modern’ replacement communication protocols exist and are being developed, Modbus will definitely be around for a long time in the future and maybe even longer than we think.

What are the cons of Modbus and When NOT to Use Modbus ?

Just like any other communication methods have their limitations. Understanding the limitations helps us to make full use of the desired method of communication while ensuring the most secure. Here are some limitations to keep in mind.

• Modbus does not have any inherent protections against inadvertent or malicious assaults on its data transactions from cybersecurity attacks, and requires additional protections. Therefore, do not use Modbus TCP if you want to go through a firewall. Because anyone on that side of the firewall would have access to not only that Modbus device but everything else on that network.
• Don’t use Modbus RTU if you need fast data response. You can push the Modbus RTU baud rate to 56K baud, or maybe even 115K, but you are still looking at a response time of 25 or more milliseconds for each device on the link. The baud rate is usually the least effective mechanism for generating faster response on a Modbus RTU link. The majority of delays between the transmission of a Modbus request and the reception of a response is the processing time with the Modbus Slave node, not the time on the wire. And the more slave nodes, the longer the cycle time of the entire multi-dropped RTU network.
• Don’t use Modbus if you need any event-oriented responses. Modbus doesn’t do events. A Modbus Master (RTU) or a Modbus Client (TCP) simply sends requests and gets These are not networks that can quickly respond to an alarm condition.
• Don’t use Modus for sensitive data transfers. Modbus doesn’t support any kind of security. Anyone getting access to the network can read the data transmitted on the network.
• Don’t use Modbus if you have a lot of data to transfer. The packets are limited to around 120 bytes maximum. It’s just not efficient for any kind of large data transfer. That recommendation doesn’t change for Modbus TCP. Even though Modbus TCP is contained with a TCP packet, you can only transfer the same 120 bytes in a Modbus message.
• Don’t use Modbus in control applications. Modbus is just an “ok” control protocol. Because Modbus RTU operates in a half-duplex mode (request out – response in, next node and repeat) the cycle time through all the nodes varies with the number of nodes. It should be used only in applications where timing and response times are not a consideration.

So, Modbus is great for small control applications where a small amount of data needs to be transferred from point A to point B. It requires little code space and almost no RAM, so it is perfect for small embedded applications. Use it only where it’s going to be effective, given its limitations.

Modbus troubleshooting

Troubleshooting Modbus can be broken into two general pieces, Modbus TCP/IP and Modbus Serial. Troubleshooting Modbus TCP/IP can be broken down into network troubleshooting, such as making sure that the Modbus TCP/IP Ethernet packets with error-free data get to and from where they are supposed to go to perform the desired transactions.

The first question to ask when troubleshooting a Modbus link whether the problem is new—did the Modbus link work in the past, or it has never worked? If it worked before for a Modbus TCP link, this means that the Ethernet and device configurations are probably OK.

The same applies to a Modbus serial link—the Modbus type, RTU/ASCII, baud rate, start characters, parity, end characters, timing between messages, termination resistors in place, etc. are probably correct. This allows the troubleshooter to concentrate on what has changed on the link, such as new device(s), modified or changed wiring, new wiring near the existing wiring, etc. If the installation is a new one, the wiring and the Modbus configuration for all the Modbus devices on the link should be double-checked, and made sure it lines up with the Modbus link manual and documentation. A common problem for Modbus serial is to have the signal wires reversed.

The most common indications of Modbus problems are an I/O timeout (a message request was sent and a reply was not received before the interface timed out) or an error code was received from the slave/server device. This would commonly show up as a bad process variable PV or an indication of an I/O timeout on the DCS or HMI. Most Modbus devices have communication lights that blink when the device is communicating and some will use colored LED to provide some troubleshooting capability.

If you are experiencing noise or intermittent or strange problems with a Modbus serial link, the problem is likely related to grounding, incorrect shielding, or wiring power wires next to Modbus wiring. RS-485 two-wire and four-wire require a common line that is grounded at one point only, in addition to the two or four wires.

The use of Modbus for safety-critical actions should be risk-assessed, and if used in safety-critical applications, protections should be put in place to ensure the safety integrity of the Modbus data that performs a safety-critical function.

Conclusion

Obviously, Modbus protocol plays no small role in both industrial communication and IoT, understanding Modbus protocol helps you to effectively deploy automation and IoT applications, while ensuring reliability safety of the solution. For more information or for more detailed advice on Modbus-related applications, please contact us at info@daviteq.com