Protocol conversion method from multiple Modbus master stations to EtherCAT slave stations

Abstract

The invention provides a protocol conversion method from multiple Modbus master stations to EtherCAT slave stations, and relates to the technical field, and the method comprises the steps: collecting the data of multiple Modbus slave station devices in parallel through at least two paths of independent Modbus master station communication interfaces, or issuing an instruction to the Modbus slave station devices; the method comprises the following steps of: analyzing acquired Modbus protocol data by running a core control module of a real-time operating system, and packaging the analyzed effective data into an EtherCAT slave station protocol data packet; or, analyzing the received EtherCAT protocol data packet, and converting the EtherCAT protocol data packet into a Modbus protocol instruction; and through the EtherCAT slave station module, sending the packaged EtherCAT slave station protocol data packet to an EtherCAT master station, or receiving an instruction data packet from the EtherCAT master station and transmitting the instruction data packet to the core control module.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field, and particularly relates to a protocol conversion method from multiple Modbus master stations to EtherCAT slave stations. BACKGROUND

[0002] In an industrial automation control system, it is a common phenomenon that multiple industrial field buses coexist with industrial Ethernet protocols. Among them, the Modbus-RTU protocol is widely used in a large number of sensors, actuators and low-end controllers due to its simplicity, reliability and low cost; and the EtherCAT (Ethernet for Control Automation Technology) protocol occupies a dominant position in the field of high-performance motion control, distributed I / O system and other fields with high real-time requirements due to its high real-time performance, determinacy and data transmission efficiency. In order to realize the penetration and centralized monitoring of information flow in a factory, it is often necessary to connect the Modbus (MODICON BUS) device network distributed in the field to the high-speed control network with EtherCAT as the backbone.

[0003] At present, the Modbus-to-EtherCAT protocol conversion gateway existing in the market mainly focuses on the translation and data forwarding of the protocol itself in the functional design. However, such a gateway is usually configured with a single Modbus master station interface. In an actual complex industrial field, the Modbus slave device is often numerous and may be scattered in different areas or functional units. When the gateway with a single master station is used for access, either all Modbus slave devices need to be connected in series on a bus, resulting in heavy bus load, complex wiring and increased communication delay; or multiple single-gateway devices have to be deployed, which not only significantly increases the hardware procurement cost, installation space and wiring difficulty, but also complicates the entire network topology structure, increasing the difficulty of system configuration, maintenance and fault diagnosis. Therefore, the existing technical solution has obvious deficiencies in economy, integration and real-time performance when dealing with the scene of parallel access of multiple regional and high-density Modbus devices to the EtherCAT network. SUMMARY

[0004] The application provides a protocol conversion method from multiple Modbus master stations to EtherCAT slave stations to solve one of the above technical problems.

[0005] The technical scheme adopted by the application is: The application provides a protocol conversion method from multiple Modbus master stations to EtherCAT slave stations, which comprises: Collecting data or issuing instructions in parallel through at least two independent Modbus master communication interfaces; Analyzing the collected Modbus protocol data through the core control module running a real-time operating system, and encapsulating the effective data after analysis into an EtherCAT slave protocol data packet; or analyzing and converting the received EtherCAT protocol data packet into a Modbus protocol instruction; Sending the encapsulated EtherCAT slave protocol data packet to the EtherCAT master through the EtherCAT slave module, or receiving the instruction data packet from the EtherCAT master and transmitting it to the core control module.

[0006] According to an embodiment of the present application, the data collection or instruction issuance through at least two independent Modbus master communication interfaces specifically includes: Connecting up to 16 Modbus slave devices through four RS-485 interfaces or two RS-422 interfaces; Sending data reading instructions or control instructions to each Modbus slave device according to a preset period through multiple independent Modbus data collection tasks scheduled by the core control module.

