Modbus Industrial Network Protocol)

About Modbus communication protocol

 

Introduction:

Industrial Control has moved from single-Host Control to centralized monitoring and distributed control. Now it is in the network era, and the connected network of industrial controller provides convenience for network management. Modbus is one of the network protocols of industrial controllers.
1. Introduction to Modbus protocol
Modbus protocol is a common language used in electronic controllers. Through this protocol, controllers can communicate with each other, and controllers can communicate with other devices over the network (such as Ethernet. It has become a general industrial standard. With it, the control devices produced by different manufacturers can be connected to an industrial network for centralized monitoring. This Protocol defines a message structure that a controller can recognize, regardless of the network through which they communicate. It describes the process of a Controller requesting access to other devices. If a request from another device is returned, how can an error be detected and recorded. It develops the message domain pattern and the public format of the content.
When a Modbus network is connected, this protocol determines that each controller needs to know their device address, identify messages sent by address, and decide what action to take. If a response is required, the Controller generates the feedback and sends the feedback using Modbus protocol. On other networks, messages that contain the Modbus protocol are converted to the frame or package structure used on the network. This type of conversion also extends the Methods for Solving Node addresses, routing paths, and error detection based on the specific network.
1. Transfer Data on MODBUS Network
The standard Modbus port is a RS-232C-compatible serial interface, which defines the Connector pins, cables, signal bits, Transmission baud rate, parity. The controller can be connected directly or through modem.
Controller communication uses the master-slave technology, that is, only one device (master device) can initiate transmission (query ). Other devices (from devices) respond accordingly based on the data provided by the primary device. Typical main device: Host and programmable instrument. Typical slave device: programmable controller.
The master device can communicate with the slave device separately or broadcast to all slave devices. If the communication is performed independently, a message is returned from the device as a response. If the communication is queried in broadcast mode, no response is returned. The Modbus protocol establishes the format of the master device query: device (or broadcast) Address, function code, all data to be sent, an error detection domain.
The Response Message from the device also consists of the Modbus protocol, including the domain to be acted upon, any data to be returned, and an error detection domain. If an error occurs during message receiving or the slave device cannot execute its command, the slave device establishes an error message and sends it as a response.
2. Switch to another network type
In other networks, controllers use peer-to-peer communication technology, so any control can communicate with other controllers. In this way, the controller can be either the master device or the slave device in a separate communication process. Multiple internal channels are provided to allow simultaneous transmission processes.
In the message bit, the Modbus protocol still provides the master-slave principle, although the network communication method is "peer-to-peer ". If a controller sends a message, it serves only as the master device and expects a response from the slave device. Similarly, when the Controller receives a message, it establishes a response format from the device and returns it to the sent controller.
3. query-response cycle
(1) Query
Query the function code in the message to indicate the feature to be executed by the selected slave device. The data segment contains any additional information about the feature to be executed from the device. For example, function code 03 requires reading and holding registers from the device and returning their content. The data segment must contain information from the device: Where to start reading and the number of registers to read. The error detection domain provides a way for the slave device to verify that the message content is correct.
(2) Response
If a normal response is generated from the device, the functional code in the response message is a response to the functional code in the query message. The data segment includes the data collected from the device, such as the register value or status. If an error occurs, the function code is modified to indicate that the response message is incorrect, and the data segment contains the code that describes the error message. The error detection domain allows the primary device to check whether the message content is available.
 
2. Two transmission modes
The controller can be set to any of the two transmission modes (ASCII or RTU) for standard Modbus network communication. The user selects the desired mode, including serial communication parameters (baud rate, Verification Mode, etc.). When configuring each controller, all devices on a Modbus network must select the same transmission mode and serial port parameters.
The ascii or RTU method is only applicable to standard Modbus networks. It defines each bit of the continuously transmitted message segment on these networks, and decide how to package the information into a message domain and how to decode it.
Modbus messages on other networks (such as map and Modbus plus) are converted into frames unrelated to serial transmission.
1. ASCII mode
When the controller is set to communicate in the Modbus network in ASCII (American Standard Information Exchange Code) mode, each 8-bit byte in the message is sent as two ASCII characters. The main advantage of this method is that the interval between sending characters can reach 1 second without generating an error. Code System
· Hexadecimal, ASCII characters 0... 9, a... f
· Each ASCII character in a message is a hexadecimal character
Bit of each byte
· 1 start position
· Seven data bits, with the minimum valid bits sent first
· One parity bit. If there is no parity, no
The CRC field contains two bytes that contain a 16-bit binary value. It is calculated by the transmission device and then added to the message. The receiving device recalculates the CRC value of the received message and compares it with the value in the received CRC Field. If the two values are different, the error occurs.
CRC is to first call a 16-bit register with a full value of "1", and then call a process to process the values in the current registers of the eight consecutive bytes in the message. Only 8-bit data in each character is valid for CRC, and the Start and Stop bits and parity bits are invalid.
During CRC generation, each 8-bit character is independent of the register content or (or). The result is moved to the lowest valid bit direction, and the highest valid bit is filled with 0. LSB is extracted for detection. If LSB is 1, the register is independent of the preset value or a bit. If LSB is 0, no. The entire process must be repeated eight times. After the last bit (8th bits) is complete, the next 8 bits are separately or the current value of the Register. The value in the final register is the CRC value after all the bytes in the message are executed.
When CRC is added to a message, the low byte is added first, and then the high byte is added.
A simple CRC function is as follows:
Unsigned short crc16 (puchmsg, usdatalen)
Unsigned char * puchmsg;/* message for CRC verification */
Unsigned short usdatalen;/* number of bytes in the message */
{
Unsigned char uchcrchi = 0xff;/* High CRC bytes initialization */
Unsigned char uchcrclo = 0xff;/* low CRC bytes initialization */
Unsigned uindex;/* index in CRC loop */
While (usdatalen --)/* Transmit message buffer */
{
Uindex = uchcrchi ^ * puchmsgg ++;/* calculate CRC */
Uchcrchi = uchcrclo ^ auchcrchi [uindex };
Uchcrclo = auchcrclo [uindex];
}
Return (uchcrchi <8 | uchcrclo );
}
/* CRC high byte value table */
Static unsigned char auchcrchi [] = {
0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x01, 0xc0,
0x80, 0x41, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41,
0x00, 0xc1, 0x81, 0x40, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0,
0x80, 0x41, 0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1, 0x81, 0x40,
0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1,
0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x01, 0xc0, 0x80, 0x41,
0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1,
0x81, 0x40, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41,
0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x01, 0xc0,
0x80, 0x41, 0x00, 0xc1, 0x81, 0x40, 0x00, 0xc1, 0x81, 0x40,
0x01, 0xc0, 0x80, 0x41, 0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1,
0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1, 0x81, 0x40,
0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x01, 0xc0,
0x80, 0x41, 0x00, 0xc1, 0x81, 0x40, 0x00, 0xc1, 0x81, 0x40,
0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0,
0x80, 0x41, 0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1, 0x81, 0x40,
0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x01, 0xc0,
0x80, 0x41, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41,
0x00, 0xc1, 0x81, 0x40, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0,
0x80, 0x41, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41,
0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0,
0x80, 0x41, 0x00, 0xc1, 0x81, 0x40, 0x00, 0xc1, 0x81, 0x40,
0x01, 0xc0, 0x80, 0x41, 0x01, 0xc0, 0x80, 0x41, 0x00, 0xc1,
0x81, 0x40, 0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41,
0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41, 0x01, 0xc0,
0x80, 0x41, 0x00, 0xc1, 0x81, 0x40
};
/* CRC low byte value table */
Static char auchcrclo [] = {
0x00, 0xc0, 0xc1, 0x01, 0xc3, 0x03, 0x02, 0xc2, 0xc6, 0x06,
0x07, 0xc7, 0x05, 0xc5, 0xc4, 0x04, 0xcc, 0x0c, 0x0d, 0xcd,
0x0f, 0xcf, 0xce, 0x0e, 0x0a, 0xca, 0xcb, 0x0b, 0xc9, 0x09,
0x08, 0xc8, 0xd8, 0x18, 0x19, 0xd9, 0x1b, 0xdb, 0xda, 0x1a,
0x1e, 0xde, 0xdf, 0x1f, 0xdd, 0x1d, 0x1c, 0xdc, 0x14, 0xd4,
0xd5, 0x15, 0xd7, 0x17, 0x16, 0xd6, 0xd2, 0x12, 0x13, 0xd3,
0x11, 0xd1, 0xd0, 0x10, 0xf0, 0x30, 0x31, 0xf1, 0x33, 0xf3,
0xf2, 0x32, 0x36, 0xf6, 0xf7, 0x37, 0xf5, 0x35, 0x34, 0xf4,
0x3c, 0xfc, 0xfd, 0x3d, 0xff, 0x3f, 0x3e, 0xfe, 0xfa, 0x3a,
0x3b, 0xfb, 0x39, 0xf9, 0xf8, 0x38, 0x28, 0xe8, 0xe9, 0x29,
0xeb, 0x2b, 0x2a, 0xea, 0xEE, 0x2e, 0x2f, 0xef, 0x2d, 0xed,
0xec, 0x2c, 0xe4, 0x24, 0x25, 0xe5, 0x27, 0xe7, 0xe6, 0x26,
0x22, 0xe2, 0xe3, 0x23, 0xe1, 0x21, 0x20, 0xe0, 0xa0, 0x60,
0x61, 0xa1, 0x63, 0xa3, 0xa2, 0x62, 0x66, 0xa6, 0xa7, 0x67,
0xa5, 0x65, 0x64, 0xa4, 0x6c, 0xac, 0xad, 0x6d, 0xaf, 0x6f,
0x6e, 0xae, 0xaa, 0x6a, 0x6b, 0xab, 0x69, 0xa9, 0xa8, 0x68,
0x78, 0xb8, 0xb9, 0x79, 0xbb, 0x7b, 0x7a, 0xba, 0xbe, 0x7e,
0x7f, 0xbf, 0x7d, 0xbd, 0xbc, 0x7c, 0xb4, 0x74, 0x75, 0xb5,
0x77, 0xb7, 0xb6, 0x76, 0x72, 0xb2, 0xb3, 0x73, 0xb1, 0x71,
0x70, 0xb0, 0x50, 0x90, 0x91, 0x51, 0x93, 0x53, 0x52, 0x92,
0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9c, 0x5c,
0x5d, 0x9d, 0x5f, 0x9f, 0x9e, 0x5e, 0x5a, 0x9a, 0x9b, 0x5b,
0x99, 0x59, 0x58, 0x98, 0x88, 0x48, 0x49, 0x89, 0x4b, 0x8b,
0x8a, 0x4a, 0x4e, 0x8e, 0x8f, 0x4f, 0x8d, 0x4d, 0x4c, 0x8c,
0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42,
0x43, 0x83, 0x41, 0x81, 0x80, 0x40
};
Modbus network is an industrial communication system, which is composed of programmable controllers with smart terminals and computers connected through public lines or local dedicated lines. The system structure includes both hardware and software. It can be applied to various data collection and process monitoring. The following table 1 defines the Modbus function code.
Table 1 Modbus Function Code
01 read coil status
02 read input status
03 read holding register
04 read input register
05 write single coil
06 write Single Register
15 write multiple Coil
16 write multiple register
Modbus network is only a host, and all communications are sent by him. The network can support as many as 247 remote slave controllers, but the actual number of slaves is determined by the communication device used. With this system, each PC can exchange information with the central host without affecting each PC to execute its own control tasks.
(1) Modbus Transmission Mode
There are two transmission modes available in the Modbus system. The two transmission modes have the same capabilities as the slave PC communication. The selection depends on the Modbus host used. Each Modbus system can only use one mode, but cannot use both modes. One mode is ASCII (US Information Exchange Code), and the other mode is RTU (Remote Terminal Device). The definitions of these two modes are shown in table 3.
Table 3 ASCII and RTU transmission modes
 
ASCII printable characters facilitate Fault Detection and are suitable for Primary computers and primary PCs programmed in advanced languages such as fortan. RTU is applicable to computer and PC hosts programmed in machine language.
The data transmitted in RTU mode is 8-bit binary characters. To convert to the ASCII mode, each RTU character must be divided into two parts: High and Low. Each of these two parts contains four digits, and then converted to a hexadecimal value. ASCII characters used to form packets are hexadecimal characters. Although the characters used in the ASCII mode are twice that in the RTU mode, it is easier to translate and process the ASCII data. In addition, the characters in the RTU mode must be transmitted as continuous data streams, in ASCII mode, characters can be separated by 1 s to adapt to faster machines.

(2) Modbus data verification method
CRC-16 (Cyclic Redundancy error check)
The CRC-16 error check program is as follows: Packet (only data bit, not the start bit, stop bit and optional parity bit) is considered as a continuous binary, its maximum valid bit (MSB) preferred sending. The packet is first multiplied by x 16 (16 digits left), and then x 16 + x 15 + X 2 + 1 division, X percentile 16 + x percentile 15 + x percentile 2 + 1 can be expressed as 11000000000000101 binary numbers. Ignore and ignore integer business bits. The 16-bit remainder is added to the message (sent first by MSB), which becomes two CRC verification bytes. Initialize all the values of 1 in the remainder to prevent all zeros from being received. After the preceding processing, if there is no error in the CRC packet, the received device is then divided by the same polynomial (x 16 + x 15 + X 2 + 1, A zero remainder is obtained (the receiving device verifies this CRC byte and compares it with the transmitted CRC ). All operations take 2 as the modulo (without carry ).
Devices that are used to sending data in strings will first send the rightmost character (LSB-least valid bit ). In the case of CRC generation, the highest effective bit MSB of the dividend should be sent first. Because carry is not used in the operation, MSB is set to the rightmost bits for the convenience of the operation. The order of the generated polynomials must also be reversed to maintain consistency. The MSB of polynomial is omitted, because it only affects the business and does not affect the remainder.
The steps to generate a CRC-16 validation byte are as follows:
(1) A 16-bit register where all digits are 1.
② The high byte of the 16-bit register and the start 8-bit byte perform the "XOR" operation. Put the calculation result into this 16-bit register.
③ Shift the 16 register to the right.
④ If the number of digits removed from the right (flag bit) is 1, the polynomial 1010000000000001 is generated and the register is "exclusive or". If the number of digits removed from the right is 0, return ③.
⑤ Repeat ③ and ④ until 8 digits are removed.
⑥ The other 8 bits perform the "XOR" operation with the 16-bit register.
7. Repeat ③ ~ (6) until all the bytes in the message are "exclusive or" with the 16-bit register, and the value is shifted 8 times.
The contents of the ⑧ 16-bit register are two-byte CRC error checks, which are added to the maximum valid bit of the message.
In addition, crc16 is often used as the verification method in some non-Modbus communication protocols, and some crc16 variants are generated, they use the crc16 polynomial x percentile 16 + x percentile 15 + x percentile 2 + 1, and the first 16-bit register to be loaded is 0000; use the reverse order of crc16 x 0000 + x 14 + X 1 + 1 and load the register value or ffffh for the first time.
LRC (vertical redundancy error check)
LRC error verification is used in ASCII mode. This error check is an 8-bit binary number, which can be transmitted as two ASCII hexadecimal bytes. Convert the hexadecimal character to binary, and add the binary character without cyclic carry and the binary complement result to generate LRC error verification (see the figure ). The LRC is verified on the receiving device and compared with the transmitted LRC, including the colon (:), carriage return (CR), and line feed (LF) and any other non-ASCII hexadecimal characters entered are not counted During computation.

2.Application of Modbus protocol in singnylan SCADA System

Abstract:
Industrial Control has entered the Internet era. In today's era of competition between industrial control technologies and industrial control products, communication between different devices has become the key to a system. Modbus industrial network protocol is a powerful tool to solve this problem. This paper briefly describes the basic principles of Modbus protocol, and introduces the general methods and precautions for MODBUS application in the SCADA System of the seining line.
　　
Keywords:
Modbus frame ASCII mode RTU mode SCADA RS-485
　　
Modbus protocol is a data communication protocol developed by modicon. Through this protocol, various devices and networks can communicate with each other. Due to its high operability and openness, modbus protocol has become a universal communication protocol for industrial control networks. Many devices of different brands and manufacturers can exchange data through this protocol. A variety of communication and network protocols are applied to the SCADA System of the seining Gas Transmission Line, which combines various devices and becomes a complete three-level distributed control system, modbus protocol is an important protocol.
　　
Modbus Protocol Introduction
1. Modbus communication process
The Modbus protocol defines an information structure that can be recognized and used by all devices supporting this protocol during communication. It describes the process in which the controller sends a query to other devices and how other devices respond, as well as error detection and reporting.
The Modbus protocol uses the master-slave (master-slave) technology. On a Modbus bus, you can only have one master, and the Server Load balancer can have a maximum of 247 master nodes. The address is 1--247. During communication, only the master can initiate a "query" and act as a server Load balancer device for continuous detection. When a "query" with its own address is detected, A "response" will be sent to the master, or the corresponding action will be taken according to the master command. When the "query" sent by the master is a "broadcast" (address code is 0), all slave execute the master command, but do not send a response to the master.
　　
Ii. Modbus Frame
In network communication, data is transmitted in the form of "packet" or "frame". The meaning of "packet" and "frame" are basically the same, it refers to a data block in the communication. For a specific communication network, the term "frame" is generally used ". In the Modbus protocol, frame is referenced as the data unit in the communication process. The frame in Modbus consists of the following parts:
1. Flag: indicates the start of a "frame.
2. Address bit: indicates the slave to which the "frame" information is sent or the slave information.
3. Function Code: indicates a command. In Modbus protocol, a series of codes indicate different commands. For example, code "3" indicates reading data.
4. Data bit: Further supplements and describes the functional code, and describes the specific content of the instruction.
5. Check bit: CRC or LRC verification.
6. Stop bit: indicates the end of the frame.
The number of digits in each part is slightly different from that in the representation method.
　　
Iii. Modbus communication modes
In Modbus protocol, there are two modes based on the specific form of data transmission: ASCII and RTU. You can choose the mode based on your needs. When selecting, all devices in the same Modbus network must have the same mode.
　　
1. ASCII mode
ASCII (American Standard Code for information interchange), that is, the American Standard Code for information exchange. In this mode, each 8-bit byte is converted into two ASCII characters for transmission. The main advantage of this mode is that the maximum time interval allowed between each adjacent two bytes is 1 second.
　　

Table 1: frame format in ASCII mode

　　
In this frame:
A frame uses a colon (:) as the start sign, and a CRLF (carriage return-line feed, that is, "Carriage Return-line feed") as the end sign;
The code system uses hexadecimal notation, with ASCII characters 0... 9, a... f
Each ASCII character is composed of a hexadecimal character;
Each byte includes one start bit, seven data bits (low first transmitted), one parity bit (0 when there is no parity check), and one (when there is parity check) or two-bit (when there is no parity check) Stop bit;
The ASCII mode adopts the LRC (vertical redundancy check) error detection method.
　　
2. RTU Mode
RTU (Remote Terminal Unit) is a remote terminal unit. This mode is characterized by the conversion of every 8-bit bytes in the information into two 4-bit hexadecimal characters for transmission. Its advantage is that it has a higher data density so that it has a stronger data throughput capability than the ASCII mode at the same baud rate.
　　

Table 2: frame format in RTU Mode

　　
In this frame:
This frame uses an idle transmission time equivalent to at least 3.5 bytes as a sign of start and end. All data in the entire frame must be transmitted continuously. If the transmission interval exceeds 1.5 characters, the receiving device considers the next character as the beginning of a new frame, that is, an address code;
The code system uses an 8-bit binary, with a hexadecimal number of 0... 9, a... F;
Each 8-bit character of the information is composed of two hexadecimal characters;
Each byte includes one start bit, eight data bits (first transmitted at the low level), one parity bit (0 when there is no parity check), and one (when there is parity check) or two-bit (when there is no parity check) Stop bit;
The ASCII mode adopts the CRC (cyclic redundancy check) check error method.
　　
4. Communication between MODBUS and other networks
Modbus networks can communicate with other Modbus-compatible networks through built-in components or network adapters. On other networks, information about the Modbus protocol will be embedded in the frame or packet structure of the network to complete information conversion, this conversion can also interpret the Node Address, path, and troubleshooting methods.
In other networks, controllers use peer-to-peer technology for communication, so any controller can initiate a communication with other controllers. In this way, the controller can act as either the master device or the slave device (slave) in a separate communication process ). Multiple internal channels can be used simultaneously by multiple transmission processes.
While the network communication method is "peer-to-peer", the Modbus protocol still follows the "master-slave" principle. When a controller sends a message and expects responses from other devices, it acts as a "master" device ,. Similarly, when the Controller receives a message, it establishes a "response" format to return the message to the sent controller. In this case, he acts as a "slave" device.
　　
Application of Modbus protocol in singnylan SCADA System
　　
Application Principle
Modbus serves as a data bridge connecting a traffic computer and a PLC in the seining SCADA system. The traffic computer collects the corresponding data from the field meter, calculates the instantaneous traffic, cumulative traffic and other traffic parameters, and then transmits the necessary data to the PLC through Modbus, after necessary processing by PLC, it is displayed on the PC for production and operation. The process is as follows:
　　

Figure 1: Data Flow Direction of Traffic parameters

Debugging process
　　
I. Wiring
A-B company contrologix, its remote I/O rack has a communication template, called mcm (Modbus conmminication model), that is, Modbus communication template. The MCM template acts as a bridge between the MODBUS and PLC backboards and is also the master of the Modbus bus. According to the RS-485 interface standard, several traffic computers and MCM templates are connected to a Modbus network through the DB9 serial port connector. The wiring diagram is as follows (taking two traffic computers as an example, multiple nodes can be connected in parallel ):
　　

Figure 2 Communication Wiring Diagram between the MCM template and the traffic computer

　　
Note:
1. The MCM template provides RJ45 interfaces. You can use the RJ45 -- DB9 adapter line provided by the manufacturer, or directly use RJ45 connector. The method is as follows: RJ45 glass can be directly accessed from the front, the value ranges from left to right from 1 to 8, which corresponds to the 1-8th end of the DB9 connector. This project uses the latter, the advantage is to reduce the number of connections and improve the stability of communication.
2. cat5e shielded twisted pair wires are used in communication media, mainly considering the connection of RJ45 connectors. We used a general wire in our experiment, which has no effect on the communication effect. Modbus has no special requirements on communication media.
3. The connection line should be as short as possible and enough. Not only does it look neat, but also for communications between different devices, the line as short as possible is always more stable.
4. the wires must be in good condition, and the joints must be fastened and tested and confirmed repeatedly. In the debugging process, any virtual connection may cause communication failure, and it is extremely difficult to find the cause. A reliable hardware connection saves you the trouble of finding unnecessary faults and faults during debugging.
5, RS-485 bus communication in the line only need to follow a principle, that is, send to send, send to receive. Confirm that the connection is correct. If there are other problems, the connection will succeed.
　　
Ii. Device Configuration
In this network, the MCM template acts as the master, and the traffic computer is slave. The port settings of the MCM template used are shown in table 3 and the corresponding port settings of the traffic computer are shown in table 4:
　　

Table 3: port settings of the MCM Template

　　

Table 4: Traffic computer port settings

Set other related settings as needed.
When setting a device, you must pay attention to the different requirements of different devices. The corresponding settings at both ends must be the same.
　　
Iii. Problems Encountered during debugging and solutions:
1. When Modbus communication is used, a floating point transmission problem is encountered. Generally, floating point numbers are 32 bits, while Modbus bus can only transmit up to 16 bits of data.
Solution: You can use two integer numbers to transmit a floating point number (dividing a 32-bit binary number into two 16-bit binary numbers). After the transfer, then combine the two integer numbers into a floating point number.
　　
2. During the debugging process, when the data is transmitted to the PLC, it is initially found that the data is not the original value, but some inexplicable data, or it is too big, it is either a negative multiple-digit number.
　　
After repeated attempts, I finally found out the problem. Originally, In the Modbus bus, the data is transmitted in low bytes first. If the data is not exchanged after being transmitted, the binary values are arranged in reverse order, that is, the original low byte is at the High Level and the high byte is at the low level. Therefore, the obtained data is far from the original data. This problem can be solved by exchanging the high/low bytes of data (SWAP position 1.
　　
3. What should I do if the debugging process is always disconnected?
In the debugging process of data communication, if the data is always disconnected, we generally check in this order:
1) are various devices normal,
2) whether the wiring is correct and in good condition;
3) whether the configuration of various devices is correct.
In general, these factors have very few problems, but it is necessary to carefully check these factors. After confirmation, pay attention to the following points:
1) Use a testing software for testing, which can narrow down the scope of the problem. During our debugging process, we used a small test software called "mbus2" to test the wiring and configuration of the traffic computer. Generally, when the software is successfully tested, the overall debugging can be solved. Such test software can be obtained online, like the "mbnus2" and "Modbus View" we use. They are easy to use but extremely effective.
2) if you check that there is no problem but it still does not work, you can try to turn off all devices and restart them. This simple method is often useful during debugging.
　　
Conclusion:
Modbus protocol is used for communication between different devices, which is easy to operate, applicable, and fast to communicate. Therefore, Modbus is a common communication protocol in various industrial control systems. At the same time, Modbus is also a strong field bus. Modbus will play a greater role in realizing real network-based industrial control.