A host computer communication method supporting a multi-protocol coupler

Abstract

The application relates to a host computer communication method supporting a multi-protocol coupler, which comprises the following steps: determining the protocol type of a target coupler according to the device discovery result of the target coupler, selecting a protocol driver and a transmission channel, constructing a private protocol frame in a unified format, encapsulating and sending the private protocol frame to the target coupler, receiving response data returned by the target coupler, extracting and checking a response private protocol frame, analyzing an execution result, and updating a configuration management database when the execution is successful. The host computer communication method supporting the multi-protocol coupler can solve the problems that couplers of different protocol types usually adopt separate software tools or independent communication paths, leading to repeated implementation of the same configuration semantics under different protocols and increased maintenance cost; meanwhile, in an EtherCAT network environment, the function lacks a unified, efficient and stable host computer communication path, affecting the device configuration efficiency and the system continuous operation ability.

Description

Technical Field

[0001] This invention relates to the field of industrial automation communication technology, and more specifically to a host computer communication method that supports multi-protocol couplers. Background Technology

[0002] In industrial automation systems, couplers typically serve as communication bridges between the host control system and remote input / output modules, undertaking tasks such as parameter configuration, topology identification, status diagnosis, and data exchange. With the increasing variety of fieldbus protocols, couplers using multiple protocols, such as EtherCAT, PROFINET, Ethernet / IP, and CC-Link, often coexist within the same equipment manufacturing system. Therefore, the host computer typically needs the ability to identify, connect, and configure devices using different protocols.

[0003] In existing solutions, couplers of different protocol types typically use separate software tools or independent communication paths, resulting in the same configuration semantics being repeatedly implemented under different protocols, increasing maintenance costs. At the same time, in the EtherCAT network environment, the standard PDO, SDO, and CoE mechanisms have limited direct carrying capacity for manufacturer-specific protocol frames, and functions such as online parameter adjustment, firmware upgrades, and diagnostic data acquisition lack a unified, efficient, and stable host computer communication path, which in turn affects device configuration efficiency and system continuous operation capability.

[0004] Therefore, existing technologies have shortcomings and need to be improved and developed. Summary of the Invention

[0005] The present invention provides a host computer communication method that supports multi-protocol couplers, which solves the problem that in the prior art, couplers of different protocol types usually use separate software tools or independent communication paths, resulting in the same configuration semantics being repeatedly implemented under different protocols, increasing maintenance costs; the main solution is to address the problem in the EtherCAT network environment that lacks a unified, efficient and stable host computer communication path, which affects the efficiency of device configuration and the continuous operation capability of the system.

[0006] This invention provides a host computer communication method supporting multi-protocol couplers, comprising:

[0007] Based on the device discovery results of the target coupler, the protocol type of the target coupler is determined to be one of EtherCAT, PROFINET, Ethernet / IP, and CC-Link protocols, and the corresponding protocol driver and transmission channel are selected.

[0008] Construct a private protocol frame with a unified format, wherein the private protocol frame includes at least a frame header, function code, device address, parameter area, data area, version number and CRC16 checksum;

[0009] The private protocol frame is encapsulated according to the protocol type and sent to the target coupler. Specifically, when the protocol type is EtherCAT, the private protocol frame is encapsulated in UDP, IP and Ethernet in sequence and then sent through an EoE mailbox. When the protocol type is PROFINET or Ethernet / IP, the private protocol frame is encapsulated into a standard UDP data packet and then sent. When the protocol type is CC-Link, the private protocol frame is encapsulated into a USB data packet and then sent.

[0010] Receive response data returned by the target coupler, extract and verify the private protocol frame of the response, parse the execution result, and update the execution result and version information in the configuration management database when the execution is successful.

[0011] Furthermore, determining the protocol type of the target coupler as one of EtherCAT, PROFINET, Ethernet / IP, and CC-Link protocols based on the device discovery results of the target coupler, and selecting the corresponding protocol driver and transmission channel, includes:

[0012] The EtherCAT protocol type is determined by scanning EtherCAT slave stations and obtaining EoE network parameters.

[0013] The PROFINET protocol type is determined by the DCP protocol discovery results;

[0014] The Ethernet / IP protocol type can be determined by the results of UDP broadcast discovery.

[0015] The USB CDC driver establishes a USB connection with the CC-Link coupler to determine the CC-Link protocol type;

[0016] Invoke the protocol driver corresponding to the protocol type to execute the private protocol frame sending and response receiving.

[0017] Furthermore, the frame header is a 2-byte fixed synchronization identifier 0xAA55; the device address is a 2-byte logical address, where the high byte represents the module number and the low byte represents the channel number; the parameter area includes at least a 4-byte parameter identifier and a 2-byte parameter length; the version number is an 8-byte configuration version number; the CRC16 checksum is generated using the CRC-16 / Modbus algorithm; and the total length of the private protocol frame is 15+M+N bytes, where M is the parameter area length and N is the data area length.

[0018] Furthermore, the function code includes at least the following: 0x01 indicates reading ordinary parameters, 0x02 indicates writing ordinary parameters, 0x11 indicates reading hot configuration parameters, 0x12 indicates writing hot configuration parameters, 0x20 indicates querying topology information, 0x30 indicates transmitting firmware upgrade data, and 0x40 indicates collecting diagnostic data; when the highest bit of the function code is 1, it indicates a response frame.

[0019] Furthermore, when the protocol type is EtherCAT, the step of determining the protocol type of the target coupler and selecting the corresponding protocol driver and transmission channel based on the device discovery result of the target coupler includes:

[0020] Open and bind the specified network adapter;

[0021] Send broadcast frames to scan the EtherCAT network, identify slave devices and read the manufacturer's identifier, product code and version number, and assign logical addresses to each slave in an incrementing manner starting from 1, according to the physical connection order of the slaves in the network topology.

[0022] For slave stations that support EoE functionality, the GetIP command is used to read the current network parameters of the slave station. If the read MAC address or IP address is invalid, a unique MAC address and an IP address in the same network segment as the host computer are generated and sent to the corresponding slave station via the SetIP command.

