Positiveomg

The Modbus RTU is designed to communicate with any controller that supports the interfaces defined in this document. It is assumed that you have full knowledge of the capabilities and limitations of the controller. Modbus RTU Overview Modbus RTU (Remote Terminal Unit) protocol defines a message structure that controllers will recognise. Master-Slave Communication via Modbus RTU Entry ID: 68202723, V2.0.1, 01/2018 9 t 2018 d The communication with Modbus RTU always occurs according to the following 3 Description of the Modbus RTU Protocol 3.1 Functioning of Modbus RTU Overview Modbus RTU (Remote Terminal Unit) is a standard protocol for serial.

Contents:

1. How to test Modbus ASCII communication?

What is the Modbus ASCII protocol?

Modbus is a serial communication protocol developed by the Modicon corporation in 1979. It was originally designed to be used with the company’s programmable logic controllers (PLCs). Modbus is an open protocol that supports serial devices that use the RS232/RS485/RS422 protocols. Its simplicity and the fact that manufacturers can incorporate it into their products at no charge has helped it become the most popular method of connecting industrial electronic devices.

There are two main styles of transmission that are used when employing the Modbus protocol. They are Modbus RTU and Modbus ASCII. This article is meant to be an advanced Modbus ASCII tutorial. We will start with an overview of Modbus that is pertinent to both the ASCII and RTU implementations of the protocol.

Modbus addresses the issue of sending information between electronic devices over serial lines. The protocol is implemented in an architecture that follows the master/slave model. The Modbus master is in charge of requesting information from the other devices. There is one Modbus master in a standard Modbus Network.

The master requests information from the slave devices, which can number up to 247. Each slave device is identified by a slave address of between 1 and 247. The process by which the master queries the slave and receives information returned from the slave is what is meant by Modbus communication. In addition to requesting information from the slave, the master device can also write to the slave device’s internal registers.

• 01Modbus RTU communication guide
• 03Modbus Decoder: How to analyze Modbus protocol

Serial data is exchanged between devices in bitstreams where each bit is a voltage. Binary data is exchanged with a 1 being denoted by a negative voltage and a zero is represented by a positive voltage.

The Modbus protocol defines function codes and the encoding scheme for transferring data as either single points (1-bit, coils) or as 16-bit data registers. Data packets are encapsulated according to the transmission method in use. The Modbus protocol uses four distinct tables to store data in the slave devices. There are two coils which store discrete on or off values and two registers which store numerical values. In the case of Modbus ASCII, messages are passed using the ASCII character set, making them more easily readable by human eyes.

How to test Modbus ASCII communication with Modbus protocol Analyzer?

If you are working with serial devices and the Modbus protocol there is a good chance that at some point you will need to engage in some debugging or monitoring of your serial data transmission. Modbus Analyzer (Serial Port Monitor) is a dedicated software application developed by Eltima Software that can be used to analyze and diagnose data transmission traveling through your system’s serial interfaces.

In order to better appreciate how a Modbus ASCII test tool like Modbus protocol Analyzer can help you, let’s take a look at the Modbus ASCII data and message format.

Modbus ASCII data format

Modbus ASCII uses the ASCII character set to represent hexadecimal characters that each contain 4 bits of data. There are 10 bits in each byte in Modbus ASCII mode. They consist of:

• 1 start bit
• 7 data bits with the least significant bit sent first
• 1 bit for parity completion
• 1 stop bit

Modbus ASCII message format

The format of Modbus ASCII messages consists of a start character which is a colon “:” and the end of the message is defined by a carriage return and line feed. This enables the space between the messages to be variable and make Modbus ASCII suitable for transmission through certain modems.

Modbus Sniffer software can be extremely helpful in debugging, monitoring, and diagnosing issues in a Modbus network. It can be used in for both Modbus RTU and ASCII implementations.

Using this tool allows you to:

• Analyze serial port activity - You can open any serial port in your system even if it already in use by another application. Use real-time data collection to quickly diagnose issues of all serial port activity.
• Monitor multiple serial ports at one time - A central log file will hold all of your monitored data in a first-in-first-out basis for easier analysis.
• View your data in four different formats - Use these various views singly or in combinations to gain more insight into your data. Table, line, dump, and terminal mode let you view your data in the way that suits your needs.
• Emulation of data transmission - You can emulate data transmission to serial devices in various formats such as string, binary, decimal, and hex.
• Export your monitored data - You can export your data to files in HTML, ASCII text, UNICODE text or Exсel CSV format. New data can be appended to previously saved files.

All told, Modbus Protocol Analyzer is an essential tool for those working with serial devices and the Modbus protocol.

• 01How to parse a Modbus message
• 02Serial communication protocols in embedded systems

What is the difference between Modbus ASCII and RTU?

Both Modbus ASCII and RTU were introduced as part of the original Modbus protocol specification. The two variations use the same master/slave architecture and are very similar. They are both designed to work with serial devices, but are not compatible with each other due to differences that we will discuss below.

The main differentiating factor is that Modbus RTU employs binary coding where the aptly named Modbus ASCII uses the ASCII character set. Modbus RTU performs error-checking using the stringent CRC method whereas Modbus ASCII uses the less effective LRC error-checking method. The data format is also slightly different as the RTU variation uses a start bit, 8 data bits, and a stop bit as opposed to the ASCII data format that we looked at earlier.

The combination of binary coding and CRC error-checking make Modbus RTU suitable to industrial applications as it lends itself to more efficient transmission than the alternative of ASCII characters. When choosing between Modbus RTU vs ASCII, RTU is the first choice if performance is a consideration.

Modbus ASCII vs TCP

There is one more flavor of Modbus to consider and that is Modbus TCP. This is simply an implementation of Modbus that runs over a TCP/IP network. The main difference between Modbus ASCII and Modbus TCP is that the LRC error-checking that is required by Modbus ASCII is performed by the IP layer.

How do you convert Modbus ASCII to the Modbus RTU protocol?

As we mentioned earlier the Modbus ASCII and Modbus RTU protocols are not compatible with each other. Devices employing the two protocols cannot communicate directly with each other. But there are ways to get the devices talking to each other.

To do this you will need to use a hardware solution called a Modbus ASCII to RTU converter. This type of device is basically a translator that reads data from one device and then stores it internally in another protocol for use by the second device. In this way devices using any Modbus variation can communicate with each other.

Serial Port Monitor

Modbus is a serial communications protocol originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de factostandard communication protocol and is now a commonly available means of connecting industrial electronic devices.^[1] The main reasons for the use of Modbus in the industrial environment are:

• developed with industrial applications in mind,
• openly published and royalty-free,
• easy to deploy and maintain,
• moves raw bits or words without placing many restrictions on vendors.

Modbus enables communication among many devices connected to the same network, for example, a system that measures temperature and humidity and communicates the results to a computer. Modbus is often used to connect a supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems. Many of the data types are named from industry usage of Ladder logic and its use in driving relays: a single-bit physical output is called a coil, and a single-bit physical input is called a discrete input or a contact.

The development and update of Modbus protocols has been managed by the Modbus Organization^[2] since April 2004, when Schneider Electric transferred rights to that organization.^[3] The Modbus Organization is an association of users and suppliers of Modbus-compliant devices that advocates for the continued use of the technology.^[4]

• 4Frame formats
  • 4.1All Modbus variants use one of the following frame formats.^[1]
• 6Format of data of requests and responses for main function codes
• 7Coil, discrete input, input register, holding register numbers and addresses

Modbus object types[edit]

The following is a table of object types provided by a Modbus slave device to a Modbus master device:

Protocol versions[edit]

Versions of the Modbus protocol exist for serial port and for Ethernet and other protocols that support the Internet protocol suite. There are many variants of Modbus protocols:

• Modbus RTU — This is used in serial communication and makes use of a compact, binary representation of the data for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. Modbus RTU is the most common implementation available for Modbus. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods.
• Modbus ASCII — This is used in serial communication and makes use of ASCII characters for protocol communication. The ASCII format uses a longitudinal redundancy check checksum. Modbus ASCII messages are framed by leading colon (':') and trailing newline (CR/LF).
• Modbus TCP/IP or Modbus TCP — This is a Modbus variant used for communications over TCP/IP networks, connecting over port 502.^[5] It does not require a checksum calculation, as lower layers already provide checksum protection.
• Modbus over TCP/IP or Modbus over TCP or Modbus RTU/IP — This is a Modbus variant that differs from Modbus TCP in that a checksum is included in the payload as with Modbus RTU.
• Modbus over UDP — Some have experimented with using Modbus over UDP on IP networks, which removes the overheads required for TCP.^[6]
• Modbus Plus (Modbus+, MB+ or MBP) — Modbus Plus is proprietary to Schneider Electric and unlike the other variants, it supports peer-to-peer communications between multiple masters.^[7] It requires a dedicated co-processor to handle fast HDLC-like token rotation. It uses twisted pair at 1 Mbit/s and includes transformer isolation at each node, which makes it transition/edge-triggered instead of voltage/level-triggered. Special hardware is required to connect Modbus Plus to a computer, typically a card made for the ISA, PCI or PCMCIA bus.
• Pemex Modbus — This is an extension of standard Modbus with support for historical and flow data. It was designed for the Pemex oil and gas company for use in process control and never gained widespread adoption.
• Enron Modbus — This is another extension of standard Modbus developed by Enron Corporation with support for 32-bit integer and floating-point variables and historical and flow data. Data types are mapped using standard addresses.^[8] The historical data serves to meet an American Petroleum Institute (API) industry standard for how data should be stored.^{[citation needed]}

Data model and function calls are identical for the first 4 variants of protocols; only the encapsulation is different. However the variants are not interoperable, nor are the frame formats.

Communication and devices[edit]

Each device intended to communicate using Modbus is given a unique address. In serial and MB+ networks, only the node assigned as the Master may initiate a command. On Ethernet, any device can send out a Modbus command, although usually only one master device does so. A Modbus command contains the Modbus address of the device it is intended for (1 to 247). Only the intended device will act on the command, even though other devices might receive it (an exception is specific broadcastable commands sent to node 0, which are acted on but not acknowledged). All Modbus commands contain checksum information to allow the recipient to detect transmission errors. The basic Modbus commands can instruct an RTU to change the value in one of its registers, control or read an I/O port, and command the device to send back one or more values contained in its registers.

There are many modems and gateways that support Modbus, as it is a very simple and often copied protocol. Some of them were specifically designed for this protocol. Different implementations use wireline, wireless communication, such as in the ISM band, and even Short Message Service (SMS) or General Packet Radio Service (GPRS). One of the more common designs of wireless networks makes use of mesh networking. Typical problems that designers have to overcome include high latency and timing issues.

Frame formats[edit]

A Modbus 'frame' consists of an Application Data Unit (ADU), which encapsulates a Protocol Data Unit (PDU):^[9]

• ADU = Address + PDU + Error check,
• PDU = Function code + Data.

All Modbus variants use one of the following frame formats.^[1][edit]

Modbus RTU frame format (primarily used on 8-bit asynchronous lines like EIA-485)[edit]

Note about the CRC:

• Polynomial: x¹⁶ + x¹⁵ + x² + 1 (CRC-16-ANSI also known as CRC-16-IBM, normal hexadecimal algebraic polynomial being 8005 and reversed A001).
• Initial value: 65,535.
• Example of frame in hexadecimal: 01 04 02 FF FF B8 80 (CRC-16-ANSI calculation from 01 to FF gives 80B8, which is transmitted least significant byte first).