[0007] According to an embodiment of the present application, the analysis of the collected Modbus protocol data includes CRC checking of the received Modbus-RTU data frame, and extracting the device address and register value as effective data after the checking is passed.

[0008] According to an embodiment of the present application, the encapsulation of the effective data after analysis into an EtherCAT slave protocol data packet includes mapping and encapsulating the register address and data of the Modbus slave device into a data packet conforming to the EtherCAT protocol format according to the EtherCAT slave object dictionary (CoE) specification.

[0009] According to an embodiment of the present application, the analysis and conversion of the received EtherCAT protocol data packet includes frame check sequence (FCS) checking of the data packet, extracting the control instruction content after the checking is passed, and generating a Modbus-RTU instruction frame containing the target Modbus slave address and control register address.

[0010] According to one embodiment of this application, the core control module executes the parsing, encapsulation, or conversion steps through multi-task scheduling, wherein the tasks include at least periodically running Modbus data acquisition tasks, protocol conversion tasks, and EtherCAT data processing tasks in response to interruptions.

[0011] According to one embodiment of this application, the method further includes an uplink feedback process: after issuing a command to the Modbus slave device, the response data of the device is received, parsed and encapsulated, and then fed back to the EtherCAT master station through the EtherCAT slave module to form a command closed loop.

[0012] A second aspect of this application provides a protocol conversion gateway for multiple Modbus masters to EtherCAT slaves, comprising: The Modbus master interface module provides at least two independent Modbus master communication interfaces to connect multiple Modbus slave devices in parallel. The core control module is communicatively connected to the Modbus master interface module and is used to run a real-time operating system. It parses Modbus protocol data from the Modbus master interface module through multi-task scheduling and converts the parsed data into EtherCAT slave protocol data packets, or parses the received EtherCAT protocol data packets and converts them into Modbus protocol instructions. The EtherCAT slave module is communicatively connected to the core control module. It is used to implement the EtherCAT slave protocol, interact with the EtherCAT master station, and send EtherCAT slave protocol data packets from the core control module to the EtherCAT master station, or transmit instruction data packets from the EtherCAT master station to the core control module. The storage module, connected to the core control module, is used to store the program, protocol configuration information, and temporary data during the operation of the real-time operating system.

[0013] A third aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the steps described in the method.

[0014] A fourth aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described.

[0015] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows: This application enables a single gateway to connect to multiple Modbus slave devices in parallel by setting at least two independent Modbus master communication interfaces. This approach directly solves the problem of limited access capacity of a single gateway in the background technology, significantly reducing the number of gateways required for the same device access scale. This effectively reduces hardware procurement costs, saves installation space, and simplifies the field cabling network structure, closely combining technical effectiveness with practical application.

[0016] By running a core control module of a real-time operating system, the gateway is provided with powerful multi-task management and scheduling capabilities. This enables the efficient reception and management of data acquired in parallel, with the core control module performing processing tasks such as parsing and encapsulation. The introduction of the real-time operating system ensures priority scheduling and deterministic response for data processing tasks, thereby meeting the real-time requirements of data acquisition and forwarding in industrial settings. The technical effectiveness is achieved through the combined effect of the real-time operating system and parallel acquisition.

[0017] The solution clearly defines the steps for EtherCAT network interaction via the EtherCAT slave module, separating them from the Modbus-side operations. This modular and process-oriented approach ensures that the uplink data flow (Modbus→EtherCAT) and the downlink command flow (EtherCAT→Modbus) are clear, independent, and do not interfere with each other. The entire process is coordinated centrally by the core control module, ensuring the accuracy of protocol conversion and the reliability of bidirectional communication. This technical effectiveness stems from the combination of the core control module's parsing and conversion functions and the dedicated interface functions of the EtherCAT slave module. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a protocol conversion method from multiple Modbus masters to EtherCAT slaves, provided for an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0019] Figure label: 810, Processor; 820, Communication interface; 830, Memory; 840, Communication bus. Detailed Implementation

