Using Modbus for process control, automation
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 most popular industrial protocol being used today, for good reasons. It is simple, inexpensive, universal, and easy to use. Even though Modbus has been around since the past century—nearly 30 years—almost all major industrial instrumentation and automation equipment vendors continue to support it in new products.
Although new analyzers, flowmeters, and PLCs may have a wireless, Ethernet, or fieldbus interface, Modbus is still the protocol that most vendors choose to implement in new and old devices. Another advantage is that it can run over virtually all communication media, including twisted-pair wires, wireless, fiber optics, Ethernet, telephone modems, cell phones, and microwave. This means that a Modbus connection can be established in a new or existing plant fairly easily. In fact, one growing application is providing digital communications in older plants, using existing twisted-pair wiring.
What is Modbus?
Modbus was developed by Modicon (now Schneider Electric) in 1979 as a means for communicating with many devices over a single twisted-pair wire. The original scheme ran over RS232, but was adapted to run on RS485 to gain faster speed, longer distances, and a true multi-drop network. Modbus quickly became a de facto standard in the automation industry, and Modicon released it to the public as a royalty-free protocol. Today, Modbus-IDA (www.Modbus.org), the largest organized group of users and vendors, continues to support the protocol worldwide.
Modbus is a master-slave system, where the master communicates with one or multiple slaves. The master is typically a PLC (programmable logic controller), PC, DCS (distributed control system), or RTU (remote terminal unit). Modbus RTU slaves are often field devices, all of which connect to the network in a multi-drop configuration. When a Modbus RTU master wants information from a device, the master sends a message that contains the device’s address, data it wants, and a checksum for error detection. Every other device on the network sees the message, but only the device that is addressed responds.
Slave devices cannot initiate communication; they can only respond. In other words, they speak only when spoken to. Some manufacturers are developing hybrid devices that act as slaves but also have write capability, thus making them pseudo-masters at times.
The three most common versions used today are:
- Modbus ASCII
- Modbus RTU
- Modbus TCP
All messages are sent in the same format. The only difference among the three types is in how the messages are coded.
In Modbus ASCII, all messages are coded in hexadecimal, using four-bit ASCII characters. For every byte of information, two communication bytes are needed, twice as many as with Modbus RTU or Modbus TCP. Therefore, ASCII is the slowest of the three protocols, but is suitable when telephone modem or radio (RF) links are used. This is because ASCII uses characters to delimit a message. As a result, any delays in the transmission medium will not cause the message to be misinterpreted by the receiving device. This can be important when dealing with slow modems, cell phones, noisy connections, or other difficult transmission mediums.
In Modbus RTU, data is coded in binary and requires only one communication byte per data byte. This is ideal for use over RS232 or multi-drop RS485 networks, at speeds from 1,200 to 115 Kbaud. The most common speeds are 9,600 and 19,200 baud. Modbus RTU is the most widely used industrial protocol, so most of this discussion will focus on its basics and application considerations.
Modbus/TCP is simply Modbus over Ethernet. Instead of using device addresses to communicate with slave devices, IP addresses are used and the Modbus data is simply encapsulated inside a TCP/IP packet. Hence, any Ethernet network that supports TCP/IP should immediately support it. More details regarding this version will be provided in a later section.
Modbus RTU basics
To communicate with a slave device, the master sends a message containing:
- Device address
- Function code
- Data, and
- Error check.
The device address is a number from 0 to 247. Messages sent to address 0 (broadcast messages) can be accepted by all slaves, but numbers 1 to 247 are addresses of specific devices. With the exception of broadcast messages, a slave device always responds to a message so the master knows the message was received.
The function code defines the command that the slave device is to execute, such as read data, accept data, report status, etc. (Figure 2). Function codes are 1 to 255. Some function codes have sub-function codes.
The data defines addresses in the device’s memory map for read functions, contains data values to be written into the device’s memory, or contains other information needed to carry out the function requested.
The error check is a 16-bit numeric value representing the cyclic redundancy check (CRC). The CRC is generated by the master (via a complex procedure involving ORing and shifting data) and checked by the receiving device. If the CRC values do not match, the device asks for a retransmission of the message. In some systems, a parity check can also be applied.
When the slave device performs the requested function, it sends a message back to the master. The returning message contains the slave’s address and requested function code (so the master knows who is responding), the data requested, and an error check value.
Modbus memory map
Each Modbus device has memory, where process variable data is stored. The Modbus specification dictates how data is retrieved and what type of data can be retrieved. However, it does not place a limitation on how and where the device vendor maps this data in its memory map.
Discrete inputs and coils are one-bit values, and each has a specific address. Analog inputs (also called input registers) are stored in 16-bit registers. By utilizing two of these registers, Modbus can support the IEEE 32-bit floating point format. Holding registers are also 16-bit internal registers that can support floating point.
Data in the memory map is defined in the Modbus specification. Assuming that the device vendor followed the specification (not all do), all data can easily be accessed by the master, which follows the specification. In many cases, the device vendor publishes the memory locations (Figure 3), making it easy for the person programming the master to communicate with the slave device.
Reading and writing data
Modbus has up to 255 function codes, but 01 (read coils), 02 (read discrete inputs), 03 (read holding registers), and 04 (read input registers) are the most commonly used read functions that are used to collect data from slaves. For example, to read three 16-bit words of analog data from device 5’s memory map, the master sends a command that looks something like this:
5 04 2 3 CRC
Where 5 is the device address, 04 says to read input registers, 2 is the starting address (address 30,002), 3 means to read three contiguous data values starting at address 30,002, and CRC is the error check value for this message. The slave device, upon receiving this command, sends back a response that looks something like this:
5 04 aa bb cc CRC
Where 5 is the device’s address; 04 is the repeated read command; aa, bb, and cc are the three 16-bit data values; and CRC is the error check value for this message.
Reading and writing digital inputs and outputs is done in a similar manner using different read and write functions. Assuming that the device follows the specification, it is a simple programming task to set up the master to read and write data, check status, obtain diagnostic information, and perform various control and monitoring functions.
One of the easiest ways to bring field devices into a process control system, PLC, or industrial computer is to simply connect digital and analog I/O into a distributed I/O system that has Modbus communication capability. This technique allows a user to connect analog and digital signals remotely, which can then be connected to a master via twisted-pair cable. Multiple data concentrators like that can be installed in several locations throughout a plant, all linked by Modbus (Figure 4).
This solution works for both new and existing plants. In many existing plants, field instruments typically connect to the DCS or PLC via home run wiring, where each device is connected with individual twisted pairs that carry analog signals. With a field device data concentrator, one of those twisted pairs can be used for the Modbus signal. This is particularly useful if the plant wants to add additional field instruments, but does not want to run more wiring given that it can easily cost of $100 per foot. A distributed I/O system can accommodate all of the existing I/O, or it can be used just to send data from all the new field instruments.
In some cases, the control system is not able to deal with a Modbus signal. It may be that the legacy control system is accustomed to dealing with 4-20 mA analog I/O and directly wired digital I/O, and accommodating Modbus data would require extensive reprogramming. Similarly, some users might like to add new remote signals to their system without having to run wire or buy expensive Modbus interface cards that require extensive re-programming. In that case, a peer-to-peer solution works best. Some of the data concentrating devices have varying levels of built-in intelligence and can be set up in either a peer-to-peer or peer-to-host configuration.
For example, with a peer-to-peer system (Figure 5), two concentrators are used: one in the field and one in the control room, to serve as a multiplexer and de-multiplexer. Field instruments connect to the remote concentrator, which connects to the control room concentrator via a single twisted-pair wire. Then, outputs from the control room concentrator are wired into the control system’s existing analog I/O panel. In this way, the analog signals from the new field transmitters can be seen in their original analog state through the plant’s existing analog I/O cards. This makes programming and commissioning of the new signals less difficult than programming new digital interface cards. These peer-to-peer solutions can also accommodate bi-directional communication in which both sides of the system can have inputs and outputs.
HART via Modbus
Another challenge for legacy plants is to find an inexpensive and convenient way to take advantage of installed HART (highway addressable remote transducer) smart devices. HART is a digital protocol that was designed to allow transmitters to transmit digital data and an analog signal simultaneously over traditional plant-installed copper twisted pair, and many if not most 4-20 mA field devices available include it. Users can configure, interrogate, and diagnose transmitters locally or remotely via any point along the twisted pair. HART slaves can be wired in a point-to-point or multi-drop configuration. In the more common point-to-point configuration, the HART transmitter varies the current on the analog loop to represent the desired process variable. While it is possible to monitor the digital HART data only, in a point-to-point configuration, it is rarely done. As the transmitter controls the current, it also has the ability to send multiple digital pieces of information via the HART data stream. Both process variable data and digital data can be transmitted by the HART slave or transmitter. This data can be used to monitor the health of instruments or used by the process control system or asset management system to optimize processes, assist in providing tighter control, or prevent unexpected process hiccups. In some cases, existing plants may have hundreds of HART-enabled instruments. Unfortunately, for one reason or another, many plants have never exploited the capabilities of HART.
In today’s world of asset management, remote diagnostics, and advanced control, many plants would like to extract that digital information, but their control system and existing wiring can’t accommodate it. The control system may not be set up or have the capability to extract HART data from the analog loop. A HART instrument can send up to four process variables via the HART signal: PV (primary variable), SV (secondary variable), TV (tertiary variable), and FV (fourth variable). Additionally, there are various bits and bytes of status data that can also be transmitted. However, if the control system cannot read the additional process variable data or any of the other diagnostic and status information from the digital HART signal, then that data goes to waste.
Customers have a range of options to get this HART data, even in legacy and mature plants. Some DCS companies offer new upgraded analog I/O cards that have the ability to pick off this HART data. However, these cards usually cost three to five times as much as the traditional analog I/O cards. Additionally, there are HART mux (multiplexer) bricks that can be installed on existing analog loops that have RS422 and RS485 outputs to asset management systems or DCSs. Again, these I/O mux bricks can be cost prohibitive. An optional route, using a HART to Modbus converter, can be cost effective and allows the flexibility of monitoring just a few or many loops at reasonable costs.
With a HART interface module that supports Modbus RTU, all the HART data can be brought to the control system simply and cost effectively (Figure 6). An interface module is a smart device that acts like HART master on the front end and Modbus RTU slave on the back end. It can extract all of the digital HART data from the 4-20 mA signal without placing a burden on the loop. It then provides a display, and various possible other outputs. When a Modbus output option is selected, the HART data is digitally mapped to an internal Modbus memory map where it can then be polled by a PLC or DCS that is acting as the Modbus RTU Master. By multi-dropping various interface modules devices via RS485, this essentially becomes a scaled-down asset management system for a fraction of the cost.
A Modbus network can be set up fairly easily to work over a wireless link (Figure 7). Essentially, all the wireless link does is replace the twisted-pair cables with a transmitter/receiver at each end of the network. Many wireless radio manufacturers support the Modbus protocol. However, due to some encryption schemes and time delays that radios and modems use, it is important to consult with your wireless vendor before making the assumption that it is supported.
Obviously the major advantage of wireless Modbus is the cost savings in wiring infrastructure. Signals that are needed from tank farms, well heads, and various other remote locations have historically been cost prohibitive to monitor and control.
Fortunately, Modbus via wireless is transparent to the control system or host, and the slave. Like the systems described previously for legacy plants, the host system doesn’t even know that a wireless Modbus network exists, because it doesn’t have to deal with it. When a 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.
Sometimes it is important to pay special attention to a Modbus communication parameter called timeout. Timeout is the amount of time that the master will wait for a response from a slave before attempting a re-transmission. Depending on how well the radio is communicating, packets can be delayed, causing an unnecessary amount of retries and re-transmits. With today’s FHSS (frequency-hopping spread spectrum) radios, most of these parameters can be massaged for efficient transfer of packets. However, proper radio site surveys that include signal strength and spectrum noise analysis can often prevent many communication hiccups.
Modbus over Ethernet
Modbus TCP is often referred to as Modbus over Ethernet since for all practical purposes it is simply Modbus packets encapsulated in standard TCP/IP packets. This enables Modbus TCP devices to connect and communicate over existing Ethernet and fiber networks, which can support 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 process control and other automation applications has allowed Modbus TCP to grow rapidly to become the most widely used industrial protocol over Ethernet.
Although PLC vendors of all sizes have adopted their own proprietary protocols over Ethernet, almost all of them support Modbus TCP. And for those PLC vendors who don’t currently support Modbus TCP, there are many companies that offer chassis-style slide-in communication cards and stand-alone gateways.
Unlike Modbus RTU and Modbus ASCII, Modbus TCP allows multiple masters to poll the same slave device simultaneously. This is allowed because 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.
Control in the field
So far, we’ve only dealt with simple Modbus data acquisition systems. It is also possible to install control devices in the field that will communicate to the central control system via Modbus. Some concentrators mentioned earlier also have a CPU and real-time control kernel that can be programmed to perform control functions, such as PID, on/off control, local alarming, complex math equations, diagnostics, and alarm monitoring.
Because it has PLC-type logic, PID-type control functions, and advanced computing capabilities, a sophisticated concentrator can often eliminate the need for a PLC, industrial computer, or a small DCS for a fraction of the price. While Modbus doesn’t have the capabilities of other protocols like Foundation fieldbus, Profibus, and CIP, when combined with the right devices, it can often fit the need for many applications where local control is desired.
PID controllers were originally stand-alone noncommunicating devices. As PLCs and DCSs got smarter, so did the controllers. Today, many end users still prefer the direct readout and simple-to-program style of the single loop controller. Digital communication protocols like Modbus may have added a little more life to these once stand-alone instruments. By multi-dropping controllers you can now create your own small distributed control system (Figure 8).
A universal interface
While the modern control world continues to grapple with advanced concepts such as fieldbus and mesh networks, the simplicity of Modbus and its ease of implementation over so many communication media allow it to remain the most widely supported and implemented industrial protocol in the world. When users of existing legacy control systems discover the need to expand field instrumentation or add remote controllers, they very often turn to Modbus as a simple solution to complex problems. Moreover, when there is a need to connect an exotic device to a control system, using the device’s Modbus interface often proves to be easiest method. Although it is one of the oldest communication methods, it is also the most popular—for very good reasons. It’s easy to use, reliable, inexpensive, and connects to almost every sensing and control device in the control industry.
Jim McConahey is a senior field applications engineer for Moore Industries-International.
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.