[0023] The slave station is switched from the Init state to the Pre-Operational state to establish an EoE communication channel.

[0024] Furthermore, it also includes constructing a forward mapping table from station number to network parameter information and a reverse mapping table from IP address to slave station number. The network parameter information includes at least IP address, MAC address, subnet mask, gateway, and port number. During the sending phase, the slave station number is determined from the target IP address based on the reverse mapping table. During the encapsulation phase, the destination MAC address is obtained from the slave station number based on the forward mapping table. The forward mapping table and the reverse mapping table are updated synchronously when the slave station network parameters change. The unique MAC address is obtained by combining a fixed prefix 8C:F3:E7 and a 3-byte random number.

[0025] Furthermore, when the protocol type is EtherCAT, the encapsulation and transmission of the private protocol frame according to the protocol type includes:

[0026] The private protocol frame is used as a UDP payload with a UDP header. The source port of the UDP header is 34981, the destination port is 50001, and the UDP length is 8+L, where L is the length of the private protocol frame. The UDP checksum is calculated based on the pseudo header containing the source IP address, destination IP address, protocol number, and UDP length.

[0027] An IP header is added to the outside of the UDP packet. The total length of the IP header is 20+8+L, where the Time to Live (TTL) field is 64 and the protocol field is 0x11. Checksums are also performed on the IP header.

[0028] An Ethernet header is added to the outside of the IP packet, and the EtherType field in the Ethernet header is 0x0800;

[0029] The EoE send interface of the EtherCAT master station is called to send the encapsulated Ethernet frame to the target coupler.

[0030] Furthermore, the step of receiving the response data returned by the target coupler, extracting and verifying the response private protocol frame includes:

[0031] Obtain the raw data packet via the EoE email receiving interface;

[0032] Verify that the destination MAC address matches the local machine's MAC address and that the EtherType field is 0x0800;

[0033] Parse the IP header length, which is the result of a bitwise AND operation between the first byte and 0x0F multiplied by 4, and verify that the protocol field is 0x11;

[0034] Extract the source port, destination port, and UDP length from the UDP header;

[0035] Extract the private protocol frame based on the UDP data start position and UDP length, verify that the frame header is 0xAA55, and compare the calculated CRC16 check value with the frame tail check code;

[0036] After the verification is successful, the function code, device address, parameter area, data area and version number are parsed, and the lower 7 bits of the response frame function code are checked for consistency with the corresponding request frame function code. The response frame function code is the result of a bitwise OR operation between the request frame function code and 0x80.

[0037] Furthermore, it also includes a parameter hot configuration process, which includes:

[0038] The host computer constructs a private protocol frame containing hot configuration parameters written to function code 0x12 and sends it to the coupler;

[0039] After parsing the private protocol frame, the coupler forwards the configuration request to the target remote input / output module;

[0040] The target remote input / output module writes the new parameters into the backup configuration buffer and switches the buffers by exchanging pointers between the running configuration buffer and the backup configuration buffer, so that the new parameters take effect.

[0041] The target remote input / output module returns the execution result and the current configuration version number.

[0042] Furthermore, updating the execution results and version information in the configuration management database includes: updating the execution results and version information in the configuration management database after a successful configuration change, incrementing the version number and recording historical versions; upon receiving a configuration rollback command and the corresponding historical version number, reading the configuration parameter snapshot corresponding to the historical version number from the configuration management database, constructing each parameter in the configuration parameter snapshot into a private protocol frame, and redistributing it to the target coupler and the target remote input / output module through the corresponding transmission channel. The target remote input / output module then uses a double-buffering switching mechanism to make the historical version configuration effective and updates the current version number in the configuration management database.

[0043] Beneficial effects:

[0044] As can be seen from the above technical solutions, the present invention provides a host computer communication method that supports multi-protocol couplers, which has the following beneficial effects:

[0045] 1. By establishing a layered system on the host computer side, consisting of a unified private protocol frame, protocol adapter driver, and physical interface layer, application semantics such as parameter configuration, topology discovery, device diagnostics, and firmware upgrades are extracted from specific protocol differences. This allows the same set of business processing logic to be reused for EtherCAT, PROFINET, Ethernet / IP, and CC-Link couplers. This reuse is not simply a unified interface, but a deep reuse built on a unified frame structure, unified function code semantics, and unified transmit and receive interfaces. Therefore, it reduces the workload of repeatedly developing business processing logic for different protocols and facilitates subsequent extensions of new protocols only at the driver layer without modifying the application layer.

[0046] 2. To address the issue of manufacturer-specific protocols being difficult to directly carry in an EtherCAT environment, a proposed approach is to encapsulate the proprietary protocol frames sequentially with UDP, IP, and Ethernet before sending them via an EoE mailbox. This enables the EtherCAT network to stably transmit configuration, diagnostic, and upgrade-related proprietary messages. This approach allows proprietary business semantics to achieve length control, address location, and verification capabilities at the standard message level, avoiding message segmentation, multiple round trips, and efficiency limitations caused by relying solely on traditional object dictionary interactions. Therefore, it is more suitable for centralized management of couplers by a host computer and online parameter distribution.

[0047] 3. Hot parameter configuration is achieved through a double-buffered configuration area and a configuration pointer switching mechanism. New parameters are first written to the backup configuration area, and then switched to the running state via pointer exchange after writing is complete. This solves the problem of parameters being in an intermediate state and interference between business access and parameter writing during online updates. Furthermore, a management mechanism for version numbers, execution result records, historical version saving, and restoration by historical version is introduced, enabling online configurations to not only take effect immediately but also have subsequent rollback and recovery capabilities. Therefore, on-site parameter adjustments can meet the requirement of no downtime while also ensuring operational stability and recoverability.