[0020] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0021] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0022] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0023] Example 1 like Figure 1 As shown, a protocol conversion method from multiple Modbus masters to EtherCAT slaves includes: Data from multiple Modbus slave devices can be collected in parallel or commands can be sent to them through at least two independent Modbus master communication interfaces.

[0024] As mentioned above, the core of this step lies in utilizing multiple independent Modbus master communication interfaces to achieve parallel data interaction, thereby improving the gateway's access capabilities and processing efficiency. Specifically, "at least two independent Modbus master communication interfaces" means that the gateway hardware is configured with two or more physical communication channels (such as interfaces based on RS-485 or RS-422 standards), each channel possessing complete Modbus master functionality, capable of independently initiating communication requests, managing connections, and following the address space of subordinate devices. This independence ensures that the interfaces do not interfere with each other during operation, avoiding communication conflicts or delays caused by too many devices in a single-bus architecture. "Parallel acquisition of data from multiple Modbus slave devices, or issuing commands to them" describes the collaborative working mode of these interfaces: the gateway simultaneously drives all interfaces through an internal scheduling mechanism (such as multi-task management based on a real-time operating system), enabling them to perform data reading or command writing operations on different Modbus slave devices within the same time period. This parallel processing not only significantly improves data throughput, but also optimizes network load distribution through a regional and device-group communication strategy, thereby meeting the needs of industrial sites for multi-device, high-real-time data acquisition and control.

[0025] For example, in a typical industrial automation scenario, such as a material conveyor line in a smart warehousing system, multiple Modbus slave devices are distributed, including temperature sensors, motor drivers, photoelectric switches, and barcode readers. These devices may be divided into different groups based on function or physical location (e.g., the sensor group in area A and the actuator group in area B). The implementation process of this solution is as follows: The gateway's two independent Modbus master interfaces are connected to the Modbus buses of area A and area B, respectively. During operation, the gateway collects real-time data from all temperature sensors in area A in parallel through the first interface (e.g., reading register values ​​once per second), while simultaneously sending speed control commands to the motor drivers in area B through the second interface (e.g., writing target speed values ​​every 200 milliseconds). This parallel operation allows the gateway to complete synchronous data interaction across areas and multiple types of devices within one communication cycle, without waiting for polling of each device on a single interface, thus significantly shortening system response time and improving overall control efficiency. Furthermore, if a device connected to one interface fails, other interfaces can still operate normally, enhancing the system's reliability and fault tolerance.

[0026] The core control module of the real-time operating system parses the collected Modbus protocol data and encapsulates the parsed valid data into EtherCAT slave protocol data packets; or, it parses the received EtherCAT protocol data packets and converts them into Modbus protocol commands.

[0027] As described above, this step outlines the core processing logic of the protocol conversion gateway. The core control module, running a real-time operating system, coordinates the bidirectional, accurate, and efficient conversion between Modbus and EtherCAT protocols. Specifically, it first parses the raw Modbus protocol data acquired in parallel from multiple interfaces. This process includes not only disassembling the data frame structure (such as identifying slave addresses, function codes, register addresses, data content, and CRC checksums) but also extracting valid information and removing erroneous frames to ensure data integrity and reliability. Subsequently, the core control module reorganizes and encapsulates the extracted valid data (such as sensor values ​​and device status) according to the EtherCAT slave protocol specifications (e.g., CoE object dictionary mapping) to generate standardized data packets that can be recognized and processed by the EtherCAT master station. Conversely, when the gateway receives a command data packet from the EtherCAT master station, the core control module executes this process in reverse: parsing the EtherCAT packet to obtain the control target (corresponding to a specific Modbus slave station) and operation content (such as the value written to the register), and then generating a command frame conforming to the Modbus protocol format (including the correct slave address, function code, and data structure). This series of operations is completed under the unified scheduling and management of the real-time operating system. The operating system, through priority allocation, task switching, and interrupt response mechanisms, ensures that critical tasks such as parsing, conversion, and encapsulation can meet the stringent timing and deterministic requirements of industrial environments, which is crucial for achieving seamless data exchange and real-time control between heterogeneous networks.

