Modbus wireless transmission method and system based on Zigbee

Abstract

The invention relates to the technical field of wireless transmission, in particular to a Modbus wireless transmission method and system based on Zigbee. A Modbus cluster is defined in a ZCL protocol, a Modbus ID attribute corresponding to physical equipment of each slave converter is set for each slave converter, when a host converter needs to communicate with unknown equipment, blind data broadcasting is not needed any more, and the communication efficiency is improved. Instead, a matching command carrying the target Modbus ID is broadcasted firstly, only the slave converter matched with the ID in the network responds to the Zigbee network address of the slave converter in a unicast mode, the host dynamically establishes address mapping after receiving the Zigbee network address, all subsequent Modbus messages are accurately transmitted through efficient and stable unicast, the mapping relation has the self-healing capacity, and the Modbus messages can be accurately transmitted through the self-healing capacity. When the network address of the slave is changed, the network address can be automatically updated, and long-term stability of communication is ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of wireless transmission, and in particular to a Zigbee-based Modbus wireless transmission method and system. Background Art

[0002] In the field of industrial automation and process control, the Modbus protocol, a mature, open, and widely used serial communication protocol, has become the de facto standard for connecting field devices such as programmable logic controllers (PLCs), sensors, transmitters, and actuators. With its simple structure and ease of deployment, the protocol plays a core role in wired communication networks, particularly those based on RS-485 or RS-232. In recent years, with the rapid development of Industrial Internet of Things (IIoT) technology, production sites have placed higher demands on the flexibility, scalability, and deployment costs of communication networks. Wireless communication technologies, particularly Zigbee, known for its low power consumption, ad hoc networking, and high reliability, have attracted significant industry attention as they are well-suited for building large-scale, distributed industrial wireless sensor and control networks. Migrating the Modbus protocol, which traditionally relies on wired media, to the flexible Zigbee wireless network through technical means, replacing expensive and complex physical wiring, and enabling wireless data collection and control in the industrial field, has become a clear and important technological development direction in this field. However, the main challenge in adapting the Modbus protocol to Zigbee wireless networks currently stems from the fundamental differences between the two protocols in network architecture and addressing mechanisms. On the one hand, Modbus uses logical addressing based on fixed device addresses, while in a Zigbee network, the network address (short address) of a node may change dynamically due to network reconstruction, device reconnection, and other reasons, making it extremely difficult to establish a stable and reliable communication link. On the other hand, there is currently a solution that uses broadcasting to transmit Modbus messages in a Zigbee network. In this case, the master station sends a request to all nodes in the network, and the target slave station responds. However, this one-call-all-response model not only generates a large amount of redundant data unrelated to the target device, resulting in a serious waste of wireless channel resources and network congestion, but also significantly increases the probability of communication delays and data collisions, greatly reducing the communication efficiency and real-time performance of the entire network, and failing to meet the stringent requirements of industrial control for stability and reliability. Summary of the Invention

[0003] The purpose of the present invention is to provide a Zigbee-based Modbus wireless transmission method and system. By establishing a dynamic mapping and adaptive discovery mechanism between Modbus addresses and Zigbee network addresses, the method optimizes the default broadcast communication to efficient unicast communication, significantly reduces network congestion and latency, and greatly improves the communication efficiency, real-time performance, and network stability of wireless Modbus systems in industrial environments.

[0004] The present invention is achieved through the following technical solutions: A Modbus wireless transmission method based on Zigbee, the method comprising the following steps: Both the master converter and the slave converter define the Modbus cluster based on the ZCL protocol. The master converter is characterized as a Zigbee converter acting as a Modbus master, and the slave converter is characterized as a Zigbee converter acting as a Modbus slave. The slave converter stores, in its Modbus cluster, a Modbus ID attribute corresponding to the Modbus slave device address to which it is connected; The host converter, after receiving a Modbus request message including a target Modbus address, searches a mapping table maintained locally for a Zigbee network address corresponding to the target Modbus address; If the target Modbus address is not found in the mapping table, the host converter broadcasts a Modbus ID match command carrying the target Modbus address; After receiving the Modbus ID matching command, the slave converter determines whether the target Modbus address carried in the command is consistent with the Modbus ID attribute stored in itself. If they are consistent, the slave converter unicasts a response containing its own Zigbee network address to the master converter; After receiving the response, the host converter establishes a mapping relationship between the target Modbus address and the Zigbee network address included in the response and updates the mapping table, and encapsulates the Modbus request message in a data transmission command and unicasts it to the slave converter.