[0048] 4. In EtherCAT scenarios, a forward mapping table from station number to network parameter information and a reverse mapping table from IP address to station number are introduced. This allows target station location, destination MAC address acquisition, and network parameter updates during message transmission to be completed through indexes. This mechanism transforms the routing process, which might have relied on traversal lookups, into a mapping table lookup process. From an engineering implementation perspective, this reduces lookup latency fluctuations during high-frequency communication and provides a structured foundation for synchronous maintenance after network parameter changes. For scenarios with multiple slave stations, frequent configuration, or concurrent processing, this design helps improve the determinism and scalability of the host computer communication path.

[0049] It should be understood that all combinations of the foregoing concepts and the additional concepts described in more detail below can be considered part of the inventive subject matter of this disclosure, provided that such concepts do not contradict each other.

[0050] The foregoing and other aspects, embodiments, and features of the teachings of the present invention will be more fully understood from the following description in conjunction with the accompanying drawings. Other additional aspects of the invention, such as features and / or beneficial effects of exemplary embodiments, will become apparent from the following description or may be learned through practice of specific embodiments according to the teachings of the present invention. Attached Figure Description

[0051] The accompanying drawings are not drawn to scale. In the drawings, each identical or nearly identical component shown in the various figures may be denoted by the same reference numeral. For clarity, not every component is labeled in each figure. Embodiments of various aspects of the invention will now be described by way of example and with reference to the accompanying drawings, wherein:

[0052] Figure 1 This is a flowchart illustrating a host computer communication method supporting a multi-protocol coupler, as described in this application.

[0053] Figure 2 This is a flowchart of step S106 of a host computer communication method supporting a multi-protocol coupler in an embodiment of this application.

[0054] Figure 3 This is a hierarchical diagram of a unified architecture for a host computer communication method supporting multi-protocol couplers, as described in an embodiment of this application.

[0055] Figure 4 This is a schematic diagram of a unified private protocol frame format for a host computer communication method supporting multi-protocol couplers, as described in an embodiment of this application.

[0056] Figure 5 This is a function code definition table for a host computer communication method supporting a multi-protocol coupler, as described in an embodiment of this application.

[0057] Figure 6 This is a schematic diagram of private protocol frame multi-channel transmission in a host computer communication method supporting a multi-protocol coupler, as described in an embodiment of this application.

[0058] Figure 7 This is an EoE-UDP packet encapsulation hierarchy diagram of a host computer communication method supporting a multi-protocol coupler, as described in an embodiment of this application.

[0059] Figure 8 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention without creative effort are within the scope of protection of the present invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art to which this invention pertains.

[0061] The terms "first," "second," and similar words used in the specification and claims of this patent application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, unless the context clearly indicates otherwise, the singular forms of "an," "a," or "the," etc., do not indicate a quantity limitation, but rather indicate the presence of at least one. Terms such as "comprising" or "including" mean that the element or object preceding "comprising" encompasses the features, integrals, steps, operations, elements, and / or components listed following "comprising" or "including," and do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; these relative positional relationships may change accordingly when the absolute position of the described object changes.

[0062] In existing solutions, couplers of different protocol types typically use separate software tools or independent communication paths, resulting in the same configuration semantics being repeatedly implemented under different protocols, increasing maintenance costs. At the same time, in the EtherCAT network environment, the standard PDO, SDO, and CoE mechanisms have limited direct carrying capacity for manufacturer-specific protocol frames, and functions such as online parameter adjustment, firmware upgrades, and diagnostic data acquisition lack a unified, efficient, and stable host computer communication path, which in turn affects device configuration efficiency and system continuous operation capability.

[0063] Therefore, embodiments of the present invention provide a host computer communication method supporting multi-protocol couplers, referring to... Figure 1 ,include:

[0064] Step S102: Based on the device discovery results of the target coupler, determine the protocol type of the target coupler as one of EtherCAT, PROFINET, Ethernet / IP, and CC-Link protocols, and select the corresponding protocol driver and transmission channel.

[0065] Step S104: Construct a private protocol frame with a unified format. The private protocol frame includes at least a frame header, function code, device address, parameter area, data area, version number, and CRC16 checksum.

[0066] Step S106: Encapsulate the private protocol frame according to the protocol type and send it to the target coupler. When the protocol type is EtherCAT, the private protocol frame is encapsulated in UDP, IP and Ethernet in sequence and then sent through the EoE mailbox. When the protocol type is PROFINET or Ethernet / IP, the private protocol frame is encapsulated into a standard UDP data packet and then sent. When the protocol type is CC-Link, the private protocol frame is encapsulated into a USB data packet and then sent.

[0067] Step S108: Receive the response data returned by the target coupler, extract and verify the response private protocol frame, parse the execution result, and update the execution result and version information in the configuration management database when the execution is successful.

[0068] First, the protocol type of the target coupler is identified based on the device discovery results. Then, the host computer constructs a unified format private protocol frame and selects the corresponding driver and transmission channel according to different protocol types to complete the encapsulation and transmission. Finally, the response private protocol frame is parsed, verified, and the results are stored in the database. This essentially converges the differences between various fieldbus devices to the protocol identification and bearer channel level, while unifying the business semantics within the same private protocol frame, so that the host computer application layer does not need to design an independent business instruction system for each protocol.

[0069] By combining a unified private protocol frame with protocol-differentiated bearers, the semantics of the business layer are decoupled from the underlying transmission method. Through a unified frame format, differentiated drive transmission, and unified response parsing, a reusable cross-protocol communication backbone is formed. This allows the host computer to adapt to multiple couplers without changing the upper-layer business semantics, reducing the development burden of protocol extensions and providing a unified bearer foundation for subsequent application functions such as hot configuration, topology query, diagnostic data collection, and firmware upgrades. This improves the consistency of configuration tools and the efficiency of engineering deployment.

[0070] In some embodiments, the target coupler's protocol type is determined to be one of EtherCAT, PROFINET, Ethernet / IP, and CC-Link protocols based on the device discovery results, and the corresponding protocol driver and transmission channel are selected, referring to... Figure 3 The multi-protocol unified architecture hierarchy shown includes:

[0071] The EtherCAT protocol type is determined by scanning EtherCAT slave stations and obtaining EoE network parameters.