[0028] For example, suppose on a smart packaging production line, an EtherCAT master PLC needs to monitor the readings of multiple Modbus temperature sensors in real time and control the start and stop of Modbus motors. The gateway collects data from sensor 1 (25.5℃) and motor 2 (stopped) through its two Modbus master interfaces. The core control module's "protocol parsing task" processes these two data streams simultaneously: parsing the temperature register value of slave station 1 and the coil status value of slave station 2. Then, the "protocol conversion task" encapsulates these two physically independent but logically related data points into different data areas within the same EtherCAT data packet, according to a pre-defined mapping relationship in the EtherCAT object dictionary. After this data packet is sent to the PLC via the EtherCAT slave module, the PLC may immediately issue a command packet requesting the start of motor 2. The gateway's EtherCAT slave module receives the instruction packet and passes it to the core control module. The core control module parses the instruction to "write a start command to the coil at Modbus address 2," then schedules the corresponding Modbus master task to generate a Modbus-RTU instruction frame containing address 2, function code 05 (write a single coil), and the value FF00 (start). This frame is then sent through the corresponding interface, completing a closed-loop control cycle from EtherCAT instruction to Modbus action. The entire process is executed efficiently and systematically in a pipeline manner under the coordination of the real-time operating system.

[0029] The EtherCAT slave module sends the encapsulated EtherCAT slave protocol data packets to the EtherCAT master station, or receives instruction data packets from the EtherCAT master station and transmits them to the core control module.

[0030] As described above, this step defines the key interfaces and processes for secure, reliable, and real-time interaction between the gateway and the high-speed EtherCAT network. Specifically, the "EtherCAT slave module" is a hardware functional entity that integrates a dedicated slave controller chip, an Ethernet physical layer interface, and related peripheral circuits. Its core function is to act as the gateway's legitimate "identity" in the EtherCAT network, strictly adhering to the EtherCAT standard protocol stack, and handling low-level communication details including data link layer frame transmission and reception, distributed clock synchronization, mailbox communication, and process data exchange. When it is necessary to "send the encapsulated EtherCAT slave protocol data packet to the EtherCAT master station," this module receives valid data organized according to the EtherCAT application layer protocol (such as CoE) from the core control module (usually via a high-speed serial bus such as SPI). Then, the slave controller chip precisely inserts this data into the designated position (i.e., its allocated "process data output" area) of the EtherCAT data frame flowing through this node, ensuring the correctness of frame verification information, so that the data can be transmitted "online" with the Ethernet frame and read by the master station in the next network cycle. Conversely, when receiving instruction data packets from the EtherCAT master station, this module extracts the data written by the master station to its "process data input" area in real time from the flowing EtherCAT frames, or receives instruction information from mailbox communication. Then, through interrupt or polling mechanisms, it promptly transmits these raw instruction data packets to the core control module for upper-layer parsing and conversion. This process ensures that the gateway can act as a slave node in the EtherCAT network, uploading data from its proxied Modbus devices in real time, and can also respond to the master station's control commands immediately, achieving seamless bridging of heterogeneous networks at the data link layer.