[0005] Optionally, also include: When the host converter fails to send data to a Zigbee network address recorded in the mapping table, the corresponding mapping relationship in the mapping table is deleted, and the Modbus ID matching command is broadcast again to obtain a new Zigbee network address; After the slave converter establishes a binding relationship with the host converter, when its own Modbus ID attribute changes, it sends its Modbus ID attribute to the host converter in the form of attribute reporting. The host converter refreshes the corresponding mapping relationship in its mapping table according to the source network address in the received attribute reporting information.

[0006] Optionally, the following attributes are defined in the Modbus cluster: The transmission mode attribute is used to configure the Zigbee converter to be in master mode or slave mode; The host notification command is sent by the master converter to notify one or more slave converters to obtain their network addresses and application port numbers in order to lock the communication target.

[0007] Optionally, the master converter and the slave converter are coordinators, routers or terminal nodes in a Zigbee network, the Zigbee network includes multiple master converters, and the slave converter is designated to communicate with the selected master converter by configuring the target address attribute within its Modbus cluster.

[0008] Optionally, a console is also included for management and configuration, specifically: The console is connected to the Zigbee network coordinator, remotely reads and writes the Modbus ID attributes in the slave converter through the ZCL host computer protocol, and sends data transmission commands encapsulating Modbus messages to any slave converter to achieve address scanning and automatic configuration of the slave device.

[0009] A Zigbee-based Modbus wireless transmission system includes a master converter and a slave converter, wherein: The master converter and the slave converter are both Zigbee devices with built-in Modbus clusters defined based on the ZCL protocol; The slave converter is configured to store the Modbus ID attribute corresponding to the Modbus slave device address connected to it in its Modbus cluster, and upon receiving a Modbus ID match command, if the target Modbus address carried in the match command is consistent with the Modbus ID attribute stored in itself, then unicast a response including its own Zigbee network address to the command source; The master converter is configured to maintain a mapping table between Modbus addresses and Zigbee network addresses. After receiving a Modbus request message containing a target Modbus address, if no corresponding relationship is found in the mapping table, the master converter broadcasts the Modbus ID matching command. After receiving a response from the slave converter, the master converter updates the mapping table, encapsulates the Modbus request message in a data transmission command, and performs unicast transmission to the slave converter.

[0010] Optionally, the host converter is further configured with: After failing to send data to a Zigbee network address recorded in the mapping table, deleting the corresponding mapping relationship in the mapping table and rebroadcasting the Modbus ID matching command; When receiving the Modbus ID attribute actively reported by the slave converter with which the binding relationship has been established, the corresponding mapping relationship in its mapping table is refreshed according to the source network address in the reported information.

[0011] Optionally, the Modbus cluster defined in the master converter and the slave converter further includes the following attributes: The transmission mode attribute is used to configure the Zigbee converter to be in master mode or slave mode; The host notification command is sent by the master converter to notify the slave converter to obtain its network address and application port number.

[0012] Optionally, the host converter and the slave converter are specifically coordinators, routers or terminal nodes in a Zigbee network; and the Zigbee converter is configured with multiple application ports supporting the Modbus cluster to connect multiple Modbus devices.

[0013] Optionally, a console is further included, which communicates with the host converter and the slave converter through a Zigbee network coordinator, and the console is configured to remotely read and write the Modbus ID attributes and send data transmission commands through a ZCL host computer protocol.