[0072] The PROFINET protocol type is determined by the results of the DCP protocol discovery.

[0073] The Ethernet / IP protocol type can be determined by the results of UDP broadcast discovery.

[0074] The USB CDC driver establishes a USB connection with the CC-Link coupler to determine the CC-Link protocol type.

[0075] Invoke the protocol driver corresponding to the protocol type to execute the private protocol frame sending and response receiving.

[0076] The discovery criteria for the four types of protocol devices are centrally defined, corresponding to EtherCAT slave scanning and EoE network parameter acquisition, PROFINET DCP discovery, Ethernet / IP UDP broadcast discovery, and CC-Link device USB connection establishment, respectively. Furthermore, the corresponding protocol driver is called through a unified private protocol interface to execute communication.

[0077] By unifying and abstracting the device discovery, protocol determination, and driver invocation processes of different protocol types into a single host computer identification framework, multi-protocol access no longer relies on independent access logic. This abstraction not only serves device discovery but also directly supports the subsequent transmission link of unified private protocol frames. By completing protocol classification and driver selection during the identification phase, the subsequent communication path of the host computer is clearer, which helps to shorten device access preparation time and reduce communication failures caused by protocol type misjudgment.

[0078] In some embodiments, reference is made to Figure 4 The frame header is a 2-byte fixed synchronization identifier 0xAA55; the device address is a 2-byte logical address, where the high byte represents the module number and the low byte represents the channel number; the parameter area includes at least a 4-byte parameter identifier and a 2-byte parameter length; the version number is an 8-byte configuration version number; the CRC16 checksum is generated using the CRC-16 / Modbus algorithm; the total length of the private protocol frame is 15+M+N bytes, where M is the parameter area length and N is the data area length.

[0079] The fixed fields, variable fields, and length composition of private protocol frames are defined to form a unified frame structure that is parsable, verifiable, and version-manageable. By setting the frame header, device address, parameter area, data area, version number, and CRC16 checksum, this feature ensures that communication between the host computer and the coupler no longer relies on the individual data semantics of different protocols, but instead relies on a unified manufacturer-side business frame semantics.

[0080] The minimum business elements required for parameter configuration, topology query, diagnostic data collection, and version management are compressed into a fixed framework, and the version number is directly incorporated into the frame structure, thus reserving a foundation for consistency verification, conflict detection, and history tracing. Compared to processing methods that rely solely on lower-level protocol native object dictionaries or register mappings, this frame structure is more suitable for cross-protocol reuse.

[0081] By using a unified field structure, the host computer can use consistent encoders, decoders, and verifiers to process data returned by devices with different protocols, reducing the risk of errors caused by the dispersion of parsing logic and providing a stable message foundation for version tracking and anomaly verification.

[0082] In some embodiments, reference is made to Figure 5 The function code includes at least the following: 0x01 indicates reading ordinary parameters, 0x02 indicates writing ordinary parameters, 0x11 indicates reading hot configuration parameters, 0x12 indicates writing hot configuration parameters, 0x20 indicates querying topology information, 0x30 indicates transmitting firmware upgrade data, and 0x40 indicates collecting diagnostic data. When the highest bit of the function code is 1, it indicates a response frame. The response frame function code is the result of bitwise ORing the corresponding request function code with 0x80.

[0083] The semantics of function codes in the unified private protocol frame are defined, and ordinary parameter reading and writing, hot configuration reading and writing, topology query, firmware upgrade and diagnostic collection are included in the same operation coding space. The highest bit identifies the response frame, so that each business operation has a clear frame-level semantic entry on the host computer side.

[0084] By unifying various management functions into a single function code system and establishing bidirectional communication rules through the encoding mapping between request and response frames, this approach avoids simple command enumeration. Instead, it employs a semantic abstraction oriented towards a unified proprietary protocol, facilitating the sharing of processing logic among protocol-driven modules. Therefore, through this unified function code system, the host computer can cover parameter, diagnostic, topology, and upgrade scenarios with a single set of business instructions, reducing the implementation complexity caused by designing separate message formats for different functions and improving the determinism of response matching and anomaly detection.

[0085] In some embodiments, when the protocol type is EtherCAT, the protocol type of the target coupler is determined based on the device discovery result of the target coupler, and the corresponding protocol driver and transmission channel are selected, including:

[0086] Open and bind the specified network adapter.

[0087] The system sends broadcast frames to scan the EtherCAT network, identifies slave devices, and reads their manufacturer identifiers, product codes, and version numbers. Logical addresses are assigned to each slave device in ascending order, starting from 1, according to their physical connection order in the network topology.

[0088] The specific rules are as follows:

[0089] (1) Allocation basis: After scanning the network through broadcast frames, the EtherCAT master station determines the number according to the connection order of the slave stations on the physical link, that is, the order in which the data frames pass through each slave station;

[0090] (2) Allocation rule: The first detected slave station is numbered 1, the second is numbered 2, and so on, until the total number of slave stations is reached;

[0091] (3) Address Purpose: This logical address serves as the unique identifier for locating the target slave station in EoE mailbox communication and is used as the key value in the bidirectional mapping table.

[0092] For slave devices that support EoE functionality, the GetIP command is used to read the current network parameters of the slave device. If the read MAC address or IP address is invalid, a unique MAC address and an IP address in the same network segment as the host computer are generated and sent to the corresponding slave device via the SetIP command.

[0093] The criteria for determining whether a MAC address or IP address is invalid are as follows:

[0094] The condition for determining an invalid MAC address is: the entire MAC address is zero, i.e., 00:00:00:00:00:00.

[0095] The conditions for determining an invalid IP address (any one of the following conditions must be met to determine it as invalid): The IP address is null or an empty string or the IP address is an all-zero address 0.0.0.0.