[0031] For example, consider a cluster control system for photovoltaic panel cleaning robots. An EtherCAT master station (a high-performance motion controller) needs to coordinate dozens of robots, each connected to multiple Modbus drivers and sensors via a gateway provided by this solution. Within a communication cycle (e.g., 1 ms), an EtherCAT slave module of a gateway performs the following operations: First, it quickly reads data written to its input area by the master station from the flowing EtherCAT frame. This data may contain target torque values ​​for specific joint motors of the robot. The module immediately transmits this data packet to the core control module via SPI. Almost simultaneously, the core control module has encapsulated Modbus data collected in the previous cycle, such as the robot's joint position and motor temperature, and sends it to the EtherCAT slave module via SPI. This module then writes this data into the output area of ​​the EtherCAT frame to be passed to the next node. The entire "read-forward" and "receive-insert" process is completed within microseconds, ensuring the master station obtains the latest status of all robots and issues the latest commands, achieving precise synchronous motion control. If the master station sends an "emergency stop" broadcast command via email service, the EtherCAT slave module of the relevant gateway can reliably receive it and notify the core control module, which will then quickly generate a corresponding Modbus emergency stop command and send it to all connected drives.

[0032] According to one embodiment of this application, the parallel data acquisition or command issuance via at least two independent Modbus master station communication interfaces specifically includes: Up to 16 Modbus slave devices can be connected via four RS-485 interfaces or two RS-422 interfaces; Multiple independent Modbus data acquisition tasks, scheduled by the core control module, send data reading instructions or control instructions to each Modbus slave device at preset intervals.

[0033] As mentioned above, at the hardware interface configuration level, this solution specifically adopts two physical interface modes: one provides four RS-485 interfaces, and the other provides two RS-422 interfaces. The RS-485 interfaces support half-duplex, multi-point communication, and each interface can connect multiple Modbus slave devices; the RS-422 interfaces support full-duplex, point-to-point, or point-to-multipoint communication, and both interfaces can also achieve multi-device connection. Through these two interface modes, the gateway can physically connect up to 16 Modbus slave devices. This upper limit is jointly limited by interface driver capabilities, bus load, and protocol address management logic, enabling centralized access of a large number of slave devices on a single gateway hardware platform.

[0034] At the software scheduling and execution level, the parallel acquisition and command issuance functions are implemented by the real-time operating system running in the core control module. The operating system creates and schedules multiple independent "Modbus data acquisition tasks," each specifically responsible for the communication management of one physical interface. These tasks are activated and executed according to a preset, configurable period (e.g., 100ms). During execution, each task, based on its managed slave device list, sequentially or as needed sends standard-format data read request frames (e.g., function code 03 to read holding registers) or control command frames (e.g., function code 06 to write a single register) to the corresponding Modbus slave address. Through the operating system's multi-task concurrency mechanism, these communication commands for different interfaces and different slave devices can overlap or alternate in time, thus achieving parallel processing of multiple Modbus communications at a macroscopic level, significantly improving the overall efficiency and real-time performance of data acquisition and control.

[0035] According to one embodiment of this application, the parsing of the collected Modbus protocol data includes: performing CRC verification on the received Modbus-RTU data frame, and extracting the device address and register value as valid data after the verification passes.

[0036] As described above, firstly, the gateway performs a Cyclic Redundancy Check (CRC check) on the complete data frames received through the physical interface and returned by the Modbus slave device. This check process, based on the Modbus-RTU protocol standard, uses a specific polynomial algorithm to calculate all bytes in the data frame except for the check bit itself, and compares the calculation result with the CRC checksum appended to the end of the data frame. If they match, the frame is determined to have no errors during transmission, and the check passes; if they do not match, it is determined to be an erroneous frame and discarded without further processing, thus ensuring the integrity and reliability of the processed data.

[0037] After the CRC check passes, the gateway's parsing program will disassemble the data frame and extract key valid information. Two main items are extracted: first, the "device address," which is the unique address code of the responding slave station identified by the first byte of the data frame, used to confirm the data's origin; second, the "register value," which is the actual data payload following the function code and other fields in the data frame. Its specific meaning and format are determined by the function code used when sending the request, and may include, for example, coil status, input status, or register value. The extracted device address and register value constitute the valid data refined from the original communication frame, which can be directly used in subsequent protocol conversion steps.