[0014] The technical solution of the present invention has at least the following advantages and beneficial effects: On the one hand, the present invention establishes a dynamic address mapping mechanism by defining a proprietary Modbus cluster and related attributes within the Zigbee converter. This mechanism utilizes an on-demand discovery strategy, initiating a one-time broadcast addressing only when the communication target is unknown. Once the target device's Zigbee network address is successfully acquired, a mapping table is established and maintained. On the other hand, the present invention transmits all subsequent Modbus service data point-to-point via efficient and reliable unicast. This fundamental shift from broadcast to unicast significantly reduces network storms, wireless channel load, and data latency, thereby ensuring the real-time performance and stability necessary for industrial control and significantly improving the efficiency of the entire wireless communication system. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A schematic diagram of the flow of the Zigbee-based Modbus wireless transmission method provided by the present invention; Figure 2 A schematic diagram of a network structure of a single converter with multiple slaves provided by the present invention; Figure 3 A schematic diagram of the connection of multiple hosts provided by the present invention; Figure 4 A schematic diagram of the first form of the system network architecture provided by the present invention; Figure 5 This is a schematic diagram of the second form of the system network architecture provided by the present invention. DETAILED DESCRIPTION

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings herein can be arranged and designed in various different configurations.

[0017] In the embodiment of the present invention, the core device of this embodiment is a Zigbee converter, which is divided into the following types according to its role in Modbus communication: Host converter: Connects to a Modbus host device (such as a PLC, HMI, or industrial computer), or integrates Modbus host logic itself, and is responsible for initiating Modbus requests in the Zigbee network.

[0018] Slave converter: Connects one or more Modbus slave devices (such as sensors, transmitters, and actuators), is responsible for receiving requests in the Zigbee network, and acts as a proxy for the slave devices to respond.

[0019] Console: An optional but powerful management device, typically a host computer or gateway connected to the Zigbee coordinator, used for advanced configuration, monitoring, and automated management of the converters in the entire wireless network.

[0020] This embodiment defines and implements a proprietary Modbus cluster within the standard Zigbee 3.0 ZCL (Zigbee Cluster Library) protocol framework. This deeply integrates the Modbus protocol's application layer concepts with Zigbee's object model architecture, enabling Modbus communications to seamlessly leverage all the advantages of the Zigbee network, such as routing, binding, and attribute reporting. This Modbus cluster is pre-installed in all master and slave converters.

[0021] The following attributes and proprietary commands are defined within the Modbus cluster: Modbus ID (attribute ID: for example, 0x0000): Data type: uint8 (unsigned 8-bit integer), value range: 1-247, corresponds to the device address of the Modbus slave. Function: In the slave converter, the value of this attribute must be configured to be exactly the same as the address of the Modbus slave device to which it is physically connected. It is the unique identifier used by the master converter to identify a specific Modbus target in the vast Zigbee network. Operation permissions: Readable, writable, and reportable. "Readable and writable" means that it can be configured locally (such as AT commands) or remotely (such as through ZCL global commands on the console); "reportable" is a key feature that enables adaptive address updates.

[0022] Transmission Mode (attribute ID: e.g., 0x0001): Data type: enum8 (8-bit enumeration type), for example, 0x00 represents slave mode, and 0x01 represents master mode. Function: Used to set the operating role of the Zigbee converter. A physical device can flexibly switch between master and slave roles based on the configuration of this attribute, greatly enhancing system deployment flexibility.

[0023] Destination Address (attribute ID: for example, 0x0002) and Destination Port (attribute ID: for example, 0x0003): Data Type: uint16 (destination address, corresponding to the ZigBee network address) and uint8 (destination port). Function: These two attributes are primarily used by slave converters. In complex networks with multiple master converters, configuring these two attributes allows a slave converter to "lock onto" a specific master converter for communication, preventing it from responding to requests from unintended masters and achieving isolated communication domains.

[0024] Data Transfer Command (Command ID: e.g., 0x00): Function: This is a core command that carries the actual Modbus service data. Both Modbus request and response messages are fully encapsulated in the command's payload and transmitted unicast between the master and slave converters. The payload can be variable in length to accommodate Modbus messages of varying lengths.

[0025] Modbus ID Match Command (Command ID: e.g., 0x01): Function: Implements "addressing signaling" for automatic address discovery. A master converter broadcasts this command when it needs to communicate with an unknown Modbus address. Payload: The command payload contains an 8-bit target Modbus address. Action: All slave converters on the network receive this broadcast command and compare the target Modbus address in the payload with the Modbus ID attribute value stored in their own devices.

[0026] Host Notification Command (Command ID: e.g., 0x02): Function: Sent by the master converter for network management. It notifies one or more slave converters of its network address and port number. Upon receiving this, the slave converters can update their "destination address" and "destination port" properties, thereby establishing or changing communication relationships.

