Modbus_RTU (RS485) Fieldbus Remote Inputs/Outputs Modules System Design Based on GD32E231

boming

Modbus_RTU (RS485) Fieldbus Remote Inputs/Outputs Modules System Design Based on GD32E231 [Copy link]

Detailed document 作品提交.docx (626.06 KB, downloads: 24)

Source code FreeRTOSv10.2.1_MultiButton_USART_DMA_FreeModbus.rar (11.11 MB, downloads: 343)

PCB schematics and proofing files

https://lceda.cn/editor#id=|2757f12a27324aebac45ee8b3f120693|f2b5d7b53466488fa332b206a804c7ed|53e5f75b74e64987a75c6cf6a065912c|65f4d1c274b846 c5bd36727f267aa75f

Technology is developing rapidly. Whether in life or in the office, we are exposed to a variety of electronic devices. When many electronic devices work together, some signal sources will be generated. In order to better transmit and collect signals, industrial control products such as remote IO modules, signal transmitters, and signal acquisition modules have been developed.
So, what is the use of remote IO modules? What is its function?
In the past, when people laid the lines between the ready-made and the cabinet, they had to connect them one by one, which greatly increased the cost of the cables and the construction time. If the distance was far, they would also face problems such as voltage attenuation. With the remote IO module, this problem is effectively solved.
If your cabinet is 200 meters away from the site and you do not use remote IO , then you have to lay 200 meters for each signal line . Then installing the remote IO module on site can save you a lot of money on cables and reduce the complexity of construction. In short, sometimes, some IOs are set up in places where on-site equipment is concentrated and far away from the central control, and then connected back to the central control room through optical fiber, just to save cable procurement and construction. Sometimes, the logical " remote " is because the number of " local IO" allowed cannot meet the actual needs, and a " remote IO template " needs to be connected . It depends on the actual situation. In addition, the cabinet room is generally placed at the device site. However, some control signals, such as emergency stop, bypass and other control signals, are implemented in the control room, so a remote IO module is needed to send these signals to the control system in the cabinet room.

Distributed remote IO modules are now used in many fields, and they play a big role. So, do you know the characteristics of distributed remote IO modules?

1. Reduce the number of control panels

Using distributed remote IO modules to monitor the metal temperature of boilers, steam turbines, generators and other equipment can reduce the number of control panels, reduce the area and space of the control room to make the control room neat and beautiful, and effectively improve the reliability of viewpoints and measurement accuracy.

2. Reduce installation costs

Distributed remote IO modules save more hardware equipment than DCS. Using distributed remote IO modules can greatly reduce safety barriers, isolators, remote IO modules, field cables and wiring terminals, thus saving IO devices and the cabinets and space for installing these devices, reducing installation costs.

3. Reliability

The number of safety barriers, isolators, terminal cabinets, IO modules, field cables and wiring terminals of distributed remote IO modules is greatly reduced. Field signals are digitally transmitted, which greatly improves the anti-interference ability of the system. These factors have improved the reliability of distributed remote IO modules!

4. Maintainability

Since the field level is completely decentralized, the number of safety barriers, isolators, I/O modules, field cables and wiring terminals is greatly reduced. Therefore, the distributed remote IO module greatly improves its maintenance performance.

5. Dispersibility

Compared with traditional DCS , distributed remote intelligent I/O embodies more thorough decentralization. Each of its 20 channels of data acquisition and processing uses an independent power supply and CPU , so faults are also dispersed. Even if any front end fails, it will not affect the normal operation of other front ends.

6. Ability to adapt to the environment

The ambient temperature of the distributed remote IO module is -20-70°C , and the protection level is IP56 , so it is suitable for places with harsh temperature environments such as the top of a boiler.

The following is the design and development of Modbus_RTU (RS485) bus Remote Inputs/Outputs Modules system based on GD32E231 :

2. Function Introduction

Power supply: External DC24V input, stepped down to DC3.3V by DC-DC , to power the entire system ( GD32E231 , input optocoupler, output optocoupler, LED , RS485 ).

RS485 conversion: USRAT0 of GD32E231 is converted to RS485 and communicate with the outside through MAX483 level conversion .

Input IO : External digital DC24V input, reduced voltage by resistor, controls optocoupler, and couples to GD32E231 input pin. Optocoupler isolates from external signal.

Output IO : GD32E231 output pin controls the optocoupler, which couples the external MOS tube to control the output. The optocoupler acts as an isolation from the external signal.

3 Modbus_RTU Fieldbus Introduction

The MODBUS protocol supports traditional RS-232 , RS-422 , RS-485 and Ethernet devices. Many industrial devices, including PLC , DCS , smart meters, etc., use the Modbus protocol as the communication standard between them.