[0038] According to one embodiment of this application, the step of encapsulating the parsed valid data into an EtherCAT slave protocol data packet includes: mapping and encapsulating the register addresses and data of the Modbus slave device into a data packet conforming to the EtherCAT protocol format according to the EtherCAT CoE object dictionary (CoE) specification.

[0039] As mentioned above, the core of this process is adhering to the "CANopen over EtherCAT" (CoE) application layer specification in the EtherCAT protocol. First, a mapping relationship, or "object dictionary," needs to be established within the gateway. This dictionary predefines each entry (index and sub-index) in the EtherCAT slave object dictionary, and each entry is explicitly associated with a specific Modbus slave device and its register address (e.g., holding register 40001 of device 1). When data packets need to be encapsulated, the gateway performs data transfer and organization based on this mapping relationship: the extracted Modbus register values ​​(valid data) are filled into the data area corresponding to the target object dictionary entry in the EtherCAT slave protocol data packet. Simultaneously, the data packet includes necessary CoE service header information to indicate the operation type (e.g., upload or download) and the target index. Finally, a data packet whose structure, format, and semantics fully conform to the EtherCAT slave protocol standard is formed for transmission to the master station via the EtherCAT network. This method achieves standardized and efficient transmission of data models between heterogeneous devices.

[0040] According to one embodiment of this application, the parsing and conversion of the received EtherCAT protocol data packet includes: performing Frame Check Sequence (FCS) verification on the data packet, extracting the control instruction content after the verification passes, and generating a Modbus-RTU instruction frame containing the target Modbus slave address and the control register address.

[0041] As described above, firstly, the gateway performs Frame Check Sequence (FCS) verification on the received raw EtherCAT Ethernet data frames. This verification, based on the standard Ethernet specification, calculates the content of the data frame and compares it with the checksum at the end of the frame. If the verification passes, it confirms that no errors occurred during data transmission, ensuring the reliability of subsequent processing.

[0042] After successful verification, the gateway parses the application layer content of the EtherCAT data packet. Based on the CoE (CANopen over EtherCAT) protocol specifications it follows, it extracts the core control commands from the data packet. This typically includes: the target Modbus slave device address, the address of the Modbus register to be operated on, and the specific data to be written to that register or the control command to be executed.

[0043] Finally, the gateway constructs a complete command frame conforming to the Modbus-RTU protocol format based on the extracted instruction content. This frame will contain the target slave address, the corresponding function code (e.g., 06 write single register), the control register address, the instruction data, and the CRC checksum. This command frame can then be sent to the specified slave device through the corresponding Modbus master interface, thereby completing the conversion from EtherCAT instructions to Modbus actions.

[0044] According to one embodiment of this application, the core control module executes the parsing, encapsulation, or conversion steps through multi-task scheduling, wherein the tasks include at least periodically running Modbus data acquisition tasks, protocol conversion tasks, and EtherCAT data processing tasks in response to interruptions.

[0045] As described above, the real-time operating system creates and manages multiple tasks with different attributes and responsibilities within the core control module. First, the periodically running Modbus data acquisition task is responsible for actively initiating communication. It is scheduled and executed by the operating system at preset time intervals, sending query requests or control commands to connected slave devices through the Modbus master interfaces. Second, the protocol conversion task also runs periodically. Its main responsibility is data processing: after the Modbus data acquisition task places the read valid data into the shared data area, the protocol conversion task retrieves this data and performs the encapsulation into EtherCAT data packets; conversely, when there are instructions to be issued, it performs the generation of Modbus instruction frames. Finally, the interrupt-responding EtherCAT data processing task has event-driven characteristics. It is usually in a dormant state. Once the EtherCAT slave module notifies of a data packet arrival from the master station via a hardware interrupt signal, the operating system immediately suspends low-priority tasks, wakes up and executes this task, enabling it to process the received EtherCAT instructions promptly. The operating system ensures that these three (or more) tasks can work together efficiently, orderly, and in real time to complete the bidirectional protocol conversion process through priority scheduling, time-slice rotation, or event triggering.