[0027] Reference Figure 1 As shown, the process will be described in detail below in combination with the master converter and the slave converter in the system.

[0028] Step 1: During system deployment, all Zigbee converters in the network (both those acting as masters and slaves) are flashed with firmware containing the Modbus cluster described above. Each slave converter must be configured so that its Modbus ID attribute matches the actual address of the Modbus slave device to which it is physically connected (e.g., the address set via DIP switches or configuration software). For example, a slave converter connected to a temperature sensor at address 0x05 must have its Modbus ID attribute set to 0x05. This configuration can be performed using local serial port AT commands or remotely from a console.

[0029] Step 2: An external Modbus master device (such as a PLC) sends a standard Modbus RTU request message to the host converter via the RS-485 bus. For example, it requests to read the holding register of the slave device at address 0x05. The host converter receives and parses the message, extracting key information: the target Modbus address (0x05) and the complete message content.

[0030] Step 3: The host converter maintains an internal address mapping table. This table stores the correspondence between Modbus addresses and Zigbee network addresses. Its structure is typically: {Modbus address (uint8), Zigbee network address (uint16), Zigbee application port (uint8)}. This table can be stored in volatile memory (RAM) because it has dynamic self-healing capabilities. The host converter uses the target Modbus address 0x05 extracted from the request message as an index to query the mapping table.

[0031] Case A: A match is found. If the mapping table contains an entry with Modbus address = 0x05, this indicates that communication with this device has already been successful. The host converter directly reads the corresponding Zigbee network address (e.g., 0x1234) and application port (e.g., 0x01) from the table. The process then jumps directly to step 9. This is a true example of the high efficiency of this invention; most routine communications will follow this path.

[0032] Case B: No match found. If the mapping table does not contain an entry with Modbus address = 0x05, or if the entry has been cleared due to a previous communication failure, this indicates that this is the first communication or the target address has changed. In this case, the host converter triggers the automatic address discovery mechanism and proceeds to step 5. To prevent loss of the current Modbus request, the host converter can temporarily store the request message in a buffer queue and start a timeout timer.

[0033] Step 5: The host converter constructs a Modbus ID match command and sets its payload to the target Modbus address 0x05. It then broadcasts this command to the entire Zigbee network via its Zigbee RF module. This is intended to establish a communication path, not to transmit service data.

[0034] Step 6: All slave converters on the network receive this broadcast command. Each slave converter performs the same operation: parsing the command, extracting the target Modbus address (0x05) in the payload, and comparing it with its internally stored Modbus ID attribute value. Slave converters whose Modbus IDs are not equal to 0x05 determine that the command is irrelevant to them and simply ignore it without responding. This avoids unnecessary network traffic. The slave converter whose Modbus ID is exactly 0x05 (we call it the target slave converter) determines that it is the target.