[0096] In some embodiments, invalid subnet masks and invalid gateway addresses are also added. The conditions for determining an invalid subnet mask are: the subnet mask is empty; an empty string; or the subnet mask is 0.0.0.0. The conditions for determining an invalid gateway address are: the gateway address is empty; an empty string; or the gateway address is 0.0.0.0. When any one of the MAC address, IP address, subnet mask, or gateway address meets the invalidity condition, the network parameters of the slave station are determined to be invalid, and subsequent address generation and distribution operations must be performed.

[0097] The slave will transition from the Init state to the Pre-Operational state to establish an EoE communication channel.

[0098] Specifically designed for EtherCAT scenarios, this document outlines the processes for device discovery, slave identification, EoE network parameter reading and setting, and state switching. After slave scanning and logical address allocation, a usable mailbox communication channel is established for slaves supporting EoE functionality to subsequently carry unified private protocol frames. The EoE channel establishment is embedded into the host computer's private protocol communication pre-process, creating a continuous closed loop between slave identification, network parameter preparation, and communication capability establishment. This process directly serves the specific purpose of carrying private protocol frames via EoE.

[0099] The handling methods for other protocols (PROFINET, Ethernet / IP, CC-Link) are as follows, please refer to... Figure 6 :

[0100] (1) PROFINET protocol driver:

[0101] The PROFINET coupler communicates with the host computer via a standard Ethernet connection. Its proprietary protocol frame transmission process is as follows:

[0102] Device discovery: The host computer discovers devices via the DCP (Discovery and Configuration Protocol) by sending a DCP Identify broadcast frame with EtherType 0x8892 (destination MAC is multicast address 01:0E:CF:00:00:00). PROFINET devices respond with a DCP Response frame, returning the device name, IP configuration, and vendor information.

[0103] Transmission Channel: After the device is discovered, a standard UDP Socket connection is established between the host computer and the PROFINET coupler. The private protocol frame is sent directly as the UDP payload without the need for EoE encapsulation.

[0104] Frame format: Uses the same proprietary protocol frame format as the EtherCAT channel.

[0105] (2) Ethernet / IP protocol driver:

[0106] Ethernet / IP couplers also communicate via standard Ethernet connections:

[0107] Device discovery: A ListIdentity request is sent via UDP broadcast port 44818. Ethernet / IP devices respond with device information, returning the vendor ID, device type, and product name.

[0108] Transmission Channel: After establishing a standard UDP Socket connection, private protocol frames are sent directly as UDP payload.

[0109] Frame format: Uses the same proprietary protocol frame format as the EtherCAT channel.

[0110] (3) CC-Link protocol driver:

[0111] CC-Link couplers communicate via a USB interface:

[0112] Device discovery: CC-Link devices are discovered through the operating system's USB enumeration mechanism. The device type is identified based on the USB device's VID / PID (vendor ID / product ID), and a USB CDC virtual serial port connection is established.

[0113] Transmission Channel: Private protocol frames are sent directly via USB virtual serial port, with a CRC-16 / Modbus checksum appended to the end of the frame.

[0114] Frame format: Uses the same proprietary protocol frame format as the EtherCAT channel.

[0115] Multi-protocol unified switching mechanism:

[0116] During runtime, the system identifies the coupler protocol type of the current connection through the CommunicateType enumeration (Serial=0, Ethernet=1, EtherCAT=2), and selects the corresponding transmission channel based on the protocol type in the SwitchCommunicateType() method:

[0117] Input: A unified private protocol frame + protocol type identifier; where Serial(0) corresponds to sending to the CC-Link coupler via USB virtual serial port; Ethernet(1) corresponds to sending to the PROFINET / Ethernet / IP coupler via standard UDP Socket; EtherCAT(2) corresponds to sending to the EtherCAT coupler via EoE-UDP mailbox.

[0118] The device discovery mechanisms and transmission channels of the four protocols differ, but the format of the private protocol frames transmitted is completely consistent. PROFINET and Ethernet / IP use existing standard UDP Socket technology as the transmission channel, while CC-Link uses USB CDC virtual serial port technology as the transmission channel; all are mature existing technologies. The host computer communication method supporting multi-protocol couplers provided in this application embodiment unifies these different channels under the same set of private protocol frames and creatively utilizes EoE mailboxes to carry private protocol frames in the EtherCAT network.

[0119] By completing the EoE-related preparations during the initialization phase, subsequent transmission of private protocol frames does not require independent network negotiation, thereby reducing communication overhead, improving the determinism of message transmission, and making it possible to incorporate the EtherCAT coupler into a unified configuration process.

[0120] In some embodiments, the method further includes constructing a forward mapping table from station number to network parameter information and a reverse mapping table from IP address to slave station number. The network parameter information includes at least IP address, MAC address, subnet mask, gateway, and port number. During the sending phase, the slave station number is determined from the target IP address based on the reverse mapping table. During the encapsulation phase, the destination MAC address is obtained from the slave station number based on the forward mapping table. The forward and reverse mapping tables are updated synchronously when the slave station's network parameters change. The unique MAC address is obtained by combining a fixed prefix 8C:F3:E7 and a 3-byte random number.

[0121] A forward mapping table from station number to network parameter information and a reverse mapping table from IP address to station number were introduced, and MAC address generation rules were defined. The target address location problem in the EoE environment was transformed into a mapping table lookup problem. This involves not only using the mapping table but also maintaining both forward and reverse indexes, enabling the host computer to quickly locate the station number from the target IP address and quickly retrieve the network parameter objects required for encapsulation from the station number. With bidirectional mapping, both the sending path and the encapsulation path can complete the location of key parameters in constant time, avoiding performance fluctuations caused by traversal lookups and providing a foundation for rapid synchronous updates after network parameter changes.

[0122] In some embodiments, when the protocol type is EtherCAT, the private protocol frame is encapsulated and sent according to the protocol type, referring to... Figure 7 ,include:

[0123] The private protocol frame is used as the UDP payload with a UDP header. The source port of the UDP header is 34981, the destination port is 50001, and the UDP length is 8+L, where L is the length of the private protocol frame. The UDP checksum is calculated based on the pseudo header containing the source IP address, destination IP address, protocol number, and UDP length.