[0046] According to one embodiment of this application, the method further includes an uplink feedback process: after issuing a command to the Modbus slave device, the response data of the device is received, parsed and encapsulated, and then fed back to the EtherCAT master station through the EtherCAT slave module to form a command closed loop.

[0047] As described above, the process does not end after the gateway completes the step of "sending EtherCAT commands to the Modbus slave." Next, the controlled target Modbus slave device will perform corresponding operations based on the received commands (such as changing register values ​​or performing actions), and will typically return a response data frame (e.g., an acknowledgment of a write command, or a response containing new status data). The gateway receives the device's response data through the corresponding Modbus master interface.

[0048] Subsequently, the gateway performs similar processing on this response data as the uplink process: first, it parses the data (e.g., CRC check, extracting response status or data), then encapsulates the parsed valid information into a feedback data packet conforming to the EtherCAT protocol format. Finally, this feedback data packet is sent back to the EtherCAT master station that initially issued the command through the EtherCAT slave module.

[0049] This uplink feedback process enables the EtherCAT master station to obtain timely and accurate information about the execution results of its issued commands on remote Modbus devices or the latest status of the devices, thereby realizing a closed-loop command system from command issuance and execution to result feedback, enhancing the reliability, observability, and interactive integrity of the entire control system.

[0050] A second aspect of this application provides a protocol conversion gateway for multiple Modbus masters to EtherCAT slaves, comprising: The Modbus master interface module provides at least two independent Modbus master communication interfaces to connect multiple Modbus slave devices in parallel. The core control module is communicatively connected to the Modbus master interface module and is used to run a real-time operating system. It parses Modbus protocol data from the Modbus master interface module through multi-task scheduling and converts the parsed data into EtherCAT slave protocol data packets, or parses the received EtherCAT protocol data packets and converts them into Modbus protocol instructions. The EtherCAT slave module is communicatively connected to the core control module. It is used to implement the EtherCAT slave protocol, interact with the EtherCAT master station, and send EtherCAT slave protocol data packets from the core control module to the EtherCAT master station, or transmit instruction data packets from the EtherCAT master station to the core control module. The storage module, connected to the core control module, is used to store the program, protocol configuration information, and temporary data during the operation of the real-time operating system.

[0051] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any of the first aspects above.

[0052] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect described above, the method including: Data from multiple Modbus slave devices can be collected in parallel or commands can be sent to them through at least two independent Modbus master communication interfaces. By running the core control module of the real-time operating system, the collected Modbus protocol data is parsed and the parsed valid data is encapsulated into EtherCAT slave protocol data packets; or, the received EtherCAT protocol data packets are parsed and converted into Modbus protocol commands. The EtherCAT slave module sends the encapsulated EtherCAT slave protocol data packets to the EtherCAT master station, or receives instruction data packets from the EtherCAT master station and transmits them to the core control module.

[0053] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0054] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer being able to perform the methods provided by the above methods, the method comprising: Data from multiple Modbus slave devices can be collected in parallel or commands can be sent to them through at least two independent Modbus master communication interfaces. By running the core control module of the real-time operating system, the collected Modbus protocol data is parsed and the parsed valid data is encapsulated into EtherCAT slave protocol data packets; or, the received EtherCAT protocol data packets are parsed and converted into Modbus protocol commands. The EtherCAT slave module sends the encapsulated EtherCAT slave protocol data packets to the EtherCAT master station, or receives instruction data packets from the EtherCAT master station and transmits them to the core control module.

[0055] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the methods provided by the above methods, the method comprising: Data from multiple Modbus slave devices can be collected in parallel or commands can be sent to them through at least two independent Modbus master communication interfaces. By running the core control module of the real-time operating system, the collected Modbus protocol data is parsed and the parsed valid data is encapsulated into EtherCAT slave protocol data packets; or, the received EtherCAT protocol data packets are parsed and converted into Modbus protocol commands. The EtherCAT slave module sends the encapsulated EtherCAT slave protocol data packets to the EtherCAT master station, or receives instruction data packets from the EtherCAT master station and transmits them to the core control module.

