Skip to main content

Understanding Modbus RTU

Alec Vaughn
  • Updated

What is Modbus?

Modbus is an application layer protocol designed for client/server communication. The protocol is designed around requests and replies, and it offers services defined by function codes. The protocol can be utilized through both TCP and serial line communications where port 502 is reserved for Modbus TCP communication and serial line communication relies on the data link layer of the OSI Model to implement an additional Master/Slave protocol on top of the application layer protocol.

 

Master/Slave Protocol

This Data Link layer protocol allows clients and servers to be defined during a serial line implementation. In a serial bus of devices, one Master device is expected to be connected with one or more Slave devices/nodes. The application protocol is expected to recognize the Master device as the client. Its connected nodes are defined as individual servers. This is because the Master device is solely responsible for communicating requests to individual nodes while the nodes themselves only focus on gathering their own sets of data. When serial line communication is chosen over TCP, one of two transmission modes must be selected across the serial bus of devices:

  • Remote Terminal Unit (RTU) mode
  • ASCII mode 

What is Remote Terminal Unit (RTU) Mode?

Remote Terminal Unit mode is the primary transmission mode for Modbus serial communication. This is because - compared to the alternative mode, ASCII - it allows greater data throughput due to its message framing structure containing a continuous stream of characters. It is also a hard requirement to implement RTU for Modbus serial devices since only one transmission mode can be selected at a time across all nodes for data exchange to work properly. 

 

RTU Message Frame

The RTU message frames can be defined as a protocol data unit (PDU) that contains a Function Code and a Data field. The application data unit (ADU) is then built by the client (Ignition) that initiates a Modbus transaction and is mapped to the PDU. The ADU can introduce additional fields, such as Additional Addresses and Error Check fields. 

Modbus Transaction

During an error free transaction the server simply responds with the same function code requested by the client and the data response. If an error occurs, the server responds with the Exception Function code followed by  a specific Exception code. 

Request with an Expected Response: 

Request with Exception Response: 

Modbus Data Model

The Modbus data model contains two data types: coils and registers. A coil represents a single bit to signify either ON (1) or OFF (0). A register is represented as a single word or a 16-bit/2 byte data unit. Each coil and register in the device’s memory can be referenced using an index of unsigned integers ranging from 0 to 65535.

Applications can impose representations for these types of data. For example, Ignition has a way to combine two consecutive registers with a float conversion in order to represent a 32-bit float value. 

The Modbus data model uses these data types to define the four primary tables: Discrete Input, Coils, Input Registers and Holding Registers.

 

Primary Tables Object Type Type
Discrete Input Single bit Read-Only
Coils Single bit Read-Write
Input Registers 16-bit word Read-Only
Holding Registers 16-bit word Read-Write

 

Modbus Addressing Model

The addressing model that exists in current Modbus protocol standards can be visualized as:

Address = Area + Offset

This structure is originally known as Modicon notation. This notation is a convention that was established for the first Modbus devices and may vary in terms of terminology across different user documentation. Additionally, this syntax is not explicitly encoded in PDUs of modern requests, but allows a quick translation of any data type’s index you’re looking for.

 

Offset Variations

6-Digit Range

Below is an expansion of the previously mentioned range of address spaces, 0 - 65535, that exists across each unique data type: 

  • 0x = Area: Status Coil (Discretes Input), offset ranges from 000001 to 065535
  • 1x = Area: Input Coil (Coils), offset ranges from 100001 to 165535
  • 3x = Area: Input Register, offset ranges from 300001 to 365535
  • 4x = Area: Holding Register, offset ranges from 400001 to 465535

The 6-digit set of integers is to accommodate both the data type value (0-4) and the address space range (00001-65635). 

 

5-Digit Range

There also exists a 5-digit variation for Modbus manufacturers where the address range is reduced to 0 - 9999:

  • 0x = Area: Status Coil (Discretes Input), offset ranges from 00001 to 09999
  • 1x = Area: Input Coil (Coils), offset ranges from 10001 to 19999
  • 3x = Area: Input Register, offset ranges from 30001 to 39999
  • 4x = Area: Holding Register, offset ranges from 40001 to 49999

The important takeaway from this comparison is the Ignition driver’s ability to accommodate any digit variation (1 to n, where n is the highest offset index allowed for the device), as long as the specified area and offset stay consistent in its addressing structure, regardless of varying Modbus servers/devices and their documentation. 

 

Other Addressing Variations

Zero-Based Addressing

The offset address ranges shown above assumes that a client is requesting from a server from an area where valid offset indices range from 1 to n. Some Modbus manufactures may take an offset in a PDU request and subtract one off the integer itself before locating the data you’re looking for. 

Ignition by default uses a unit ID of 0. The unit ID will be specified in the addressing. A single Modbus driver connection can be used to reference multiple Unit IDs by connecting to a Modbus Gateway. Refer to the Ignition User Manual for more information regarding Modbus Addressing in Ignition. 

 

The Ignition Modbus Driver

