Industrial-IOT : Introduction to MODBUS protocol

Hey Folks,

Its been for a while since we talked on Internet of things ! (One year I guess since its 2017 itself  😉 )

So here we are now again , and this time the topic is Introduction to MODBUS protocol !
Again we have three questions , What ? why ? and How ?

So let’s get started ,

What is MODBUS ?

Modbus is a serial communications protocol originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs). Simple and robust, it has since become a de facto standard communication protocol, and it is now a commonly available means of connecting industrial electronic devices.

Since it first appeared in 1979, Modbus has evolved into a broad set of protocols over a variety of physical links (for example, RS-485). At its core, Modbus is a serial communications protocol that follows a master–slave model. A master sends a request to a slave device, and the slave returns a response. In a standard Modbus network, there is one master and up to 247 slaves (although 2 byte addressing can significantly expand this limit).

Why Modbus ?

When it comes to choosing a network for your device, Modbus TCP/IP offers several significant advantages:

  • Simplicity: Modbus TCP/IP simply takes the Modbus instruction set and wraps TCP/IP around it. If you already have a Modbus driver and you understand Ethernet and TCP/IP sockets, you can have a driver up and running and talking to a PC in a few hours. Development costs are exceptionally low. Minimum hardware is required, and development is easy under any operating system.
  • Standard Ethernet: There are no exotic chipsets required and you can use standard PC Ethernet cards to talk to your newly implemented device. As the cost of Ethernet falls, you benefit from the price reduction of the hardware, and as the performance improves from 10 to 100 Mb and soon to 1 Gb, your technology moves with it, protecting your investment. You are no longer tied to one vendor for support, but benefit from the thousands of developers out there who are making Ethernet and the Internet the networking tools of the future. This effort has been complemented opportunely with the assignment of the well-known Ethernet port 502 for the Modbus TCP/IP protocol.
  • Open: The Modbus protocol was transferred from Schneider Electric to the Modbus Organization in April 2004, signaling a commitment to openness. The specification is available free of charge for download, and there are no subsequent licensing fees required for using Modbus or Modbus TCP/IP protocols. Additional sample code, implementation examples, and diagnostics are available on the Modbus TCP toolkit, a free benefit to Modbus Organization members and available for purchase by nonmembers
  • Availability of many devices: Interoperability among different vendors’ devices and compatibility with a large installed base of Modbus-compatible devices makes Modbus an excellent choice.

How it works ?

Modbus Architecture :

There are many types of MODBUS protocols like MODBUS RTU , MODBUS TCP , MODBUS ASCII and many more but we are using MODBUS TCP for our system.

In the architecture of MODBUS there are mainly two things,

  1. Modbus Slave : In general terms, we call it Server, the entity that provides the data, currently we are using a Simulator for this. Actually our Data Collector would work as a Modbus Slave.
  2. Modbus Master: In general terms We call it Client , the entity that consumes data, hence our service will be a client.

This is how Modbus Architecture looks like :


MODBUS may seem complicated and confusing to some, but it is a very simple protocol when you understand how it works.  MODBUS is a request and response protocol.   A MODBUS master will initiate a request and a slave will respond with either an error or the data requested.  This is the simple concept of MODBUS.

 Modbus Message Structure :

So  MODBUS Message Structure looks something like this :


For different other types it looks something like this :


Modbus addressing

The first information in each Modbus message is the address of the receiver. This parameter contains one byte of information. In Modbus/ASCII it is coded with two hexadecimal characters, in Modbus/RTU one byte is used. Valid addresses are in the range 0..247. The values 1..247 are assigned to individual Modbus devices and 0 is used as a broadcast address. Messages sent to the latter address will be accepted by all slaves. A slave always responds to a Modbus message. When responding it uses the same address as the master in the request. In this way the master can see that the device is actually responding to the request.

Within a Modbus device, the holding registers, inputs and outputs are assigned a number between 1 and 10000. One would expect, that the same addresses are used in the Modbus messages to read or set values. Unfortunately this is not the case. In the Modbus messages addresses are used with a value between 0 and 9999. If you want to read the value of output (coil) 18 for example, you have to specify the value 17 in the Modbus query message. More confusing is even, that for input and holding registers an offset must be subtracted from the device address to get the proper address to put in the Modbus message structure. This leads to common mistakes and should be taken care of when designing applications with Modbus. The following table shows the address ranges for coils, inputs and holding registers and the way the address in the Modbus message is calculated given the actual address of the item in the slave device.


Modbus function codes

The second parameter in each Modbus message is the function code. This defines the message type and the type of action required by the slave. The parameter contains one byte of information. In Modbus/ASCII this is coded with two hexadecimal characters, in Modbus/RTU one byte is used. Valid function codes are in the range 1..255. Not all Modbus devices recognize the same set of function codes. The most common codes are discussed here.

Normally, when a Modbus slave answers a response, it uses the same function code as in the request. However, when an error is detected, the highest bit of the function code is turned on. In that way the master can see the difference between success and failure responses.


There is a still lot that we need to know about MODBUS , that you can read by going to the references to this post 🙂

In this series there would be three blogs , this being the first one.

  1. Industrial-IOT : Introduction to MODBUS protocol
  2. Industrial-IOT : A basic Scala implementation for MODBUS Master.
  3. Industrial-IOT  : MODBUS Spark Custom Receiver.

I will add the links accordingly to these blogs.

And yeah I will be writing the Spark-IoT Series soon , sorry for the delay 😉
So be patient and stay connected and tuned 🙂

The next blog will be out soon.

If you want to know anything about me , please visit the link below. You can get in touch with me anytime. Always welcomed 🙂



About the Author :

Shivansh Srivastava , Sr. Software Enginner @ Chirpanywhere Inc. (Scala , Spark , IoT specialist )
Know more :