Implementing Modbus Protocol for Communication Between Microcontrollers and PLCs

The HMI (Human-Machine Interface) is increasingly used in industrial automation systems and devices due to its small size, high performance, and strong real-time capabilities. It features various displays such as letters, Chinese characters, graphics, and images, with a simple and user-friendly interface. Equipped with long-lasting membrane button keyboards, it is easy to operate. Typically, it uses a microcontroller with high integration, fast speed, high reliability, and low cost as its core controller to achieve real-time fast processing. The combination of PLC and microcontroller not only enhances the data processing capability of the PLC but also provides users with a friendly and simple interface. This article discusses in detail how to implement communication between a microcontroller and a PLC using the Modbus communication protocol in a human-machine system, with examples in C51.

The Modbus protocol is a universal language applied to electronic controllers. Through this protocol, controllers can communicate with each other, and controllers can communicate with other devices via the network.

The Modbus protocol provides a master-slave principle, where only one device (the master device) can initiate transmission (query). Other devices (slave devices) respond based on the data provided by the master device’s query.

The format of the master device’s query includes: device address (or broadcast, which does not require a response), function code, all data to be sent, and an error detection field. The response message from the slave device includes the confirmation address, function code, any data to be returned, and an error detection field. If an error occurs during message reception or the slave device cannot execute its command, the slave device will generate an error message and send it as a response.

Controllers can be set to two transmission modes: ASCII and RTU. At the same baud rate, RTU can transmit more data than ASCII, so the RTU mode is used.

(1) Typical RTU Message Frame

The typical RTU message frame is shown in Table 1.

The address field of the RTU message frame contains 8 bits. The possible slave device addresses are 0…127 (decimal). Address 0 is used as a broadcast address so that all slave devices can recognize it. The master device selects the slave device by placing the address of the slave device it wants to contact in the address field of the message. When the slave device sends a response message, it puts its own address into the response’s address field so that the master device knows which device is responding.

The function code field of the RTU message frame contains 8 bits. When the message is sent from the master device to the slave device, the function code field informs the slave device what actions to perform; when the slave device responds, it uses the function code field to indicate whether it is a normal response (no error) or if an error has occurred (known as an exception response, generally by changing the highest bit of the function code from 0 to 1).

The data field of the message sent from the master device to the slave device contains additional information: the information the slave device must use to execute the actions defined by the function code. This includes discontinuous register addresses, the number of items to be processed, and the actual number of data bytes in the field. If no error occurs, the data field returned from the slave device contains the requested data. If an error occurs, this field contains an exception code that the master device application can use to determine the next action.

When using RTU mode for character frames, the error detection field contains a 16-bit value (implemented with two 8-bit characters). The content of the error detection field is derived from cyclic redundancy check (CRC) of the message content. The CRC field is appended to the end of the message, added first as the low byte and then as the high byte.

(2) All Modbus Function Codes

The definitions of Modbus function codes are shown in Table 2.

This article introduces the design of several commonly used Modbus function programs. The author uses a microcontroller as the master, writing programs on the microcontroller to achieve communication between the microcontroller and the PLC. The microcontroller sends command information to the PLC, which automatically responds. The PLC communicates through the serial communication port of the microcontroller, and the program is implemented in C51. The sub-functions of the program and their functionalities are:

(1) Serial Port Initialization

void ProtocolInit(void)

Functionality: Set the serial port to asynchronous communication mode 1 (1 start bit, 8 data bits, 1 stop bit); set timer/counter 1 as baud rate generator, communication rate 9600 bps; enable serial interrupts and set serial interrupts to high priority.

(2) Simple CRC Function

unsigned char Crc16(unsigned char *puchMsg, unsigned char usDataLen)

Functionality: Load a value of all “1” into a 16-bit register, then call a process to process each continuous 8-bit byte from the message with the current value in the register. Each 8-bit character is ORed with the content of the register, and the result is shifted towards the least significant bit, filling the most significant bit with 0. The LSB is extracted for detection; if LSB is 1, the register is ORed with a preset value; if LSB is 0, no operation is performed. This process is repeated 8 times. After completing the last bit (the 8th bit), the next 8-bit byte is ORed with the current value of the register. The final value in the register is the CRC value after processing all bytes in the message.

(3) Initialize Variables

void Initvar(void)

Functionality: Initialize all process variables.

(4) Serial Interrupt Service Program

void ProtocolSerialProcess(void) interrupt 4 using 2

Functionality: Send the command array formed by the master through the interrupt; after sending, set the flag; receive the response array returned by the PLC, store it in the receive array, set the flag, and assume the response is correct, pending processing by the master.

(5) Read N Bits Variable (Coils)

void ProtocolRead_bit(unsigned char DeviceAddr/*PLC Address*/, unsigned char RegType/*Register Type*/, unsigned int BitAddr/*Starting Address*/, unsigned char SubAddr/*Sub Address*/, unsigned int BitNum/*Number of Bits*/)

Functionality: Form a command array to read N bits variable according to function parameters, initiate sending. Wait for completion of sending and receiving (if timeout occurs and not completely received, resend). Analyze the receive array: if correct, save the read data; if incorrect, resend.

(6) Write a Bit Variable

void ProtocolSetBit(unsigned char DeviceAddr/*PLC Address*/, unsigned char RegType/*Register Type*/, unsigned int BitAddr/*Address*/, unsigned char SubAddr/*Sub Address*/, unsigned int ClrSet/*Write Value “1” or “0”*/)

Functionality: Form a command array to set a bit variable to “1” or “0” according to function parameters, initiate sending. Wait for completion of sending and receiving (if timeout occurs and not completely received, resend). Analyze the receive array: if correct, return; if incorrect, resend.

(7) Read N Bytes Variable

void ProtocolReadByte(unsigned char DeviceAddr/*PLC Address*/, unsigned char RegType/*Register Type*/, unsigned int RegAddr/*Starting Address*/, unsigned char SubAddr/*Sub Address*/, unsigned int RegNum/*Number*/)

Functionality: Form a command array to read N bytes variable according to function parameters, initiate sending. Wait for completion of sending and receiving (if timeout occurs and not completely received, resend). Analyze the receive array: if correct, save the read data; if incorrect, resend.

(8) Write N Bytes Variable

void ProtocolSetByte(unsigned char DeviceAddr/*PLC Address*/, unsigned char RegType/*Register Type*/, unsigned int RegAddr/*Starting Address*/, unsigned char SubAddr/*Sub Address*/, unsigned int RegNum/*Number*/)

Functionality: Form a command array to write N bytes variable (the values to write are read from a parameter array) according to function parameters, initiate sending. Wait for completion of sending and receiving (if timeout occurs and not completely received, resend). Analyze the receive array: if correct, return; if incorrect, resend.

The above programs have been tested and applied in practical human-machine systems. Similar methods can be used to write other functional programs to achieve different controls and operations on the PLC. By leveraging the advantages of both the microcontroller and PLC, a networked and intelligent industrial control system can be formed. Additionally, the entire microcontroller system program is written in C51 language, making the program concise, easy to read, and debug. The combination of the microcontroller and the HMI can display the working status of the PLC in real-time, control, set, and adjust the PLC’s operational status in real-time, enhancing the automation and responsiveness of industrial control.