The Ignition Modbus driver provides three device connection options:

  • Modbus TCP
  • Modbus RTU over TCP
  • Modbus RTU (Serial)

It’s important to remember the differences in these options only refer to the type of connection that will be established between client and server. Requests and their optimization are implemented the same in terms of their PDU (function codes and data), while their means of transport (frame structure and communication layers) can vary. 

You may also notice the terminology master and slave used to define a Modbus setup. In the context of communications involving serial line RTU, Ignition and its driver are implemented to be the Modbus master (Client) while any device connections using this protocol are recognized as Modbus slaves (Server). This is also why there are cases where a unit ID will sometimes be referred to as a slave ID.

 

Modbus RTU over TCP

Modbus RTU over TCP is the implementation of the Modbus protocol over Ethernet where RTU mode is expected to be enabled in your device’s transmission of data. The connection will be attempted using the device’s IP address. Ignition is referred to as the Modbus TCP Client and the device is the Modbus Server. While very similar to Modbus TCP in setup, framing structure for requests encapsulating the PDU are expected to be different and can lead to device connection errors if overlooked.

This option may need to be considered when Modbus TCP is unsuccessful and you are unsure about the details of your device. In scenarios where an IP address is provided but additional context of the device implementation is unknown, consider attempting to connect using this option. A Modbus Gateway has the ability to communicate with devices using either direct TCP connections or RTU.  

 

Modbus RTU (Serial)

Modbus RTU implements the Modbus protocol over a serial connection, which is the closest setup Ignition can provide for a classic serial line Modbus communication where RTU mode is involved. Within Ignition, before version 8.1.20 this required the Serial Support Gateway module. For versions 8.1.20 and higher, serial native libraries are provided on the Ignition platform itself without any additional module installations. This is the only option that requires a physical connection between the Ignition server and your device, which is why you will notice the first property requiring the name of a serial port.

 

Troubleshooting Tips

Exception Responses

Earlier we mentioned that if an error occurs during a Modbus transaction, the server responds with the Exception Function code and then a specific Exception code. Below is a list of exception codes and their meaning:

Code - Name Meaning 
01 - ILLEGAL FUNCTION  The function code received in the query is not an allowable action for the server. This may be because the function code is only applicable to newer devices, and was not implemented in the unit selected. It could also indicate that the server is in the wrong state to process a request of this type, for example because it is unconfigured and is being asked to return register values.
02 - ILLEGAL DATA ADDRESS  The data address received in the query is not an allowable address for the server. More specifically, the combination of reference number and transfer length is invalid. For a controller with 100 registers, the PDU addresses the first register as 0, and the last one as 99. If a request is submitted with a starting register address of 96 and a quantity of registers of 4, then this request will successfully operate (address-wise at least) on registers 96, 97, 98, 99. If a request is submitted with a starting register address of 96 and a quantity of registers of 5, then this request will fail with Exception Code 0x02 “Illegal Data Address” since it attempts to operate on registers 96, 97, 98, 99 and 100, and there is no register with address 100.
03 - ILLEGAL DATA VALUE A value contained in the query data field is not an allowable value for the server. This indicates a fault in the structure of the remainder of a complex request, such as that the implied length is incorrect. It specifically does NOT mean that a data item submitted for storage in a register has a value outside the expectation of the application program, since the MODBUS protocol is unaware of the significance of any particular value of any particular register.
04 - SERVER DEVICE FAILURE An unrecoverable error occurred while the server was attempting to perform the requested action.
05 - ACKNOWLEDGE Specialized use in conjunction with programming commands. The server has accepted the request and is processing it, but a long duration of time will be required to do so. This response is returned to prevent a timeout error from occurring in the client. The client can next issue a Poll Program Complete message to determine if processing is completed.
06 - SERVER DEVICE BUSY Specialized use in conjunction with programming commands. The server is engaged in processing a long– duration program command. The client should retransmit the message later when the server is free.
08 - MEMORY PARITY ERROR Specialized use in conjunction with function codes 20 and 21 and reference type 6, to indicate that the extended file area failed to pass a consistency check. The server attempted to read a record file, but detected a parity error in the memory. The client can retry the request, but service may be required MODBUS Application Protocol Specification V1.1b3 Modbus April 26, 2012 http://www.modbus.org 49/50 on the server device.
0A - GATEWAY PATH UNAVAILABLE Specialized use in conjunction with gateways, indicates that the gateway was unable to allocate an internal communication path from the input port to the output port for processing the request. Usually means that the gateway is misconfigured or overloaded.
0B - GATEWAY TARGET DEVICE FAILED TO RESPOND Specialized use in conjunction with gateways, indicates that no response was obtained from the target device. Usually means that the device is not present on the network.

 

Third Party Modbus Applications

Below are a few resources that can assist you with testing & simulating Modbus device connections and reading protocol data:

Was this article helpful?
1 out of 2 found this helpful
Return to top

Related articles

Comments

0 comments

Article is closed for comments.

This article has 0 comments.