[0124] An IP header is added to the outside of the UDP packet. The total length of the IP header is 20+8+L, where the Time to Live (TTL) field is 64 and the protocol field is 0x11. Checksums and calculations are performed on the IP header.

[0125] Add an Ethernet header to the outside of the IP packet, with the EtherType field in the Ethernet header set to 0x0800.

[0126] The EoE send interface of the EtherCAT master station is called to send the encapsulated Ethernet frame to the target coupler.

[0127] The process of sending proprietary protocol frames in an EtherCAT scenario is concretized into four consecutive steps: UDP header construction, IP header construction, Ethernet header construction, and invoking the EoE send interface. By embedding manufacturer-specific service frames into standard UDP, IP, and Ethernet layers and then sending them through EtherCAT's EoE mailbox, EtherCAT networks, which would otherwise struggle to directly carry proprietary semantics, gain a reusable channel. This enables the reorganization of the link, rather than simply filling in isolated protocol fields.

[0128] Through this encapsulation method, private protocol frames can maintain the integrity of their own business semantics and obtain a unified verification and routing foundation by leveraging mature UDP and IP encapsulation rules, thereby improving the efficiency of configuration and management communication in the EtherCAT environment.

[0129] In some embodiments, the response data returned by the target coupler is received, and the response private protocol frame is extracted and verified, referring to... Figure 2 ,include:

[0130] Step S1061: Obtain the raw data packet through the EoE mailbox receiving interface.

[0131] Step S1062: Verify that the destination MAC address matches the local MAC address and that the EtherType field is 0x0800.

[0132] Step S1063: Parse the IP header length. The IP header length is the result of a bitwise AND operation between the first byte and 0x0F multiplied by 4, and verify that the protocol field is 0x11.

[0133] Step S1064: Extract the source port, destination port, and UDP length from the UDP header.

[0134] Step S1065: Extract the private protocol frame based on the UDP data start position and UDP length, verify that the frame header is 0xAA55, and compare the calculated CRC16 check value with the frame tail check code.

[0135] Step S1066: After the verification is passed, parse the function code, device address, parameter area, data area and version number, and perform a consistency check between the lower 7 bits of the response frame function code and the corresponding request frame function code, wherein the response frame function code is the result of a bitwise OR operation between the request frame function code and 0x80.

[0136] The function code of the response frame is checked for consistency with the corresponding function code of the request frame, according to the following rules:

[0137] (1) Function code correspondence: The function code of the response frame should be equal to the result of bitwise OR operation between the function code of the corresponding request frame and 0x80. That is: Response function code = Request function code | 0x80 (the highest bit is set to 1 to indicate the response frame).

[0138] (2) Matching verification method: After receiving the response frame, perform a bitwise AND operation between the response frame function code and 0x7F, extract the lower 7 bits, and then compare them with the request frame function code recorded when sending. If the two are equal, the verification is successful.

[0139] (3) Handling of verification failure: If the function code does not match, it is considered an invalid response, and we continue to wait for the correct response within the timeout period.

[0140] The document specifies a layer-by-layer extraction and verification process for EoE return data, including Ethernet layer verification, IP layer parsing, UDP layer extraction, and private protocol frame verification and field parsing. Essentially, this corresponds to the reverse recovery process of the sending link. Instead of directly treating the return data as an application layer result, it establishes a response verification path completely corresponding to the sending end through reverse layered parsing, incorporating function code matching, version number parsing, and CRC16 comparison into a unified process. Because verification nodes are set up at each layer, erroneous, non-target, and format-abnormal packets can be eliminated before the packet enters the service layer. This improves the reliability of the host computer's execution result judgment and reduces configuration risks caused by misparsing.

[0141] In some embodiments, a parameter hot configuration process is also included, which includes:

[0142] The host computer constructs a private protocol frame containing hot configuration parameters written to function code 0x12 and sends it to the coupler.

[0143] After the coupler parses the private protocol frame, it forwards the configuration request to the target remote input / output module.

[0144] The target remote input / output module writes the new parameters into the standby configuration buffer and switches the buffers by swapping the pointers of the running configuration buffer and the standby configuration buffer, so that the new parameters take effect.

[0145] The target remote input / output module returns the execution result and the current configuration version number.

[0146] A hot configuration process for parameters is introduced, with the following technical logic: the host computer constructs a hot configuration write frame, the coupler forwards it to the target remote input / output module, the input / output module writes the new parameters to the standby configuration buffer, and the new parameters take effect by exchanging pointers between the running configuration buffer and the standby configuration buffer. This expands online configuration from simple data writing to a complete mechanism of buffered writing, pointer switching, and immediate effect. This mechanism solves the problem of how to safely switch parameters to the running state without system downtime. Through double buffering, the module can continue to use the original running configuration while receiving new parameters, thus avoiding interference with real-time services during configuration; switching pointers after the new parameters are written makes the parameter activation process more stable and reduces anomalies caused by intermediate state configuration.

[0147] In some embodiments, updating the execution results and version information in the configuration management database includes: updating the execution results and version information in the configuration management database after a successful configuration change, incrementing the version number and recording historical versions; upon receiving a configuration rollback instruction and the corresponding historical version number, reading the configuration parameter snapshot corresponding to the historical version number from the configuration management database, constructing each parameter in the configuration parameter snapshot into a private protocol frame, and redistributing it to the target coupler and the target remote input / output module through the corresponding transmission channel; the target remote input / output module then uses a double-buffered switching mechanism to make the historical version configuration effective and updates the current version number in the configuration management database.

[0148] The specific recovery method for configuration rollback involves reading a snapshot of the parameters from the historical version from the configuration management database, and then re-issuing all configuration parameters corresponding to that version to the coupler. The specific process is as follows:

[0149] Rollback process:

[0150] (1) Receive rollback command: The host computer receives the configuration rollback request initiated by the user, which includes the target historical version number;

[0151] (2) Query historical snapshots: Find the complete configuration parameter snapshot corresponding to the target version number from the configuration management database (local backup file);