[0056] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0057] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0058] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A protocol conversion method from a multi-Modbus master to an EtherCAT slave, characterized in that, The method is applied to a protocol conversion gateway, and comprises the following steps: Collecting data of or issuing instructions to multiple Modbus slave devices in parallel through at least two independent Modbus master communication interfaces; Analyzing the collected Modbus protocol data through a core control module running a real-time operating system, and encapsulating the analyzed effective data into an EtherCAT slave protocol data packet; or analyzing and converting an EtherCAT protocol data packet received into a Modbus protocol instruction; Sending the encapsulated EtherCAT slave protocol data packet to an EtherCAT master through an EtherCAT slave module, or receiving an instruction data packet from the EtherCAT master and transmitting the data packet to the core control module.

2. The method of claim 1, wherein, The data collection or instruction issuance through the at least two independent Modbus master communication interfaces in parallel specifically comprises the following steps: Connecting a maximum of 16 Modbus slave devices through four RS-485 interfaces or two RS-422 interfaces; Sending data reading instructions or control instructions to each Modbus slave device in a preset period through multiple independent Modbus data collection tasks scheduled by the core control module.

3. The method of claim 1, wherein, The analysis of the collected Modbus protocol data comprises the following steps: performing CRC check on a received Modbus-RTU data frame, and extracting a device address and a register value as effective data after the check is passed.

4. The method of claim 1, wherein, The encapsulation of the analyzed effective data into an EtherCAT slave protocol data packet comprises the following steps: mapping and encapsulating a register address and data of a Modbus slave device into a data packet conforming to an EtherCAT protocol format according to an EtherCAT slave object dictionary (CoE) specification.

5. The method of claim 1, wherein, The analysis and conversion of the received EtherCAT protocol data packet comprises the following steps: performing frame check sequence (FCS) check on the data packet, extracting control instruction content after the check is passed, and generating a Modbus-RTU instruction frame containing a target Modbus slave address and a control register address.

6. The method of claim 1, wherein, The core control module performs the analysis, encapsulation or conversion steps through multitasking scheduling, and the tasks at least include a periodically running Modbus data collection task, a protocol conversion task and an EtherCAT data processing task responding to an interruption.

7. The method of claim 1, wherein, The method further comprises an uplink feedback process: after issuing an instruction to a Modbus slave device, receiving response data of the device, feeding back the data to an EtherCAT master through the EtherCAT slave module after analysis and encapsulation, and forming an instruction closed loop.

8. A protocol conversion gateway from a multi-Modbus master to an EtherCAT slave, characterized in that, The method comprises the following steps: A Modbus master interface module is configured to provide at least two independent Modbus master communication interfaces to access multiple Modbus slave devices in parallel; a core control module, in communication connection with the Modbus master station interface module, for running a real-time operating system, parsing Modbus protocol data from the Modbus master station interface module through multi-task scheduling, and converting the parsed data into EtherCAT slave protocol data packets, or parsing received EtherCAT protocol data packets and converting them into Modbus protocol instructions; an EtherCAT slave module, in communication connection with the core control module, for implementing an EtherCAT slave protocol, interacting with an EtherCAT master station for data, and sending EtherCAT slave protocol data packets from the core control module to the EtherCAT master station, or transmitting instruction data packets from the EtherCAT master station to the core control module; a storage module, in connection with the core control module, for storing programs of the real-time operating system, protocol configuration information, and temporary data in the running process.

9. A computer-readable storage medium having stored thereon a program, characterized in that, The program is executed by the processor to implement the steps in the method of any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps in the method of any one of claims 1-7.

Images