The Modbus protocol is a universal language used in electronic controllers. Through this protocol, controllers can communicate with each other and with other devices via a network (such as Ethernet). The Modbus protocol defines a message structure that a controller can recognize and use , regardless of the network they communicate through. It describes the process of a controller requesting access to other devices, how to respond to requests from other devices, and how to detect and record errors. It establishes a common format for the message field pattern and content.

Modbus is a request / reply protocol.

The Modbus protocol is a universal language used in electronic controllers. Through this protocol, controllers can communicate with each other and with other devices via a network (such as Ethernet). It has become a universal industrial standard. With it, 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 and use , regardless of the network they communicate through. It describes the process of a controller requesting access to other devices, how to respond to requests from other devices, and how to detect and record errors. It establishes a common format for the message field structure and content. When communicating on a Modbus network, this protocol determines that each controller needs to know their device address, identify the message sent by the address, and decide what action to take. If a response is required, the controller will generate feedback information and send it using the Modbus protocol. On other networks, messages containing the Modbus protocol are converted to the frame or packet structure used on this network. This conversion also expands the methods for resolving node addresses, routing paths, and error detection based on specific networks.

1. Converting a standard Modbus port on a Modbus network uses an RS-232C compatible serial interface, which defines the pins, cables, signal bits, transmission baud rate, and parity of the connection port. The controller can be networked directly or via a modem . Controller communication uses master - slave technology, that is, only one device (master device) can initiate transmission (query). Other devices (slave devices) respond accordingly based on the data provided by the master device query. Typical master devices: host and programmable instrument. Typical slave device: programmable controller. The master device can communicate with slave devices alone or with all slave devices in broadcast mode. If communicating alone, the slave device returns a message in response. If queried in broadcast mode, no response is made. The Modbus protocol establishes the format of the master device query: device (or broadcast) address, function code, all data to be sent, and an error detection field. The slave device response message is also composed of the Modbus protocol, including a field to confirm the action to be taken, 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 create an error message and send it as a response.

Transmission mode ASC Ⅱ & RTU mode

2. Transmission on other types of networks On other networks, controllers communicate using peer-to-peer technology, so any controller can initiate communication with other controllers. In this way, in a single communication process, the controller can act as both a master device and a slave device. The multiple internal channels provided allow simultaneous transmission processes. In the message position, the Modbus protocol still provides the master - slave principle, although the network communication method is " peer " . If a controller sends a message, it only acts as a master device and expects a response from the slave device. Similarly, when the controller receives a message, it will establish a slave device response format and return it to the sending controller.

3. Query - Response Cycle

( 1 ) Query

The function code in the query message tells the selected slave what function to perform. The data segment contains any additional information about the function to be performed by the slave. For example, function code 03 requires the slave to read holding registers and return their contents.

The data segment must contain information to tell the slave device: which register to start reading from and the number of registers to read. The error detection field provides a way for the slave device to verify whether the message content is correct.

( 2 ) Response

If the slave generates a normal response, the function code in the response message is the same as the function code in the query message. The data segment contains the data collected by the slave: such as register values or status. If an error occurs, the function code will be modified to indicate that the response message is an error, and the data segment contains a code describing the error information. The error detection field allows the master device to confirm whether the message content is valid.

4Supported functions and features

Modbus Message Structure

The Modbus protocol uses 16-bit words (registers) divided into two bytes of 8 bits.

A Modbus message starts with a header followed by a 1-byte address.

message uses a Modbus function code (see page 67) as its first byte.

The table below describes the full structure of a Modbus RTU message:

Mask writing (22): Result= (Current contentAND And_Mask) OR (Or_Mask AND And_Mask)

Abort Code

The meaning of error codes is given in the table below:

Electrical Specifications

The network interface module supports 2-wire Modbus. Communication type is halfduplex.

Communications Configuration

The Modbus communication parameters which define the frame can be configured

in a number of different ways.

5 Register Map

PA1 à DISCRETE_INPUT0

PA2 à DISCRETE_INPUT1

PA3 à DISCRETE_INPUT2

PA4 à DISCRETE_INPUT3

PA5 à DISCRETE_INPUT4

PA6 à DISCRETE_INPUT5

PB4 à DISCRETE_INPUT6

PB5 à DISCRETE_INPUT7

PB6 à DISCRETE_INPUT8

PB7 à DISCRETE_INPUT9

PB8 à DISCRETE_INPUT10

PB0 à DISCRETE COILS0

PB1 à DISCRETE COILS1

PB10 AT DISCRETE COILS2

PB11 à DISCRETE COILS3

PB12 à DISCRETE COILS4

PB13 AT DISCRETE COILS5

PB14 à DISCRETE COILS6

PB15 à DISCRETE COILS7

6 Function Demonstration

2.mp4 (13.44 MB, downloads: 3)

3.mp4 (8.99 MB, downloads: 3)