[0152] (3) Construct configuration frame: Construct private protocol frame for each of the configuration parameters of the historical version (function code is 0x02 normal parameter write or 0x12 hot configuration parameter write).

[0153] (4) Send to Coupler: Send the configuration frame to the target coupler through the corresponding transmission channel (EoE-UDP / Standard UDP / USB), and the target coupler forwards it to the target remote input / output module;

[0154] (5) Module execution recovery: After receiving the parameters, the target remote input / output module writes them into the spare configuration buffer and performs buffer switching (double buffering mechanism) to make the parameters of the previous version effective;

[0155] (6) Update the database: After the host computer confirms that the rollback is successful, update the current version number of the configuration management database.

[0156] Storage mechanism:

[0157] The configuration management database is stored locally on the host computer as an XML file. After each successful configuration change, the system automatically saves the current complete configuration as a snapshot file. During rollback, the corresponding version of the snapshot file is read from the backup directory and restored to the active configuration path.

[0158] By introducing version incrementing, historical version records, and a configuration recovery mechanism based on historical version numbers into the configuration management database, the hot configuration process not only focuses on immediate effectiveness but also on version traceability and recoverability. Combining online hot configuration with version management ensures that each configuration change has identifiable, queryable, and rollback-capable version semantics. In this way, hot configuration is no longer a one-off action but is incorporated into a continuously manageable parameter lifecycle system. Through version incrementing and historical records, the host computer can audit and track configuration changes; in the event of misconfiguration or mismatch with on-site operating conditions, existing parameters can be restored based on historical versions, thereby reducing the operational risks associated with online changes.

[0159] Another embodiment of the present invention also provides a host computer communication device supporting a multi-protocol coupler, comprising:

[0160] The acquisition module is used to determine the protocol type of the target coupler as one of EtherCAT, PROFINET, Ethernet / IP and CC-Link protocols based on the device discovery results of the target coupler, and select the corresponding protocol driver and transmission channel.

[0161] Create a module to build a private protocol frame in a unified format. The private protocol frame includes at least a frame header, function code, device address, parameter area, data area, version number, and CRC16 checksum.

[0162] The transmitting module is used to encapsulate private protocol frames according to the protocol type and send them to the target coupler. Specifically, when the protocol type is EtherCAT, the private protocol frame is encapsulated in UDP, IP and Ethernet in sequence and then sent through an EoE mailbox. When the protocol type is PROFINET or Ethernet / IP, the private protocol frame is encapsulated into a standard UDP data packet and then sent. When the protocol type is CC-Link, the private protocol frame is encapsulated into a USB data packet and then sent.

[0163] The receiving module is used to receive the response data returned by the target coupler, extract and verify the private protocol frame of the response, parse the execution result, and update the execution result and version information in the configuration management database when the execution is successful.

[0164] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0165] Based on the same inventive concept as the above method embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it enables the electronic device to implement the control method described in the above embodiments.

[0166] In one embodiment, the electronic device may be a server, and in this embodiment, the structure of the electronic device may be as follows: Figure 8 As shown, it includes a memory, a communication module, and one or more processors.

[0167] Memory is used to store computer programs executed by the processor. Memory can be mainly divided into a program storage area and a data storage area. The program storage area can store the operating system and programs required to run instant messaging functions, etc.; the data storage area can store various instant messaging information and operation instruction sets, etc.

[0168] Memory can be volatile memory, such as random access memory (RAM); memory can also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory can be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory can be a combination of the above-mentioned types of memory.

[0169] A processor may include one or more central processing units (CPUs) or digital processing units, etc. The processor is used to implement the aforementioned audio data processing methods when it invokes computer programs stored in memory.

[0170] The communication module is used to communicate with terminal devices and other servers.

[0171] This application embodiment does not limit the specific connection medium between the above-described memory, communication module, and processor. This application embodiment... Figure 8 The memory and processor are connected via a bus, and the bus is in... Figure 8 The connections between other components are illustrated with arrows and are for illustrative purposes only, not as limiting information. Buses can be categorized as address buses, data buses, control buses, etc. For ease of description, Figure 8 The text uses only one arrow to describe it, but does not indicate that there is only one bus or one type of bus.

[0172] Based on the same inventive concept as the above-described method embodiments, embodiments of the present invention also provide a computer-readable storage medium for storing a computer program. When the computer program is run on a computer, it enables an electronic device to implement the control methods described in the above embodiments. The computer-readable storage medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0173] Based on the same inventive concept as the above-described method embodiments, embodiments of the present invention also provide a computer program product. The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of the control methods described above according to various exemplary embodiments of this application. The program product may take the form of any combination of one or more readable media. These computer program commands can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the commands executed by the processor of the computer or other programmable data processing device generate a process for implementing... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0174] While the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Those skilled in the art can make various modifications and refinements without departing from the spirit and scope of the invention. Therefore, the scope of protection of the present invention shall be determined by the claims.

Claims

1. A host computer communication method supporting multi-protocol couplers, characterized in that, include: Based on the device discovery results of the target coupler, the protocol type of the target coupler is determined to be one of EtherCAT, PROFINET, Ethernet / IP, and CC-Link protocols, and the corresponding protocol driver and transmission channel are selected. Construct a private protocol frame with a unified format, wherein the private protocol frame includes at least a frame header, function code, device address, parameter area, data area, version number and CRC16 checksum; The private protocol frame is encapsulated according to the protocol type and sent to the target coupler. Specifically, when the protocol type is EtherCAT, the private protocol frame is sequentially encapsulated with UDP, IP, and Ethernet before being sent via an EoE mailbox. When the protocol type is PROFINET or Ethernet / IP, the private protocol frame is encapsulated into a standard UDP data packet before being sent. When the protocol type is CC-Link, the private protocol frame is encapsulated into a USB data packet before being sent. This includes adding a UDP header to the private protocol frame as a UDP payload, where the source port of the UDP header is 34981 and the destination port is 500.

