The Modbus protocol is, what many calls, the grandfather of industrial networking. Modbus is, in fact, almost as old as the first PLC (Programmable Logic Controller), the Modicon 084. No wonder, this protocol's unconnected messages, and simple request-response communication structure are now considered unusual among today's technologies.
Modbus-enabled devices are very common among many manufacturers throughout many different industries. In Supervisory Control and Data Acquisition (SCADA) systems, Modbus is commonly used to communicate data and control commands.
If in your SCADA system, you have Modbus protocol connecting your remote equipment to your Remote Terminal Units (RTUs) and to your master station, then it's critical that you understand how this protocol works. This way, you'll have an efficient remote monitoring system.
Here, at DPS, we've provided many different Modbus monitoring solutions throughout our 30+ years in the market. We're experts and it's important to us that you know how to get the most out of your network monitoring system.
So, let's dive into the Modbus RTU protocol.
Modbus RTU is a version of the Modbus open serial protocol. As an open standard protocol, manufacturers can build it into equipment without paying royalties.
Widely used in building management systems and in industrial automation systems to connect electronic devices, Modbus RTU is a popular protocol due to its ease of use and reliability.
Modbus RTU messages are a simple 16-bit structure with a Cyclic-Redundant Checksum (CRC). The simplicity of these messages allows the basic 16-bit Modbus RTU register structure to be used to pack in floating points, tables, ASCII characters, and other data.
This protocol mainly uses RS-232 or RS-485 serial interfaces for communications and is supported by almost every SCADA software in the market today. This makes it easy to integrate Modbus-enabled gear into your existing remote monitoring network.
There are many standard transports used to transmit Modbus protocol messages. RS-232 and RS-485 are the main ones, but you can use others.
Although RS-485 is newer than RS-232, both work in a similar way in terms of synchronizing bits that synchronize the transfer of bits from a sending device to a receiving device.
There are, however, some main points that make RS-485 the preferred way to transport Modbus messages:
The Modbus RTU protocol uses the master/slave structure to transmit data between devices. This means that your Modbus RTU application will have a master station and at least one slave.
A master is typically a supervisory software that will monitor and control slave devices. Slave devices are the equipment deployed at your facilities or remote sites, they gather information and send it to the master and execute the control actions requested by the master.
Each slave has a unique 8-bit device address or unit number. Packets sent by the master include the address of the slave the message is intended for. The slave should respond only if its address is recognized and must respond within a certain time period or the master will call it a "no response" error.
Each exchange of information comprises a request from the master and a response from the slave coming after that. Each data packet, whether request or response, begins with the device address or slave address, followed by the function code, followed by parameters defining what is being asked for or provided.
Like everything else about Modbus, its data representation is fairly simple.
Modbus data types include coils and registers.
Coils are single bits. The bits can be ON (1) or they can be OFF (0). Some coils represent inputs, meaning they contain the status of some physical discrete input. They can also represent outputs, which means that they hold the state of some physical discrete output signal. Coils can be read or written.
Registers are 16-bit pieces of data. Registers can have a value from 0 to 65535. There is no representation for negative values, for values greater than 65535, or for real data.
Registers can be grouped into Input Registers or Holding Registers.
Like Input Coils, Input Registers report the state of some external input as a value between 0 and 65535. The original intent of an Input Register was to show the value of analog inputs. Most Modbus devices today, however, are not I/O devices so Input Registers function just like Holding Registers. Input Registers are read-only.
Holding Registers were initially meant to be temporary program storage for devices like Modbus controllers. Nowadays, Holding Registers act as data storage for devices. Modbus RTU packets are only intended to send data - they don't have the capability to send parameters. Holding Registers can be read or written.
Think about Modbus slave devices as having an internal spreadsheet with numbers. The master station will ask a slave for its data value or number found in a determined row and column, and the slave will respond by sending that piece of information back to the master. This process can also be reserved, with the master telling the slave which number to put into its table in a given row and column.
The columns in a Modbus device's spreadsheet are the register types. Register types may be a coil, a discrete input, an input register, or a holding register.
Now, the rows in that same spreadsheet are the register number. Usually, these start at 1 and count up sequentially. Some equipment might not have a register 1, and their first register may be number 100, for example. If the register number doesn't exist in the slave device, it will send back an error message - known as an exception. The exception gives an error code that says "no such register".
An encoding mechanism describes how bit patterns are formed from the control and data values that are encoded into the packet. The sender and the receiver should use the same encoding to properly understand the contents of the data.
There are two ways of encoding Modbus messages: RTU and ASCII.
In ASCII format, the messages are readable, whereas in RTU format the messages are in binary coding and can't be read while monitoring. RTU messages, however, are a smaller-size, and this allows for more data exchange during the same time frame.
It's important to remember that your Modbus network should have the same transmission style, as Modbus ASCII can't communicate with Modbus RTU and vice versa.
Modbus TCP is a version of the Modbus protocol that encapsulates request and response data packages in a TCP packet transmitted over standard Ethernet networks.
The main difference between Modbus RTU and Modbus TCP (also known as Modbus TCP/IP) is that Modbus TCP needs an Ethernet physical layer to work, while Modbus RTU needs a serial connection. Modbus TCP also uses a 6-byte header to allow routing.
A Modbus RTU master is a single device. It sends a message to an RTU and gets an answer. Modbus RTU is limited to a single master. Only one set of signals can be on the RS-485 link at one time. Either the master is transmitting or the RTU is sending information. Modbus TCP makes the definition of master and slave less obvious as the Ethernet allows peer to peer communication. In other words, there can be multiple masters and multiple slaves.
With Modbus TCP, controllers can much more efficiently use the bandwidth on Ethernet to be the master to hundreds of devices. RS-485 has a limitation of 32 devices, but Ethernet is unlimited.
Also, with Modbus TCP, you need to have a switch in your system. With Modbus RTU, you can just daisy-chain all the devices together.
When making the investment in a remote monitoring device that is Modbus-enabled, it's important to make sure you are getting the right equipment for your network. Here are a few things to keep in mind.
Although Modbus is a fairly simple protocol, knowing all its bits and pieces can be challenging if you have many other tasks to do first. But, don't worry, our team of experts is always a call away to help you design your perfect-fit Modbus monitoring system.
With more than 30 years in the market as a remote monitoring solutions manufacturer, we know what makes an efficient system. We don't pressure you to buy anything, our main goal is simply to make sure you have the best visibility over your network as possible.
Give us a call or send us a message, we are here to help.
Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.
You need to see DPS gear in action. Get a live demo with our engineers.
Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.Reserve Your Seat Today