Using MODBUS for Process Control and Automation (2)

MODBUS RTU Basics

To communicate with a slave device, the master sends a message containing:

• Device Address
• Function Code
• Data
• Error Check

Continued from first part of article Using MODBUS for Process Control and Automation (1)

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-247 are addresses of specific devices. With the exception of broadcast messages, a slave device always responds to a MODBUS message so the master knows the message was received.

Figure 2 – Function Codes

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.

Below would be a common example of how a vendor might logically map different types of process variable data. 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.

Figure 3

The literature or operation manuals of most MODBUS compatible devices, such as this TMZ Temperature Transmitter from Moore Industries, publish the addresses of key variables in the MODBUS Memory Map. The TMZ’s addresses conform to the MODBUS spec.

Data in the memory map is defined in the MODBUS specification. Assuming that the device vendor followed the MODBUS specification (not all do), all data can easily be accessed by the MODBUS 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 MODBUS 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 MODBUS 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.

Connecting MODBUS Devices

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.

For example, the NCS (NET Concentrator System) from Moore Industries allows a user to connect analog and digital signals remotely, which can then be connected to a MODBUS master via twisted pair cable.

Multiple NCS systems can be installed in several locations throughout the 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 the NCS, 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 (at an installed 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-20mA analog I/O and directly wired digital I/O, and reprogramming the old system to accommodate MODBUS data would be difficult. Often, users would 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.

For example, the CCS (Cable Concentrator System) and the NCS (NET Concentrator System) from Moore Industries both have peer-to-peer communication abilities. The NCS and CCS are similar to a distributed I/O module, but have more built-in intelligence and can be set up in either a peer-to-peer or peer-to-host configuration.

Figure 5 – In some cases, the control system is not able to deal with a MODBUS signal. In that case, a peer-to peer solution with two NCS systems simply replaces all the home run wiring with a single MODBUS cable. Analog outputs from the control room NCS are then wired directly into the host system’s I/O card.

With a peer-to-peer NCS system (Figure 5), two concentrators are used: one in the field and one in the control room. Field instruments connect to the remote NCS, which connects to the control room NCS via a single twisted pair wire. Then, outputs from the control room NCS 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.

To be continued…

Resource:  Using MODBUS for Process Control and Automation – Moore Industries