01. The UDP length is 8+L, where L is the length of the private protocol frame. The UDP checksum is calculated based on a pseudo header containing the source IP address, destination IP address, protocol number, and UDP length. An IP header is added to the outside of the UDP packet, with a total IP length of 20+8+L. The Time-to-Live (TTL) field is 64, and the protocol field is 0x11. A checksum is calculated for the IP header. The IP header is encapsulated into an IP packet. An Ethernet header is added to the outside of the IP packet, with the EtherType field in the Ethernet header being 0x0800. The EoE sending interface of the EtherCAT master station is called to send the encapsulated Ethernet frame to the target coupler. The system receives response data returned by the target coupler, extracts and verifies the private protocol frame of the response, and parses the execution result, which includes hot parameter configuration. The hot parameter configuration process includes: the host computer constructs a private protocol frame containing the hot configuration parameter writing function code 0x12 and sends it to the coupler; after parsing the private protocol frame, the coupler forwards the configuration request to the target remote input / output module; the target remote input / output module writes the new parameters into the standby configuration buffer and completes the buffer switching by exchanging pointers between the running configuration buffer and the standby configuration buffer, so that the new parameters take effect; the target remote input / output module returns the execution result and the current configuration version number; and updates the execution result and version information in the configuration management database when the execution is successful.

2. The host computer communication method supporting multi-protocol couplers according to claim 1, characterized in that, The step of determining the protocol type of the target coupler based on the device discovery result of the target coupler as one of EtherCAT, PROFINET, Ethernet / IP, and CC-Link protocols, and selecting the corresponding protocol driver and transmission channel, includes: The EtherCAT protocol type is determined by scanning EtherCAT slave stations and obtaining EoE network parameters. The PROFINET protocol type is determined by the DCP protocol discovery results; The Ethernet / IP protocol type can be determined by the results of UDP broadcast discovery. The USB CDC driver establishes a USB connection with the CC-Link coupler to determine the CC-Link protocol type; Invoke the protocol driver corresponding to the protocol type to execute the private protocol frame sending and response receiving.

3. The host computer communication method supporting multi-protocol couplers according to claim 1, characterized in that, The frame header is a 2-byte fixed synchronization identifier 0xAA55; the device address is a 2-byte logical address, where the high byte represents the module number and the low byte represents the channel number; the parameter area includes at least a 4-byte parameter identifier and a 2-byte parameter length; the version number is an 8-byte configuration version number; the CRC16 checksum is generated using the CRC-16 / Modbus algorithm; the total length of the private protocol frame is 15+M+N bytes, where M is the parameter area length and N is the data area length.

4. The host computer communication method supporting multi-protocol couplers according to claim 1, characterized in that, The function code includes at least the following: 0x01 indicates reading ordinary parameters, 0x02 indicates writing ordinary parameters, 0x11 indicates reading hot configuration parameters, 0x12 indicates writing hot configuration parameters, 0x20 indicates querying topology information, 0x30 indicates transmitting firmware upgrade data, and 0x40 indicates collecting diagnostic data; when the highest bit of the function code is 1, it indicates a response frame.

5. A host computer communication method supporting multi-protocol couplers according to claim 2, characterized in that, When the protocol type is EtherCAT, the step of determining the protocol type of the target coupler and selecting the corresponding protocol driver and transmission channel based on the device discovery result of the target coupler includes: Open and bind the specified network adapter; Send broadcast frames to scan the EtherCAT network, identify slave devices and read the manufacturer's identifier, product code and version number, and assign logical addresses to each slave in an incrementing manner starting from 1, according to the physical connection order of the slaves in the network topology. For slave stations that support EoE functionality, the GetIP command is used to read the current network parameters of the slave station. If the read MAC address or IP address is invalid, a unique MAC address and an IP address in the same network segment as the host computer are generated and sent to the corresponding slave station via the SetIP command. The slave station is switched from the Init state to the Pre-Operational state to establish an EoE communication channel.

6. A host computer communication method supporting multi-protocol couplers according to claim 5, characterized in that, It also includes constructing a forward mapping table from station number to network parameter information and a reverse mapping table from IP address to slave station number. The network parameter information includes at least IP address, MAC address, subnet mask, gateway, and port number. During the sending phase, the slave station number is determined from the target IP address based on the reverse mapping table. During the encapsulation phase, the destination MAC address is obtained from the slave station number based on the forward mapping table. The forward mapping table and the reverse mapping table are updated synchronously when the slave station network parameters change. The unique MAC address is obtained by combining a fixed prefix 8C:F3:E7 and a 3-byte random number.

7. A host computer communication method supporting multi-protocol couplers according to claim 6, characterized in that, The process of receiving response data returned by the target coupler, extracting and verifying the response private protocol frame, includes: Obtain the raw data packet via the EoE email receiving interface; Verify that the destination MAC address matches the local machine's MAC address and that the EtherType field is 0x0800; Parse the IP header length, which is the result of a bitwise AND operation between the first byte and 0x0F multiplied by 4, and verify that the protocol field is 0x11; Extract the source port, destination port, and UDP length from the UDP header; Extract the private protocol frame based on the UDP data start position and UDP length, verify that the frame header is 0xAA55, and compare the calculated CRC16 check value with the frame tail check code; After the verification is successful, the function code, device address, parameter area, data area and version number are parsed, and the lower 7 bits of the response frame function code are checked for consistency with the corresponding request frame function code. The response frame function code is the result of a bitwise OR operation between the request frame function code and 0x80.

8. A host computer communication method supporting multi-protocol couplers according to claim 1, characterized in that, The process of updating the execution results and version information in the configuration management database includes: updating the execution results and version information in the configuration management database after a successful configuration change, incrementing the version number and recording historical versions; upon receiving a configuration rollback command and the corresponding historical version number, reading the configuration parameter snapshot corresponding to the historical version number from the configuration management database, constructing each parameter in the configuration parameter snapshot into a private protocol frame, and redistributing it to the target coupler and the target remote input / output module through the corresponding transmission channel. The target remote input / output module then uses a double-buffering switching mechanism to make the historical version configuration effective and updates the current version number in the configuration management database.

Images