[0035] Step 7: The successfully matched target slave converter immediately constructs a response message. This response message can be a specific ZCL command, whose payload contains its own key information triple: its Zigbee network address, application port number, and its Modbus ID. It then extracts the source network address (i.e., the master converter's address) from the Zigbee frame header of the received Modbus ID match command and accurately sends this response message back to the master converter via unicast.

[0036] Step 8: The master converter receives the unicast response from the target slave converter. It parses the response message, extracting the Zigbee network address (for example, 0x1234), application port (0x01), and Modbus ID (0x05). It then creates or updates this mapping {0x05, 0x1234, 0x01} in its local address mapping table. This completes the address discovery and mapping process.

[0037] Step 9: The host converter retrieves (or directly uses) the original Modbus request message from the buffer queue and encapsulates it into a data transmission command as the payload. It then sends this data transmission command in unicast mode to the Zigbee address 0x1234 and port 0x01 recorded in the mapping table.

[0038] Step 10: The target slave converter (address 0x1234) receives this unicast data transmission command. It parses the command, extracts the Modbus request message from the payload, and forwards the message intact to the physically connected Modbus slave device (address 0x05) via its connected RS-485 interface. The Modbus slave device executes the request and returns a response message to the slave converter via RS-485. Upon receiving this response message, the slave converter encapsulates it into a new data transmission command in the same manner. It then derives the source address (the master converter's address) from the header of the previously received request command and unicasts this response command back to the master converter. Upon receiving it, the master converter parses the Modbus response message and returns it to the original Modbus master device via the RS-485 interface. This concludes a complete, efficient, point-to-point wireless Modbus communication transaction.

[0039] The system of this embodiment is centered around a master converter and a slave converter. These converters can be identical in hardware, with their roles differentiated by writing transmission mode attributes. The hardware components are as follows: A microcontroller unit (MCU): Serving as the brain of the device, it is responsible for running the Zigbee protocol stack, the ZCL protocol, and the Modbus cluster application logic defined in this invention, including processing Modbus messages, maintaining the address mapping table, and executing the state machine. A Zigbee RF transceiver: A RF chip compliant with the IEEE 802.15.4 standard, responsible for transmitting and receiving wireless data in the 2.4 GHz frequency band. A serial communication interface: Typically an RS-485 or RS-232 transceiver, used for physical connection and level conversion with external Modbus devices. Memory: Includes Flash (for storing firmware and permanent configuration, such as the Modbus ID) and RAM (for running programs and storing dynamic data, such as the address mapping table). A power supply module: Provides a stable operating voltage for the entire device.

[0040] In the specific application of this embodiment, the mesh nature of the Zigbee network determines that the network address of a node may change under certain circumstances (such as network reconfiguration or parent node loss). This embodiment provides a robust adaptive update mechanism to ensure the long-term stability of the communication link.

[0041] Mechanism 1: When the master converter sends a data transmission command to a Zigbee address (e.g., 0x1234) according to its mapping table, the Zigbee protocol stack provides a send confirmation callback (e.g., AF_DATA_SEND_CONFIRM). If the data transmission fails (e.g., because the target node no longer exists or the network address has changed), the callback returns a failure status. The master converter's application logic monitors this transmission status. When it detects that consecutive data transmission failures to the same address reach a preset threshold (e.g., three times), it determines that the mapping relationship has expired. At this point, the master converter proactively deletes the entry from its address mapping table (i.e., deletes {0x05, 0x1234, 0x01}). The next time the Modbus master device requests access to address 0x05, the master converter will automatically re-trigger step S105 of Example 1, rebroadcasting the Modbus ID match command, because the address cannot be found in the mapping table (it has been deleted). This will help the master converter discover the target slave converter's new network address, which may have changed, and re-establish the mapping relationship.

[0042] Mechanism 2: During the network configuration phase, a Modbus cluster binding relationship can be established between the slave converter and the master converter through the console or by using a master notification command. Binding means that the slave converter records the master converter's 64-bit IEEE address and port number in its binding table. The reporting rules for the slave converter's Modbus ID attribute are configured. For example, a maximum reporting interval (such as 30 minutes), a minimum reporting interval, and a change threshold can be set. (For static data such as the Modbus ID, the change threshold can be set to 1, meaning any changes are reported.) Even if the Modbus ID does not change, the slave converter will automatically send an attribute report command containing its own Modbus ID to the bound master converter via unicast at the maximum reporting interval (every 30 minutes). If the administrator modifies the slave converter's Modbus ID attribute in some way, the slave converter will immediately trigger an attribute report due to the reporting configuration. After receiving this attribute report command, the master converter not only obtains the reported Modbus ID value but, more importantly, directly reads the source network address from the Zigbee network layer header of the ZCL frame. The master converter then uses this Modbus ID and source network address to refresh its local address mapping table. This way, even if the slave converter's network address changes, the master converter's mapping table can be automatically and seamlessly updated the next time it reports an attribute. These two mechanisms complement each other, ensuring that address mappings remain up-to-date and valid under all circumstances, significantly improving system robustness.

[0043] In further applications of this embodiment, this embodiment is not limited to a simple one-master-to-multiple-slave structure, but supports a variety of complex network topologies and application architectures, fully demonstrating its flexibility and scalability, including: Single converter connected to multiple slaves: refer to Figure 2If a physical Zigbee converter device is equipped with multiple independent serial ports (such as two RS-485 interfaces), multiple Modbus cluster-supported applications can be instantiated on its MCU, with each application occupying a separate application port (Endpoint). For example, the application on port 1 connects to Modbus slave A (address 0x0A) on serial port 1, with its Modbus ID attribute set to 0x0A. The application on port 2 connects to Modbus slave B (address 0x0B) on serial port 2, with its Modbus ID attribute set to 0x0B. From the perspective of the Zigbee network, this is equivalent to two independent logical devices existing on a single physical node. The host converter performs address discovery and communication with port-level accuracy. Its address mapping table also includes the port number to ensure that data is routed to the correct application instance, which is then forwarded to the correct physical serial port.

[0044] Multi-host and master-slave integrated network: refer to Figure 3 This embodiment supports multiple host converters in a Zigbee network. For example, host A is responsible for controlling a group of production equipment, and host B is responsible for monitoring another group of environmental sensors. By configuring the target address and target port properties of the slave converter, a slave can be specified to only accept communications from a specific host, thus achieving logical isolation. A physical converter can play the role of both host and slave at the same time. For example, Figure 3 In the example, converter C has one application port (e.g., EP1) configured in slave mode, connected to a slave device and responding to requests from host A. Meanwhile, another application port (e.g., EP2) is configured in master mode, actively polling the slave device connected to converter D. This flexibility makes it possible to build complex, hierarchical control systems.

[0045] Flexible device role assignment: The master converter and slave converter in this embodiment are logical roles, not fixed device types. Any Zigbee device, whether a coordinator, router, or terminal node, can be configured as any role as long as it has sufficient processing power and memory. Figure 5 This figure shows a common deployment scenario in which the Zigbee coordinator itself is configured as a master converter. The advantage of this approach is that, as the center of the network, the coordinator typically has the most stable position and the strongest processing power. Having it assume the master role simplifies the network structure. Other routers or end nodes act as slave converters.

[0046] Further, refer to Figure 4 and Figure 5As shown, this embodiment also introduces a console component, significantly improving the system's manageability and usability. The console is typically a software application running on a PC, industrial computer, or dedicated gateway device. It connects to the Zigbee network coordinator via a physical connection (such as USB or Ethernet). The coordinator runs a special "ZCL host protocol" interface that converts high-level commands from the console into standard ZCL commands and sends them to the Zigbee network, and vice versa.

[0047] The operator can browse all Zigbee converters on the network using the console's graphical interface. By clicking on a device, the console can issue a ZCL read attribute command to retrieve key attributes such as the device's Modbus ID and transmission mode. Similarly, write attribute commands can be sent to remotely modify these configurations without physically accessing the device. The console constructs a standard Modbus request message, such as "Read Device Identification Code" (function code 0x11). Through the coordinator, the console broadcasts a data transfer command encapsulating the Modbus request message to the entire Zigbee network. This broadcast command is unique in that it is not targeted at a specific Zigbee device but rather intended for all slave converters to receive and process. Upon receiving this broadcast command, each slave converter transmits the encapsulated Modbus request message through its own serial port. The Modbus slave device on the bus with a matching address responds. Upon receiving the response, the slave converter encapsulates it in a data transfer command and sends it back to the coordinator via unicast, ultimately reaching the console. By looping through all possible Modbus addresses (1 to 247), the console can discover the existence and addresses of all Modbus slave devices on the network. After the scan is complete, the console possesses a complete mapping table from "Zigbee network addresses" to "Modbus device addresses." Based on this table, the console automatically sends a write attribute command to each slave converter, setting its Modbus ID to the correct address, thus completing the automated configuration of the entire system. This console-based implementation significantly reduces system deployment, commissioning, and maintenance costs.

[0048] The above is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that the present invention is susceptible to various modifications and variations. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A Modbus wireless transmission method based on Zigbee, characterized in that: The steps of the method include: Both the master converter and the slave converter define the Modbus cluster based on the ZCL protocol. The master converter is characterized as a Zigbee converter acting as a Modbus master, and the slave converter is characterized as a Zigbee converter acting as a Modbus slave. The slave converter stores, in its Modbus cluster, a Modbus ID attribute corresponding to the Modbus slave device address to which it is connected; The host converter, after receiving a Modbus request message including a target Modbus address, searches a mapping table maintained locally for a Zigbee network address corresponding to the target Modbus address; If the target Modbus address is not found in the mapping table, the host converter broadcasts a Modbus ID match command carrying the target Modbus address; After receiving the Modbus ID matching command, the slave converter determines whether the target Modbus address carried in the command is consistent with the Modbus ID attribute stored in itself. If they are consistent, the slave converter unicasts a response containing its own Zigbee network address to the master converter; After receiving the response, the host converter establishes a mapping relationship between the target Modbus address and the Zigbee network address included in the response and updates the mapping table, and encapsulates the Modbus request message in a data transmission command and unicasts it to the slave converter.

2. The Zigbee-based Modbus wireless transmission method according to claim 1, wherein: Also includes: When the host converter fails to send data to a Zigbee network address recorded in the mapping table, the corresponding mapping relationship in the mapping table is deleted, and the Modbus ID matching command is broadcast again to obtain a new Zigbee network address; After the slave converter establishes a binding relationship with the host converter, when its own Modbus ID attribute changes, it sends its Modbus ID attribute to the host converter in the form of attribute reporting. The host converter refreshes the corresponding mapping relationship in its mapping table according to the source network address in the received attribute reporting information.

3. The Zigbee-based Modbus wireless transmission method according to claim 1, wherein: The Modbus cluster defines the following properties: The transmission mode attribute is used to configure the Zigbee converter to be in master mode or slave mode; The host notification command is sent by the master converter to notify one or more slave converters to obtain their network addresses and application port numbers in order to lock the communication target.

4. The Zigbee-based Modbus wireless transmission method according to claim 1, wherein: The master converter and the slave converter are coordinators, routers or terminal nodes in a Zigbee network. The Zigbee network includes a plurality of the master converters, and the slave converter is designated to communicate with the selected master converter by configuring the target address attribute within its Modbus cluster.

5. The Zigbee-based Modbus wireless transmission method according to claim 4, wherein: It also includes a console for management and configuration, specifically: The console is connected to the Zigbee network coordinator, remotely reads and writes the Modbus ID attributes in the slave converter through the ZCL host computer protocol, and sends data transmission commands encapsulating Modbus messages to any slave converter to achieve address scanning and automatic configuration of the slave device.

6. A Modbus wireless transmission system based on Zigbee, characterized in that: Includes master converter and slave converter, where: The master converter and the slave converter are both Zigbee devices with built-in Modbus clusters defined based on the ZCL protocol; The slave converter is configured to store the Modbus ID attribute corresponding to the Modbus slave device address connected to it in its Modbus cluster, and upon receiving a Modbus ID match command, if the target Modbus address carried in the match command is consistent with the Modbus ID attribute stored in itself, then unicast a response including its own Zigbee network address to the command source; The master converter is configured to maintain a mapping table between Modbus addresses and Zigbee network addresses. After receiving a Modbus request message containing a target Modbus address, if no corresponding relationship is found in the mapping table, the master converter broadcasts the Modbus ID matching command. After receiving a response from the slave converter, the master converter updates the mapping table, encapsulates the Modbus request message in a data transmission command, and performs unicast transmission to the slave converter.

7. The Zigbee-based Modbus wireless transmission system according to claim 6, characterized in that: The host converter is further configured with: After failing to send data to a Zigbee network address recorded in the mapping table, deleting the corresponding mapping relationship in the mapping table and rebroadcasting the Modbus ID matching command; When receiving the Modbus ID attribute actively reported by the slave converter with which the binding relationship has been established, the corresponding mapping relationship in its mapping table is refreshed according to the source network address in the reported information.

8. The Zigbee-based Modbus wireless transmission system according to claim 6, characterized in that: The Modbus cluster defined in the master converter and the slave converter also includes the following attributes: The transmission mode attribute is used to configure the Zigbee converter to be in master mode or slave mode; The host notification command is sent by the master converter to notify the slave converter to obtain its network address and application port number.

9. The Zigbee-based Modbus wireless transmission system according to claim 6, characterized in that: The host converter and the slave converter are specifically coordinators, routers or terminal nodes in the Zigbee network; and the Zigbee converter is configured with multiple application ports supporting the Modbus cluster to connect multiple Modbus devices.

10. The Zigbee-based Modbus wireless transmission system according to claim 9, characterized in that: It also includes a console, which communicates with the host converter and the slave converter through a Zigbee network coordinator, and the console is configured to remotely read and write the Modbus ID attributes and send data transmission commands through a ZCL host computer protocol.

Images