What is the Modbus?
Modbus is a communication protocol commonly used in industrial automation systems to facilitate communication between electronic devices. The Modbus Protocol was developed in 1979 by Modicon, which is now a part of Schneider Electric. Modbus has become a standard communication protocol in the field of industrial control systems due to its simplicity, versatility, and widespread adoption.
Modbus protocol supports both serial (RS-232, RS-485) and Ethernet communication. It is a master-slave protocol, where a master device (such as a PLC or computer) communicates with one or more slave devices (such as sensors, actuators, or other control devices).
Modbus Protocol Architecture
Modbus Protocol is free and open-source, which means its specifications are publicly available for anyone to use without paying fees. Manufacturers can create their devices to talk to each other using Modbus rules, following the memory mapping and data structures provided by Modbus standards. You can find detailed information, specifications, documentation, and resources on the Modbus Organization.
Modbus Protocol Communication:
- Master-Slave Architecture: Modbus follows a master-slave architecture, where one device (the master) initiates communication and controls the exchange of data, while one or more devices (the slaves) respond to the master’s requests.
- Request-Response Model: Communication in Modbus is based on a simple request-response model. The master sends a request to a slave device, specifying the action to be performed (such as reading or writing data), and the slave responds with the requested data or acknowledgment.
- Function Codes: Modbus defines a set of function codes that specify different types of operations that can be performed, such as reading or writing data registers, reading input status, etc. These function codes are included in the request messages to indicate the desired action.
- Data Encoding: Data exchanged between devices in Modbus is typically encoded in a simple binary format, with numerical values represented in 16-bit or 32-bit formats.
- Error Handling: Modbus includes error checking mechanisms to ensure data integrity during transmission. This may involve CRC (Cyclic Redundancy Check) or LRC (Longitudinal Redundancy Check) checksums to detect transmission errors.
Modbus Protocol Addressing:
- Device Addressing: Each slave device on a Modbus network is assigned a unique address ranging from 1 to 247. The master uses these addresses to identify and communicate with specific slave devices on the network.
- Register Addressing: Modbus organizes data into different types of registers, such as coil registers (binary outputs), discrete input registers (binary inputs), input registers (analog inputs), and holding registers (analog outputs). Each register is identified by a numeric address, which the master uses to access or manipulate the data stored in that register.
- Data Addressing: When sending requests to read or write data, the master specifies the starting address of the data and the number of data points to be read or written. This allows for efficient bulk data transfer and manipulation.
Office Analogy of Master-Slave Architecture
If you are new to Modbus protocol-based devices, you may not fully understand the above explanation of Modbus protocol architecture. Let’s use a network of office cubicles to further simplify the explanation.
Office Cubicle Network:
Imagine a big office building with lots of cubicles (slaves) where employees work, and there’s one main office where the manager sits (the master) overseeing everything.
Cubicle Identification:
Each cubicle is uniquely identified by a number or name, such as Cubicle 1, Cubicle 2, and so forth. This allows for easy reference and communication within the office.
Different Jobs in Each Cubicle:
In each cubicle, there’s someone doing a different job:
- Some control the lights (coils), turning them on or off.
- Others check sensors (discrete inputs) for things like whether a door is open or closed.
- And some keep track of information (registers), like how many pens are left in stock.
Getting Information:
- If the manager wants to know if the lights are on in Cubicle 1, they just ask the person working there.
- Similarly, in Modbus, if the master wants to know something from a specific slave, it just asks that slave directly.
Giving Instructions:
- If the manager needs something done, like turning off the lights in Cubicle 3, they tell the person responsible for lights in Cubicle 3 to do it.
- Likewise, in Modbus, the master device can tell a specific slave device to do something, like changing a setting or turning on a machine.
Making Work Efficient:
- By having everyone in their own cubicle and knowing what job they’re responsible for, the manager can make sure everything runs smoothly.
- Similarly, in Modbus, by giving each device its own address and knowing what type of data it handles, the master can efficiently control and monitor the industrial processes.
Office Analogy of Modbus Protocol.
let’s relate the Modbus protocol to the office cubicle analogy:
Sending Messages in the Office:
- In our office analogy, communication between the boss (master) and employees (slaves) involves sending messages.
- Similarly, in Modbus, communication between the master device and slave devices involves sending messages known as “Modbus frames.”
Modbus Frame Structure:
- A Modbus frame is like a message containing specific information.
- Just like the boss sends a message with instructions to a specific cubicle, the master device sends a Modbus frame with commands or requests to a specific slave device.
Addressing in Modbus:
- In our office analogy, each cubicle has a unique number, which is like the address of a slave device in Modbus.
- When the boss wants to communicate with a specific cubicle, they use its number. Similarly, in Modbus, the master device addresses specific slave devices by their unique addresses.
Function Codes:
- In Modbus, the function code in a frame specifies the type of action to be performed, such as reading data or writing data.
- This is like the instructions the boss gives to each employee in the office. For example, “Check the lights” or “Record the temperature.”
Data Exchange:
- In our office analogy, when an employee receives a message from the boss, they respond with the requested information or carry out the instructed task.
- Similarly, in Modbus, when a slave device receives a Modbus frame from the master device, it responds with the requested data or performs the specified action.
Error Checking:
- In Modbus, error checking mechanisms ensure the integrity of data transmission.
- This is like the boss double-checking that the message they received from an employee makes sense and is accurate before taking any further action.
Modbus Protocol Description.
The Modbus protocol frame structure depends on the variant being used, namely Modbus RTU (Remote Terminal Unit) or Modbus ASCII (American Standard Code for Information Interchange). I’ll describe the frame structure for Modbus RTU, as it’s more commonly used in industrial applications due to its efficiency.
Master Frame Structure:
These are the basic structures for Modbus RTU frames used by both the master and slave devices in a Modbus network. The actual content of the frame (such as the specific function code and data) will vary depending on the communication requirements and the commands being sent between the master and slave devices.
| Slave Address | Function Code | Data | Error Check |
|---|---|---|---|
- Slave Address: 1 byte specifying the address of the slave device the message is intended for.
- Function Code: 1 byte indicating the type of action to be performed by the slave device.
- Data (optional): 0 to 252 bytes containing additional information depending on the function code.
- Error Check: 2 bytes for error checking (e.g., CRC).
- End: 1 byte at the end of the frame indicating the end of the message.
Slave Frame Structure:
| Slave Address | Function Code | Data | Error Check |
|---|---|---|---|
- Slave Address: 1 byte specifying the address of the slave device.
- Function Code: 1 byte indicating the type of action requested by the master.
- Data (optional): 0 to 252 bytes containing additional information depending on the function code.
- Error Check: 2 bytes for error checking (e.g., CRC).
Modbus Protocol - Address Field
The “Address” field in the Modbus RTU frame structure refers to the byte that specifies the address of the target device (slave) or the source device (master) on the Modbus network. This field is a fundamental component of Modbus communication and plays a crucial role in ensuring that messages are correctly routed to the intended recipient
Address Field in Modbus RTU Frame:
Length: The Address field consists of one byte, allowing for a total of 256 possible addresses (0 to 255). This byte is typically represented in hexadecimal notation (0x00 to 0xFF).
Device Identification: The Address byte serves as a unique identifier for each device (slave) on the Modbus network. When a master device initiates communication, it specifies the address of the target slave device to which the message is directed. Similarly, when a slave device responds to a message, it includes its own address in the response.
Broadcast Address: Address 0 (0x00) is reserved for broadcast messages, which are sent to all devices on the Modbus network. Broadcast messages allow a master device to simultaneously communicate with multiple slave devices or to broadcast commands or queries to all devices for specific actions or status requests.
Address Range: Addresses typically range from 1 to 247 (0x01 to 0xF7), with certain addresses reserved for specific purposes or ranges. For example, addresses 1 to 247 are typically used for individual slave devices, while addresses 248 to 255 may be reserved for special functions or broadcast messages.
Address Field Usage:
Master Device: When a master device initiates communication with a slave device, it specifies the address of the target slave in the Address field of the Modbus RTU request frame.
Slave Device: When a slave device responds to a message from the master, it includes its own address in the Address field of the Modbus RTU response frame. This allows the master device to identify the source of the response and correctly process the incoming data.
Modbus Protocol - Function Code Field
The “Function Code” in the Modbus RTU frame structure indicates the type of action to be performed by the target device (slave) or the response type from the slave device. It defines the specific function or operation that the sender requests the recipient to execute or the type of response the sender expects to receive.
Function Code in Modbus RTU Frame:
Length: The Function Code field consists of one byte, allowing for a total of 256 possible function codes (0x00 to 0xFF). Each function code corresponds to a specific Modbus function or operation.
Action Specification: The Function Code byte specifies the type of action or operation that the sender requests the recipient to perform. It determines the nature of the Modbus message and the subsequent data exchange between the master and slave devices.
Function Categories: Modbus function codes are categorized into several groups based on the type of operation they represent. For simplicity, we will only explore the most commonly used ones. Common function code categories include:
Function Categories:
Read Coils (Function Code 0x01):
- This function code is used by the master to request the status of coils (binary outputs) from the slave device.
- The slave responds with the status of the requested coils (e.g., ON/OFF states).
Read Discrete Inputs (Function Code 0x02):
- Similar to Function Code 0x01, but used for reading the status of discrete inputs (binary inputs) from the slave device.
- The slave responds with the status of the requested discrete inputs.
Read Holding Registers (Function Code 0x03):
- This function code is used by the master to request the values of holding registers (16-bit data) from the slave device.
- The slave responds with the values of the requested holding registers.
Read Input Registers (Function Code 0x04):
- Similar to Function Code 0x03, but used for reading the values of input registers (16-bit data) from the slave device.
- The slave responds with the values of the requested input registers.
Write Single Coil (Function Code 0x05):
- This function code is used by the master to write a single coil (binary output) in the slave device.
- The master specifies the coil address and the desired state (ON/OFF) for the coil.
Write Single Register (Function Code 0x06):
- This function code is used by the master to write a single holding register (16-bit data) in the slave device.
- The master specifies the register address and the desired value for the register.
Write Multiple Coils (Function Code 0x0F):
- This function code is used by the master to write multiple coils (binary outputs) in the slave device.
- The master specifies the starting coil address, the number of coils to write, and the states (ON/OFF) for each coil.
Write Multiple Registers (Function Code 0x10):
- This function code is used by the master to write multiple holding registers (16-bit data) in the slave device.
- The master specifies the starting register address, the number of registers to write, and the values for each register.
Function Usage:
Master Device: When a master device initiates communication with a slave device, it specifies the desired function code in the Modbus RTU request frame to indicate the type of operation it wants the slave to perform.
Slave Device: When a slave device receives a Modbus RTU request frame from the master, it examines the function code to determine the requested action. The slave then executes the operation if it is supported and generates an appropriate response.
Modbus Protocol - Data Field
The “Data Field” in the Modbus RTU frame structure contains additional information required for the specific function or operation being performed. It serves as the payload of the Modbus message, carrying parameters, addresses, data values, or other relevant information necessary for executing the requested action.
Data Field in Modbus RTU Frame:
Length and Structure: The Data Field can vary in length and structure depending on the function code specified in the Modbus RTU message. It typically ranges from zero bytes (for certain function codes) to a maximum of 252 bytes, allowing for flexibility in transmitting data.
Content and Purpose: The Data Field contains various types of information, such as register addresses, data values, quantities, or parameters specific to the function being performed. Its content is determined by the function code and the requirements of the operation.
Register Addresses: For read or write operations involving registers (e.g., holding registers or input registers), the Data Field often includes the starting register address or addresses, and in some cases, the number of registers to be read or written.
Data Values: In write operations, the Data Field may contain the data values to be written to the specified registers. These values could represent control signals, setpoints, process variables, or any other relevant data.
Quantities: For functions that involve multiple data points, such as reading or writing multiple registers or coils, the Data Field may include information about the quantity of data elements to be processed.
Error Information: In some cases, the Data Field might include error codes, status flags, or diagnostic information returned by the slave device in response to a request. This information helps the master device understand the outcome of the operation and take appropriate action if necessary.
Formatted Data: The content of the Data Field is often formatted according to the requirements of the specific function code and the data types supported by Modbus. For example, data might be represented in binary, hexadecimal, integer, floating-point, or other formats as appropriate.
Data Field Usage:
Master Device: When a master device initiates communication with a slave device, it includes relevant data in the Data Field of the Modbus RTU request frame to specify the parameters or values associated with the requested operation.
Slave Device: When a slave device receives a Modbus RTU request frame from the master, it examines the Data Field to extract the necessary information required to execute the requested action. The slave then processes the data and generates an appropriate response
Modbus Protocol - Error Check Field
The “Error Check” field in the Modbus RTU frame serves as a mechanism for ensuring data integrity during transmission. It allows the recipient device to detect any errors or corruption that may have occurred in the frame during transmission over the communication channel. The Error Check field typically consists of a cyclic redundancy check (CRC) or a checksum, which are mathematical algorithms used to calculate a value based on the contents of the frame. Here’s a detailed explanation of the Error Check field:
Error Check in Modbus RTU Frame:
CRC (Cyclic Redundancy Check): CRC is a commonly used error-checking technique that calculates a checksum based on the binary contents of the frame. The sender device computes the CRC value using a predefined algorithm and appends it to the frame before transmission. The recipient device performs the same CRC calculation on the received frame and compares the calculated CRC value with the one received in the frame. If the two values match, it indicates that the frame was transmitted without errors. If they do not match, it suggests that an error occurred during transmission, and the frame may be discarded or flagged for retransmission.
Checksum: Alternatively, some Modbus implementations may use a simpler checksum method for error checking. The checksum is computed by summing all the bytes in the frame (excluding the checksum byte itself) and taking the one’s complement (negation) of the result. Like CRC, the sender appends the checksum to the frame, and the recipient recalculates the checksum based on the received frame to verify its integrity.
Error Check Field Usage:
Transmission: When a device sends a Modbus RTU frame over the communication channel, it calculates the CRC or checksum based on the frame’s contents and appends the result to the frame before transmission.
Reception: Upon receiving a Modbus RTU frame, the recipient device performs the same CRC or checksum calculation on the received frame. It then compares the calculated value with the one received in the frame. If the values match, it indicates that the frame was transmitted without errors. Otherwise, an error is detected, and appropriate error-handling mechanisms may be initiated.
Master and Slave Scenario with Modbus Protocol Communication.
Let’s clarify the Modbus Protocol concept with an example Modbus scenario involving communication between a master device and a slave device.
Scenario:
Let’s imagine a simple industrial automation system where a master device (such as a PLC or computer) is communicating with a temperature sensor, acting as the slave device, over a Modbus Protocol (RTU) network. The master device wants to read the temperature values from the sensor and control a heater based on the temperature readings.
Step 1: Setup and Configuration
- The Modbus RTU network is configured with appropriate baud rate, parity, and other settings.
- The master device is configured with the address of the slave device (e.g., address 1 for the temperature sensor).
Step 2: Reading Temperature Values
Master Request (Frame):
- The master device sends a request to the temperature sensor (slave device) to read the temperature values.
- Example Frame:
0x01 0x03 0x00 0x00 0x00 0x01 XX XX - Explanation:
- Slave Address: 0x01 (Address of the temperature sensor)
- Function Code: 0x03 (Read Holding Registers)
- Register Address: 0x0000 (Starting address of the temperature sensor)
- Number of Registers: 0x0001 (Number of registers to read, assuming one register for temperature)
- XX XX: Error check (CRC or checksum)
- Example Frame:
Slave Response (Frame):
- The temperature sensor receives the request, processes it, and responds with the temperature values.
- Example Response Frame:
0x01 0x03 0x02 0x00 0x1A XX XX - Explanation:
- Slave Address: 0x01 (Address of the temperature sensor)
- Function Code: 0x03 (Read Holding Registers)
- Data: 0x0200 0x1A (Temperature value, assuming the temperature is 26.6°C)
- XX XX: Error check (CRC or checksum)
Step 3: Controlling the Heater
Master Request (Frame):
- Based on the temperature readings, the master device decides to turn on or off the heater.
- Example Frame:
0x02 0x05 0x00 0x02 0xFF 0x00 XX XX - Explanation:
- Slave Address: 0x02 (Address of the heater controller)
- Function Code: 0x05 (Write Single Coil)
- Coil Address: 0x0002 (Address of the coil controlling the heater)
- Coil Value: 0xFF00 (Turn on the heater)
- XX XX: Error check (CRC or checksum)
Slave Response (Frame):
- The heater controller (slave device) receives the request, processes it, and acknowledges the action.
- Example Response Frame:
0x02 0x05 0x00 0x02 0xFF 0x00 XX XX - Explanation:
- Slave Address: 0x02 (Address of the heater controller)
- Function Code: 0x05 (Write Single Coil)
- Coil Address: 0x0002 (Address of the coil controlling the heater)
- Coil Value: 0xFF00 (Turn on the heater)
- XX XX: Error check (CRC or checksum)
Key features of Modbus Protocol.
- Simplicity: Modbus Protocol uses a simple and straightforward communication structure, making it easy to implement and troubleshoot.
- Flexibility: It supports various data types and formats, including digital inputs/outputs, analog inputs/outputs, registers, coils, and more.
- Compatibility: Modbus Protocol is supported by a wide range of devices from different manufacturers, promoting interoperability within industrial systems.
- Efficiency: Modbus Protocol is designed for efficient communication over serial lines, making it suitable for use in environments with limited bandwidth or high noise levels.
Overall, Modbus Protocol plays a crucial role in enabling communication and data exchange between different components of industrial control systems, contributing to the automation and efficiency of various industrial processes.