Modbus ASCII frame format (primarily used on 7- or 8-bit asynchronous serial lines)[edit]

Address, function, data, and LRC are all capital hexadecimal readable pairs of characters representing 8-bit values (0–255). For example, 122 (7 × 16 + 10) will be represented as 7A.

LRC is calculated as the sum of 8-bit values, negated (two's complement) and encoded as an 8-bit value. Example: if address, function, and data encode as 247, 3, 19, 137, 0, and 10, their sum is 416. Two's complement (−416) trimmed to 8 bits is 96 (e.g. 256 × 2 − 416), which will be represented as 60 in hexadecimal. Hence the following frame: :F7031389000A60<CR><LF>.

Modbus TCP frame format (primarily used on Ethernet networks)[edit]

Unit identifier is used with Modbus/TCP devices that are composites of several Modbus devices, e.g. on Modbus/TCP to Modbus RTU gateways. In such case, the unit identifier tells the Slave Address of the device behind the gateway. Natively Modbus/TCP-capable devices usually ignore the Unit Identifier.

The byte order for values in Modbus data frames is most significant byte of a multi-byte value is sent before the others.[edit]

Supported function codes[edit]

The various reading, writing and other operations are categorised as follows.^[10] The most primitive reads and writes are shown in bold. A number of sources use alternative terminology, for example Force Single Coil where the standard uses Write Single Coil.^[11]
Prominent entities within a Modbus slave are:

• Coils: readable and writable, 1 bit (off/on)
• Discrete Inputs: readable, 1 bit (off/on)
• Input Registers: readable, 16 bits (0 to 65,535), essentially measurements and statuses
• Holding Registers: readable and writable, 16 bits (0 to 65,535), essentially configuration values

Format of data of requests and responses for main function codes[edit]

Requests and responses follow frame formats described above. This section gives details of data formats of most used function codes.

Function code 1 (read coils) and function code 2 (read discrete inputs)[edit]

Request:

• Address of first coil/discrete input to read (16-bit)
• Number of coils/discrete inputs to read (16-bit)

Normal response:

• Number of bytes of coil/discrete input values to follow (8-bit)
• Coil/discrete input values (8 coils/discrete inputs per byte)

Value of each coil/discrete input is binary (0 for off, 1 for on). First requested coil/discrete input is stored as least significant bit of first byte in reply.
If number of coils/discrete inputs is not a multiple of 8, most significant bit(s) of last byte will be stuffed with zeros.
For example, if eleven coils are requested, two bytes of values are needed. Suppose states of those successive coils are on, off, on, off, off, on, on, on, off, on, on, then the response will be 02 E5 06 in hexadecimal.

Because the byte count returned in the reply message is only 8 bits wide and the protocol overhead is 5 bytes, a maximum of 2008 (251 x 8) discrete inputs or coils can be read at once.

Function code 5 (force/write single coil)[edit]

Request:

• Address of coil (16-bit)
• Value to force/write: 0 for off and 65,280 (FF00 in hexadecimal) for on

Normal response: same as request.

Function code 15 (force/write multiple coils)[edit]

Request:

• Address of first coil to force/write (16-bit)
• Number of coils to force/write (16-bit)
• Number of bytes of coil values to follow (8-bit)
• Coil values (8 coil values per byte)

Value of each coil is binary (0 for off, 1 for on). First requested coil is stored as least significant bit of first byte in request.
If number of coils is not a multiple of 8, most significant bit(s) of last byte should be stuffed with zeros. See example for function codes 1 and 2.
Normal response:

• Address of first coil (16-bit)
• number of coils (16-bit)

Function code 4 (read input registers) and function code 3 (read holding registers)[edit]

Request:

• Address of first register to read (16-bit)
• Number of registers to read (16-bit)

Normal response:

• Number of bytes of register values to follow (8-bit)
• Register values (16 bits per register)

Because the number of bytes for register values is 8-bit wide and maximum modbus message size is 256 bytes, only 125 registers for Modbus RTU and 123 registers for Modbus TCP can be read at once.^[12]

Function code 6 (preset/write single holding register)[edit]

Request:

• Address of holding register to preset/write (16-bit)
• New value of the holding register (16-bit)

Normal response: same as request.

Function code 16 (preset/write multiple holding registers)[edit]

Request:

• Address of first holding register to preset/write (16-bit)
• Number of holding registers to preset/write (16-bit)
• Number of bytes of register values to follow (8-bit)
• New values of holding registers (16 bits per register)

Because register values are 2-bytes wide and only 127 bytes worth of values can be sent, only 63 holding registers can be preset/written at once.

Normal response:

• Address of first preset/written holding register (16-bit)
• Number of preset/written holding registers (16-bit)

Exception responses[edit]

For a normal response, slave repeats the function code. Should a slave want to report an error, it will reply with the requested function code plus 128 (hex 0x80) (3 becomes 131 = hex 0x83), and will only include one byte of data, known as the exception code.

Main Modbus exception codes[edit]

Coil, discrete input, input register, holding register numbers and addresses[edit]

Some conventions govern how access to Modbus entities (coils, discrete inputs, input registers, holding registers) are referenced.

It is important to make a distinction between entity number and entity address:

• Entity numbers combine entity type and entity location within their description table.
• Entity address is the starting address, a 16-bit value in the data part of the Modbus frame. As such its range goes from 0 to 65,535

In the traditional standard, numbers for those entities start with a digit, followed by a number of 4 digits in the range 1–9,999:

• coils numbers start with 0 and span from 00001 to 09999,
• discrete input numbers start with 1 and span from 10001 to 19999,
• input register numbers start with 3 and span from 30001 to 39999
• holding register numbers start with 4 and span from 40001 to 49999.

This translates into addresses between 0 and 9,998 in data frames.For example, in order to read holding registers starting at number 40001, corresponding address in the data frame will be 0 with a function code of 3 (as seen above). For holding registers starting at number 40100, address will be 99. Etc.

This limits the number of addresses to 9,999 for each entity. A de facto referencing extends this to the maximum of 65,536.^[13]It simply consists of adding one digit to the previous list:

• coil numbers span from 000001 to 065536,
• discrete input numbers span from 100001 to 165536,
• input register numbers span from 300001 to 365536,
• holding register numbers span from 400001 to 465536.

When using the extended referencing, all number references must have exactly 6 digits. This avoids confusion between coils and other entities. For example, to know the difference between holding register #40001 and coil #40001, if coil #40001 is the target, it must appear as #040001.

JBUS mapping[edit]

Another de facto protocol closely related to Modbus appeared after it, and was defined by PLC brand April Automates, the result of a collaborative effort between French companies Renault Automation and Merlin Gerin et Cie in 1985: JBUS. Differences between Modbus and JBUS at that time (number of entities, slave stations) are now irrelevant as this protocol almost disappeared with the April PLC series which AEG Schneider Automation bought in 1994 and then made obsolete. However the name JBUS has survived to some extent.

JBUS supports function codes 1, 2, 3, 4, 5, 6, 15, and 16 and thus all the entities described above. However numbering is different with JBUS:

Modbus Rtu Vs Tcp Pdf

• Number and address coincide: entity #x has address x in the data frame.
• Consequently, entity number does not include the entity type. For example, holding register #40010 in Modbus will be holding register #9, located at address 9 in JBUS.
• Number 0 (and thus address 0) is not supported. Slave should not implement any real data at this number and address and it can return a null value or throw an error when requested.

Implementations[edit]

Almost all implementations have variations from the official standard. Different varieties might not communicate correctly between equipment of different suppliers. Some of the most common variations are:

• Data types
  • IEEE floating-point number
  • 32-bit integer
  • 8-bit data
  • Mixed data types
  • Bit fields in integers
  • Multipliers to change data to/from integer. 10, 100, 1000, 256 ...
• Protocol extensions
  • 16-bit slave addresses
  • 32-bit data size (1 address = 32 bits of data returned)
  • Word-swapped data

Limitations[edit]

• Since Modbus was designed in the late 1970s to communicate to programmable logic controllers, the number of data types is limited to those understood by PLCs at the time. Large binary objects are not supported.
• No standard way exists for a node to find the description of a data object, for example, to determine whether a register value represents a temperature between 30 and 175 degrees.
• Since Modbus is a master/slave protocol, there is no way for a field device to 'report by exception' (except over Ethernet TCP/IP, called open-mbus) – the master node must routinely poll each field device and look for changes in the data. This consumes bandwidth and network time in applications where bandwidth may be expensive, such as over a low-bit-rate radio link.
• Modbus is restricted to addressing 254 devices on one data link, which limits the number of field devices that may be connected to a master station (once again, Ethernet TCP/IP being an exception).
• Modbus transmissions must be contiguous, which limits the types of remote communications devices to those that can buffer data to avoid gaps in the transmission.
• Modbus protocol itself provides no security against unauthorized commands or interception of data.^[14]

Trade group[edit]

Modbus Organization, Inc. is a trade association for the promotion and development of Modbus protocol.^[2]

Modbus Plus[edit]

Despite the name, Modbus Plus^[15] is not a variant of Modbus. It is a different protocol, involving token passing.

It is a proprietary specification of Schneider Electric, though it is unpublished rather than patented. It is normally implemented using a custom chipset available only to partners of Schneider.

Modbus Rtu Source Code

References[edit]

1. ^ ^abDrury, Bill (2009). Control Techniques Drives and Controls Handbook(PDF) (2nd ed.). Institution of Engineering and Technology. pp. 508–.
2. ^ ^ab'Modbus home page'. Modbus. Modbus Organization, Inc. Retrieved 2 August 2013.
3. ^'Modbus FAQ'. Modbus. Modbus Organization, Inc. Retrieved 1 November 2012.
4. ^'About Modbus Organization'. Modbus. Modbus Organization, Inc. Retrieved 8 November 2012.
5. ^Modbus Messaging on TCP/IP Implementation Guide V1.0b(PDF), Modbus Organization, Inc., October 24, 2006, retrieved 2017-01-07
6. ^'Java Modbus Library - About'. 2010. Retrieved 2017-02-07.
7. ^'What is the difference between Modbus and Modbus Plus?'. Schneider Electric. Retrieved 2017-02-07.
8. ^'Simply Modbus - About Enron Modbus'. Simply Modbus. Retrieved 2017-02-07.
9. ^'Modbus Messaging On TCP/IP Implementation Guide'(PDF). Modbus Organization. Modbus-IDA.
10. ^'Modbus Application Protocol V1.1b3'(PDF). Modbus. Modbus Organization, Inc. Retrieved 2 August 2013.
11. ^Clarke, Gordon; Reynders, Deon (2004). Practical Modern Scada Protocols: Dnp3, 60870.5 and Related Systems. Newnes. pp. 47–51. ISBN0-7506-5799-5.
12. ^http://modbus.org/docs/PI_MBUS_300.pdf
13. ^'Modbus 101 – Introduction to Modbus'. Control Solutions, Inc.
14. ^Palmer; Shenoi, Sujeet, eds. (23–25 March 2009). Critical Infrastructure Protection III. Third IFIP WG 11. 10 International Conference. Hanover, New Hampshire: Springer. p. 87. ISBN3-642-04797-1.
15. ^'Modbus Plus - Modbus Plus Network - Products overview - Schneider Electric United States'. Schneider-electric.com. Retrieved 2014-01-03.

See also[edit]

External links[edit]

Specification

• Modbus Protocol; Modicon; 74 pages; 2000.

Other

• Modbus Protocol tutorial for beginners RF Wireless World