Custom protocol data transmission method and system based on EtherCAT

Abstract

The invention provides a user-defined protocol data transmission method and system based on EtherCAT (Ethernet Control Automation Technology). The method comprises the following steps: defining a receiving channel object and a sending channel object for custom protocol communication in an object dictionary of a slave station, and mapping the receiving channel object and the sending channel object into a receiving PDO and a sending PDO of at least one group of process data objects PDO; the master station or the slave station constructs and sends a protocol frame to an opposite end node in the receiving PDO, wherein the protocol frame comprises control information, sequence identification information and a load data area; when the receiving party periodically processes the PDO data, the protocol frame is identified according to the control information and the sequence identification information, and the data in the load data area is analyzed and processed; the receiver generates a response protocol frame in the sending PDO according to the analysis processing result and sends the response protocol frame to the sender; and the sender receives the response protocol frame and matches the response protocol frame with the corresponding protocol frame so as to complete PDO-based custom protocol communication.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology, and in particular to a custom protocol data transmission method and system based on EtherCAT. Background Technology

[0002] In industrial automation control systems, EtherCAT (Ethernet for Control Automation Technology) is widely used for master-slave communication. In an EtherCAT system, the master and slave stations achieve real-time control by periodically exchanging Process Data Objects (PDOs). PDO channels are suitable for carrying data items with fixed semantics and structures, typically mapped from entries in the slave station's object dictionary. Through this mechanism, the master station can periodically read and write the slave station's status variables, control variables, and preset parameters, achieving fast, reliable data communication and closed-loop control.

[0003] However, when slave stations need to carry multiple types of custom data, such as batch parameter access, diagnostic logs, debugging commands, extended status information, or vendor-specific services, existing solutions typically involve adding multiple RxPDO / TxPDO sets or transmitting data via a CoE (CANopen over EtherCAT) mailbox channel. The former leads to a rapid increase in the number of PDOs, thereby increasing the configuration complexity of the object dictionary and slave information file (ESI) and reducing system scalability; the latter, while enabling flexible data access, suffers from additional protocol overhead and unpredictable processing latency, making its real-time performance and stability less reliable than during periodic PDO anomaly communication. As application scenarios increasingly demand high-frequency periodic control, existing solutions face numerous limitations in ensuring real-time performance and scalability. Summary of the Invention

[0004] The purpose of this invention is to provide a custom protocol data transmission method and system based on EtherCAT, so as to realize reliable, verifiable and scalable transmission of multiple types of custom data in master-slave communication, while reducing the complexity of slave object dictionary and engineering configuration, and improving periodic real-time performance and system scalability.

[0005] In a first aspect, the present invention provides a custom protocol data transmission method based on EtherCAT, applicable to a system containing an EtherCAT master station and an EtherCAT slave station, comprising the following steps: Define receive channel objects and send channel objects for custom protocol communication in the object dictionary of the slave station, and map the receive channel objects and send channel objects to at least one set of process data objects PDOs for receiving PDOs and sending PDOs; The master station or slave station constructs and sends a protocol frame to the peer node in the received PDO. The protocol frame includes control information for indicating the frame status, sequence identification information for identifying the communication order, and a payload data area for carrying custom data. When the receiving party processes PDO data periodically, it identifies the protocol frame based on the control information and the sequence identifier information, and performs parsing processing on the data in the payload data area. The receiver generates a response protocol frame in the transmit PDO based on the parsing and processing results and sends it to the sender; The sender receives the response protocol frame and matches it with the corresponding protocol frame to complete the custom protocol communication based on the PDO.

[0006] Optionally, the specific steps for the receiving party to identify the protocol frame based on the control information and the sequence identifier information, and to parse the data in the payload data area when periodically processing PDO data, include: The receiver compares the sequence identification information in the currently received protocol frame with the sequence identification information of the processed protocol frames; When the sequence identification information is inconsistent with the processed record, the protocol frame is determined to be a new protocol frame and the data in its payload data area is parsed and processed. When the sequence identifier information matches the processed record, the protocol frame is determined to be a duplicate protocol frame and the parsing process is ignored or the corresponding response protocol frame is returned directly.

[0007] Optionally, the control information includes at least one of the following: Frame validity identification information used to indicate that the current protocol frame is a valid data frame; Confirmation request identification information used to instruct the sender to request the receiver to return the processing result; This is an acknowledgment information used to indicate to the receiver that the protocol frame processing is complete and a result has been returned; Error indication information used to indicate abnormal situations that occur during protocol frame processing.

[0008] Optionally, the control information further includes first frame identification information and last frame identification information for indicating the data fragmentation status. When the receiving party periodically processes PDO data, identifying the protocol frame based on the control information and the sequence identification information, and parsing the data in the payload data area, further includes the following steps: When the control information of the protocol frame contains both the first frame identifier information and the last frame identifier information, the data in the payload data area is parsed as complete data. When the control information of the protocol frame contains first frame identification information but not last frame identification information, the data in the payload data area is cached as the starting part of the fragmented data. When the control information of the protocol frame contains the last frame identifier information, the payload data area of ​​the current protocol frame is concatenated with the previously cached fragmented data to form complete data before parsing.

[0009] Optionally, the specific steps of concatenating the payload data area of ​​the current protocol frame with the previously cached fragmented data to form complete data before parsing include: When a protocol frame containing first frame identification information is received, the starting sequence number of the current data reassembly process is established according to the sequence identifier of the protocol frame containing first frame identification information. When receiving subsequent protocol frames, their sequence identifiers are compared with those of the previous protocol frame to determine whether the received protocol frames arrive in the predetermined order. When a discontinuous sequence identifier is detected, the current data reassembly process is terminated and the cached fragment data is cleared. When a protocol frame containing last frame identifier information and consecutive sequence identifiers is received, the cached fragmented data is concatenated with the payload data in the protocol frame containing last frame identifier information and consecutive sequence identifiers to form complete data and then parsing it.

[0010] Optionally, the length of the payload data area of ​​the protocol frame is determined based on the available buffer space or the available data length of the PDO (Packet Attached Data), and the specific steps include: When the sender generates a protocol frame, it segments the data to be sent according to the preset maximum payload length. The segmented data is sequentially filled into the payload data area of ​​multiple protocol frames for transmission, ensuring that the payload data length in each protocol frame does not exceed the maximum payload length, so as to guarantee that the receiver can properly parse and process the received protocol frames.

[0011] Optionally, the protocol frame may further include service identification information for identifying the data service type, and the custom protocol data transmission method may further include: When generating a protocol frame, the sender writes the corresponding service identification information into the protocol frame according to the service type to which the data to be sent belongs; After receiving the protocol frame, the receiver classifies the data in the payload data area according to the service identification information, and calls the processing logic corresponding to the service type for parsing or execution, so that the same PDO communication channel can carry the data transmission of multiple different service types.

[0012] Optionally, the specific steps for the receiver to generate a response protocol frame in the transmitted PDO based on the parsing processing result and send it to the sender include: When parsing protocol frames, the receiver identifies abnormal situations such as data verification errors, discontinuous sequences, or mismatched service identifiers. Write the corresponding error flag information and error code into the control information field of the response protocol frame and send it to the sender via PDO; Adjust the receiving or buffering strategy based on the error state, and implement delayed reception or buffering control for subsequent protocol frames to avoid buffer overflow or data corruption.

[0013] Optionally, the custom protocol data transmission method further includes: When generating a protocol frame, the sender writes the corresponding protocol version identifier information into the protocol frame; When receiving a protocol frame, the receiver identifies the protocol version based on the protocol version identifier information and selects the corresponding parsing logic or processing strategy based on the version information to ensure compatible processing of different version protocol frames. When an incompatible or unrecognizable protocol version is detected, the receiver sends a version error flag or prompt message to the sender via a response protocol frame, thereby supporting data communication and compatibility extension of different protocol versions within a single PDO channel.

[0014] Secondly, the present invention provides a custom protocol data transmission system employing the aforementioned custom protocol data transmission method based on EtherCAT, the system comprising: The slave object dictionary module is configured to define receive channel objects and send channel objects for custom protocol communication, and to map the receive channel objects and send channel objects to at least one set of process data objects (PDOs) for receiving and sending PDOs. The protocol frame encoding module is used to encapsulate the custom data to be sent according to the preset protocol frame format when any communication node is the sender, and generate a protocol frame containing control information, sequence identification information and payload data area. The protocol frame decoding module is used to parse the protocol frames received through PDO when any communication node acts as the receiver, identify the protocol frames according to the control information and the sequence identifier information, and parse and process the data in the payload data area. The EtherCAT interface module is communicatively connected to both the master station and the slave station. It is used to send the protocol frames generated by the protocol frame encoding module to the bus via PDO, and to provide the PDO data received from the bus to the protocol frame decoding module, so as to realize bidirectional custom protocol data communication between the sender and receiver based on the PDO.

[0015] According to the present invention, bidirectional custom data communication based on a minimal number of Process Data Objects (PDOs) can be achieved between EtherCAT master and slave stations. This scheme defines receive and transmit protocol channel objects in the slave object dictionary and maps them to PDOs. It utilizes control information and sequence identifiers in the protocol frames to achieve communication acknowledgment and matching, enabling the master and slave stations to reliably exchange custom data. This significantly reduces the complexity of the slave object dictionary and project configuration, while maintaining the real-time and deterministic nature of periodic PDOs, thus improving the system's communication efficiency and scalability.

[0016] Furthermore, by employing mechanisms such as fragmentation identifiers, sequence detection, service identifiers, and protocol version identifiers within the control information, data fragmentation and reassembly, anomaly handling, service classification, and multi-version protocol compatibility can be supported, thereby achieving flexible and reliable processing of large-capacity data, different service types, and multiple protocol versions. This scheme enables the same PDO channel to carry multiple types of service data, improving the utilization and scalability of the communication channel, while enhancing the system's adaptability and reliability in various custom data scenarios such as parameter access, diagnosis, debugging, and extended states.

[0017] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, the preferred embodiments of the present invention are described in detail below. Attached Figure Description

[0018] Figure 1 A schematic flowchart of a custom protocol data transmission method based on EtherCAT according to an embodiment of the present invention is shown; Figure 2 It shows Figure 1 A schematic flowchart illustrating how the party receiving the protocol frame in step S300 identifies the protocol frame based on control information and sequence identifier information and parses the data in the payload data area when periodically processing PDO data. Figure 3The diagram shows a schematic flowchart of step S360, which involves concatenating the payload data area of ​​the current protocol frame with the previously cached fragmented data to form complete data and then performing parsing processing. Figure 4 A schematic flowchart is shown in which the receiver generates a response protocol frame in the PDO based on the parsing processing result and sends it to the sender in step S400. Figure 5 A structural block diagram of a custom protocol data transmission system based on EtherCAT according to an embodiment of the present invention is shown. Detailed Implementation

[0019] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, it should be noted that, for ease of description, only the parts relevant to this application are shown in the accompanying drawings, not the entire structure. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application.

[0020] The terms “comprising” and “having”, and any variations thereof, used in this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] Figure 1 A schematic flowchart illustrating a custom protocol data transmission method based on EtherCAT according to an embodiment of the present invention is shown. Figure 1 As shown, the custom protocol data transmission method includes: Step S100: Define receive channel objects and send channel objects for custom protocol communication in the object dictionary of the slave station, and map the receive channel objects and send channel objects to at least one set of process data objects PDOs for receiving PDOs and sending PDOs.

[0023] In this step, by uniformly defining the communication channel at the object dictionary level, custom protocol communication can have clear data entry and exit points during the system configuration phase, and directly participate in the EtherCAT periodic communication process through the PDO mapping mechanism. A stable data transmission channel can be established using a small number of PDOs, eliminating the need to add multiple PDO entries for different data types. This reduces the number of object dictionary configurations while maintaining PDO real-time performance, lowering project configuration complexity, and improving the system's flexibility for subsequent functional expansion.

[0024] In step S200, the master station or slave station constructs and sends a protocol frame to the peer node in the received PDO. The protocol frame includes control information for indicating the frame status, sequence identification information for identifying the communication order, and a payload data area for carrying custom data.

[0025] In this step, by constructing a protocol frame with a unified format in the PDO, structured custom data can be carried within fixed-length process data, enabling unified management of different communication states and data content. Specifically, control information describes the communication state or processing requirements of the current data frame, sequence identifier information distinguishes the order of data frames in different communication cycles, and the payload data area carries the actual service data. Thus, while maintaining the PDO cycle transmission mechanism, a protocol data carrier with basic communication control capabilities is provided between the master and slave stations.

[0026] In step S300, when the receiving party is periodically processing PDO data, it identifies the protocol frame based on the control information and sequence identifier information, and performs parsing processing on the data in the payload data area.

[0027] In this step, by identifying protocol frames during the PDO periodic update process, the processing of custom data can be synchronized with the real-time communication cycle of EtherCAT, thereby ensuring the timeliness and consistency of data processing. The joint identification of control information and sequence identifier information enables the receiver to accurately determine the status and order of the current data frame, avoiding redundant processing of invalid or duplicate data, and executing corresponding data parsing or business processing logic according to the payload content in the protocol frame, thus achieving a stable and reliable data interaction process.

[0028] In step S400, the receiver generates a response protocol frame in the sending PDO based on the parsing processing result and sends it to the sender.

[0029] In this step, by constructing a response protocol frame in the PDO (Process Request) transmission, the receiver can feed back the processing result or execution status of the data requested by the sender to the sender, thus forming a complete data interaction loop between the master and slave stations. The response protocol frame can also contain control information and necessary return data, enabling the sender to clearly identify the processing result or execution status, thereby improving the confirmability and traceability of the communication process and providing a basis for subsequent data interaction or control decisions.

[0030] In step S500, the sender receives the response protocol frame and matches the response protocol frame with the corresponding protocol frame to complete the custom protocol communication based on PDO.

[0031] In this step, by matching the response protocol frame with the original sending protocol frame, the sender can confirm whether the current communication request has been processed correctly and obtain the data or status information returned by the receiver. This matching process enables the sender to effectively manage the communication results while avoiding confusion between different communication requests. This allows for custom protocol data interaction with request-response relationships within the PDO periodic communication environment, improving the reliability and manageability of the overall communication process.

[0032] According to the above embodiments, by defining receive and transmit protocol channel objects in the slave object dictionary and mapping them to PDOs, and utilizing control information and sequence identifiers in the protocol frames to achieve communication acknowledgment and matching, the master and slave stations can reliably exchange custom data. This significantly reduces the complexity of the slave object dictionary and engineering configuration, while maintaining the real-time and deterministic nature of periodic PDOs, thus improving the system's communication efficiency and scalability.

[0033] Figure 2 It shows Figure 1 The flowchart illustrating how the party receiving the protocol frame in step S300 identifies the protocol frame based on control information and sequence identifier information and parses the data in the payload data area during periodic processing of PDO data is shown. Figure 2 As shown, step S300 specifically includes: In step S310, the receiver compares the sequence identifier information in the currently received protocol frame with the sequence identifier information of the processed protocol frames.

[0034] In this step, after receiving the protocol frame sent by the sender via the receive PDO, the receiver first extracts the sequence identifier information from the protocol frame and compares it with the sequence identifier information of the most recently processed protocol frame recorded internally by the receiver. This comparison can be performed within the receiver's periodic tasks or protocol processing module. By maintaining a state variable to record the sequence numbers of processed frames, the receiver can continuously track the order of data frames in the current communication session. Through this step, the receiver can determine the position of the currently received data frame in the communication sequence, thus providing a basis for subsequent data processing. This helps avoid frame identification confusion caused by periodic communication jitter or repeated transmissions, improving the orderliness and stability of the communication process.

[0035] Step S320: When the sequence identifier information is inconsistent with the processed record, the protocol frame is determined to be a new protocol frame and the data in its payload data area is parsed and processed.

[0036] In this step, when the comparison result shows that the sequence identifier information in the current protocol frame is inconsistent with the processed record, the receiver identifies the protocol frame as a new protocol frame and further parses and processes the payload data area of ​​the protocol frame. Specifically, based on the control information and service content in the protocol frame, the receiver extracts the data in the payload data area and passes it to the corresponding processing logic for parsing or execution, such as parameter access processing, status query, or other custom data processing operations. By identifying protocol frames with different sequence identifiers as new data frames, it can be ensured that each new communication request can be correctly identified and processed, thereby avoiding the omission of valid data and ensuring that the communication requests initiated by the sender can be responded to in a timely manner.

[0037] Step S330: When the sequence identifier information is consistent with the processed record, the protocol frame is determined to be a duplicate protocol frame and the parsing process is ignored or the corresponding response protocol frame is returned directly.

[0038] In this step, when the comparison result shows that the sequence identifier information in the current protocol frame matches the processed record, the receiver identifies the protocol frame as a duplicate protocol frame. At this point, the receiver can choose to ignore the payload data of this protocol frame and not repeat the same data parsing process; or, if maintaining communication consistency is required, it can directly return the previously generated response protocol frame. This processing method effectively avoids duplicate execution problems caused by communication link jitter, sender retransmission, or periodic synchronization differences, preventing the same service operation from being triggered multiple times, thereby improving the stability of the system processing logic and reducing unnecessary computation and resource consumption.

[0039] In one embodiment, the control information used to indicate the frame status includes at least one of the following: frame validity identifier information for indicating that the current protocol frame is a valid data frame; acknowledgment request identifier information for indicating that the sender requests the receiver to return the processing result; acknowledgment identifier information for indicating that the receiver has completed processing the protocol frame and returned the result; and error indication information for indicating that an abnormal situation has occurred during the processing of the protocol frame.

[0040] In this embodiment, the control information in the protocol frame describes the status or processing requirements of the current data frame during communication, enabling the master and slave stations to identify and process the data frame based on unified flag information. Specifically, when the sender constructs the protocol frame, it can set corresponding status flags in the control information according to the current communication requirements. For example, when sending valid data, a frame validity flag is set to indicate that the data carried in the payload data area of ​​the current protocol frame is valid content that needs to be processed. When the sender wants the receiver to return the execution result or status information after processing, it can set an acknowledgment request flag to trigger the receiver to generate corresponding response data. At the same time, after the receiver completes the parsing and processing of the protocol frame data, it can set an acknowledgment flag in the returned response protocol frame to indicate that the data frame has been processed correctly. If data abnormalities, format errors, or other processing failures are detected during processing, the abnormal status can be marked through error indication information and returned to the sender by sending a PDO. In this way, the control information plays the role of status description and processing instructions during communication, enabling the protocol frame to have basic communication control capabilities in the fixed-structure PDO data.

[0041] By introducing multiple status flags into the protocol frames, the slave and master stations can clearly identify the processing status and interaction requirements of each data frame during periodic communication, thus forming a clear communication control mechanism. On the one hand, the sender can determine whether the request has been correctly executed based on the returned acknowledgment flag or error indication information, facilitating subsequent control or retransmission processing. On the other hand, the receiver can also adopt corresponding processing strategies for different types of data frames based on the frame validity flag and acknowledgment request flag, thereby avoiding invalid data from participating in processing and improving communication efficiency and processing reliability. Simultaneously, this method achieves data status management without adding extra communication channels, enabling the custom protocol to have more complete interactive capabilities in PDO periodic communication, which is beneficial to improving the overall stability and manageability of the system's communication.

[0042] In one embodiment, the control information of the protocol frame further includes first frame identification information and last frame identification information to indicate the data fragmentation status, thereby supporting the fragmented transmission and reassembly of long data or large batches of custom data. Step S300 above also includes the following steps: Step S340: When the control information of the protocol frame contains both the first frame identifier information and the last frame identifier information, the data in the payload data area is parsed as complete data.

[0043] In this step, when the received protocol frame contains both a first frame identifier and an last frame identifier, it indicates that the content carried in the payload data area of ​​that protocol frame is complete, and no fragmentation or splicing operation is required. At this time, the receiver can directly parse and process the data in the payload data area, including executing business logic, updating parameters, or processing diagnostic information, thereby efficiently completing single-frame data communication and business response. The advantage of this step is that it eliminates the need for additional fragmentation buffer management, reducing processing overhead, while ensuring that complete data is processed quickly and accurately, achieving efficient and deterministic communication.

[0044] Step S350: When the control information of the protocol frame contains the first frame identifier information but not the last frame identifier information, the data in the payload data area is cached as the starting part of the fragmented data.

[0045] In this step, when the received protocol frame contains a first frame identifier but not an last frame identifier, it indicates that the protocol frame is the starting frame of a multi-frame data sequence. The receiver buffers the contents of the payload data area as the starting part of the fragmented data and records the corresponding sequence identifier information to track the data reassembly order. This buffered data remains in the buffer until subsequent frames arrive, and is then parsed after the complete data collection is finished. The advantage of this step is that it enables continuous transmission management of large amounts of data or long messages without increasing the number of PDOs, while ensuring the correctness of the fragmentation order through sequence identifiers, thus providing a foundation for the reliable assembly of multi-frame data.

[0046] Step S360: When the control information of the protocol frame contains the last frame identifier information, the payload data area of ​​the current protocol frame is concatenated with the previously cached fragmented data to form complete data, and then parsing is performed.

[0047] In this step, when the received protocol frame contains an end-frame identifier, it indicates that the last part of the multi-frame transmission has arrived. The receiver concatenates the payload data area of ​​the current frame with the previously cached fragmented data to form a complete dataset, which is then parsed. This step not only ensures data integrity but also supports unified processing of cross-frame service information, such as batch parameter updates, integration of diagnostic logs, or continuous parsing of debugging data. The advantage of this step is that it achieves seamless reassembly of fragmented data, adapting to the transmission needs of large-capacity or complex custom data in high-frequency periodic communication environments, while keeping the number of PDO channels unchanged, significantly improving system scalability and processing reliability.

[0048] Figure 3The diagram illustrates a schematic flowchart of step S360, which involves concatenating the payload data area of ​​the current protocol frame with previously cached fragmented data to form complete data, followed by parsing. Figure 3 As shown, step S360 includes: Step S361: When a protocol frame containing first frame identification information is received, the starting sequence number of the current data reassembly process is established according to the sequence identifier of the protocol frame.

[0049] In this step, when the receiver receives a protocol frame containing the first frame identifier information, it establishes the starting sequence number for the current data reassembly process based on the sequence identifier in that protocol frame. This step not only marks the starting point of the current fragmented data sequence but also provides a reference benchmark for subsequent fragment order verification. Through this operation, the receiver can correctly identify the starting position of each message during multi-frame transmission, avoiding confusion between fragmented data of different messages, thereby ensuring the accuracy of subsequent splicing and parsing operations. The advantage of this step is that it can effectively manage the starting identifiers of fragmented data, ensuring an orderly and reliable data reassembly process, and improving the determinism and stability of overall communication.

[0050] Step S362: When receiving subsequent protocol frames, compare their sequence identifiers with the sequence identifiers of the previous protocol frame to determine whether the received protocol frames arrive in the predetermined order.

[0051] In this step, when receiving subsequent protocol frames, the receiver compares their sequence identifiers with those of the previous protocol frame to determine whether the received protocol frames arrived in the predetermined order. This operation monitors the integrity and order of fragmented transmission, ensuring that no parsing errors occur during data reassembly due to out-of-order delivery. By verifying the continuity of sequence identifiers, the receiver can promptly detect potential frame loss or out-of-order delivery, providing a basis for subsequent processing and thus maintaining the integrity and traceability of fragmented data.

[0052] Step S363: When a discontinuous sequence identifier is detected, terminate the current data reassembly process and clear the cached fragment data.

[0053] In this step, when a discontinuous sequence identifier is detected, the receiver will terminate the current data reassembly process and clear the cached fragment data. This operation is a protection mechanism against abnormal transmission situations, preventing erroneous or lost fragments from affecting the subsequent parsing of complete data, while also avoiding storage resource waste caused by cache accumulation. The advantage of this step is that by promptly cleaning up invalid data and aborting erroneous reassembly processes, it ensures that the system maintains stability and reliability even in high-frequency and complex communication environments.

[0054] Step S364: When a protocol frame containing last frame identifier information and consecutive sequence identifiers is received, the cached fragmented data is concatenated with the payload data in the protocol frame to form complete data and then parsed.

[0055] In this step, when a protocol frame containing last frame identifier information and with consecutive sequence identifiers is received, the receiver concatenates the buffered fragmented data with the payload data in that protocol frame to form complete data, which is then parsed. This step achieves the final reassembly of fragmented data, unifying the parsing of segmented information from multiple frames, and completing the business logic processing of custom protocol content, such as parameter updates, diagnostic log processing, or debug data parsing. Its advantage lies in ensuring data integrity while enabling a single PDO channel to efficiently carry large amounts of data, achieving highly real-time and reliable bidirectional custom protocol communication.

[0056] In one embodiment, the length of the payload data area of ​​the protocol frame is determined based on the available buffer space of the receiving device or the available data length of the PDO, and the specific steps include: When the sender generates a protocol frame, it segments the data to be sent according to the preset maximum payload length.

[0057] In this step, the sender divides the data to be sent into data blocks suitable for transmission in a single protocol frame, based on the receiver's available buffer space and the data length that each PDO can carry. This not only ensures that each frame of data does not exceed the receiver's processing capacity but also provides clear boundary information for fragment reassembly, thereby ensuring controllable data order and integrity during subsequent frame parsing. In this way, the system can flexibly adapt to different device resource conditions and achieve stable data transmission.

[0058] The segmented data is sequentially filled into the payload data area of ​​multiple protocol frames for transmission, ensuring that the payload data length in each protocol frame does not exceed the maximum payload length, so as to guarantee that the receiver can properly parse and process the received protocol frames.

[0059] In this step, the sender fills each segment into its corresponding protocol frame payload area according to the data sequence, and sets the corresponding control information and sequence identifier to ensure that the data of each frame can be uniquely identified and correctly reassembled during transmission. Before transmission, the system verifies the length of each frame and adjusts the data size of the last frame according to the actual buffer capacity to prevent overflow or data truncation. This step, by strictly controlling the single-frame payload length, avoids data parsing errors and buffer overflow risks, while ensuring reliability and real-time performance in high-frequency periodic communication scenarios.

[0060] In one embodiment, the protocol frame also includes service identification information for identifying the data service type, and the custom protocol data transmission method further includes: When generating a protocol frame, the sender writes the corresponding service identification information into the protocol frame according to the service type to which the data to be sent belongs.

[0061] In this step, the sender first identifies the specific service category of the data to be sent, such as parameter read / write, diagnostic logs, or debugging commands. Then, it fills the corresponding service identifier field into the control information or payload header of the protocol frame so that the receiver can quickly identify the data type upon reception. By explicitly labeling the service type, the system can transmit different types of data on the same PDO channel while maintaining the independence and traceability of each type of data, thereby reducing channel management complexity and improving the flexibility and scalability of data transmission.

[0062] After receiving the protocol frame, the receiver classifies the data in the payload data area according to the service identification information, and calls the processing logic corresponding to the service type for parsing or execution, so that the same PDO communication channel can carry the data transmission of multiple different service types.

[0063] In this step, the receiver parses the service identifier field in the protocol frame header and allocates the data to the corresponding service processing module or state machine based on the identifier. For example, diagnostic data is processed by calling the log parsing module, and parameter reading and writing are processed by calling the corresponding control logic. The advantage of this approach is that it enables the same PDO communication channel to efficiently carry the data transmission of multiple service types, avoids configuring a separate PDO for each type of service, reduces the complexity of the object dictionary and project configuration, and maintains the accuracy and real-time performance of various data processing methods.

[0064] Figure 4 This diagram illustrates a schematic flowchart of step S400, where the receiver generates a response protocol frame in the transmitted PDO based on the parsing processing result and sends it to the sender. Figure 4 As shown, step S400 includes: In step S410, when parsing the protocol frame, the receiver identifies abnormal situations such as data verification errors, discontinuous sequences, or mismatched service identifiers.

[0065] In this step, the receiver performs integrity and consistency checks on the received payload data area when parsing the protocol frame. Specifically, the receiver first calculates the data checksum and compares it with the checksum field attached to the protocol frame to detect whether any errors occurred during data transmission. Simultaneously, it compares the sequence identifier of the current protocol frame with the sequence identifier of previously received frames to determine if there are any discontinuous sequences. It also verifies the service identifier information to ensure that the data type of the frame is consistent with the expected service type. Through this multi-check and identification mechanism, the receiver can promptly detect data anomalies or errors, preventing invalid or corrupted data from affecting subsequent system processing, thus improving the reliability of data communication and the security of system operation.

[0066] Step S420: Write the corresponding error flag information and error code into the control information field of the response protocol frame and send it to the sender via PDO.

[0067] In this step, the receiver converts the identified anomalies into specific error flags and error codes, writes them into the control information field of the response protocol frame, and sends the information back to the sender via a PDO (Passive Error Detection). In this step, the receiver sets corresponding error flags based on different anomaly types, such as verification failure flags, sequence error flags, or service identification error flags, and attaches detailed error codes so that the sender can clearly identify the specific source of the error. The advantage of this is that the sender can receive feedback immediately and take appropriate measures for different error types, such as retransmitting data or adjusting communication strategies, thereby improving the overall stability and efficiency of communication.

[0068] Step S430: Adjust the receiving or buffering strategy based on the error state, and implement delayed reception or buffering control for subsequent protocol frames to avoid buffer overflow or data corruption.

[0069] In this step, the receiver dynamically adjusts the reception and buffering strategy for subsequent protocol frames based on the currently identified error state. For example, when a discontinuous sequence or an impending data buffer overflow is detected, the receiver will temporarily suspend the reception of new protocol frames or temporarily adjust the buffer allocation to ensure the integrity of already received data. The advantage of this step is that by dynamically managing the reception rhythm and buffer resources, data corruption or loss can be effectively avoided, while ensuring that the system can maintain stable communication even under abnormal conditions, thereby enhancing the reliability and adaptability of the protocol in high real-time scenarios.

[0070] In one embodiment, the custom protocol data transmission method further includes: When generating a protocol frame, the sender writes the corresponding protocol version identifier information into the protocol frame.

[0071] In this step, the protocol version identification information may include a major version number, minor version number, or revision number, so that the receiver can clearly identify the specific protocol specification followed by the current protocol frame. The advantage of this is that it enables the receiver to correctly parse and process data based on the version information, avoiding data errors or misoperations caused by version differences, thereby improving the compatibility and reliability of the entire communication system.

[0072] When receiving a protocol frame, the receiver identifies the protocol version based on the protocol version identifier information and selects the corresponding parsing logic or processing strategy according to the version information to ensure compatible processing of different version protocol frames.

[0073] In this step, the receiver can maintain multiple parsing logic modules or policy sets, each corresponding to a specific version of the protocol format and field definitions. The advantage of this step is that it ensures that protocol frames of different versions are processed correctly on the same communication channel, avoiding parsing errors caused by version differences, and facilitating backward compatibility when the system upgrades or expands the protocol.

[0074] When an incompatible or unrecognizable protocol version is detected, the receiver sends a version error flag or prompt message to the sender via a response protocol frame, thereby supporting data communication and compatibility extension of different protocol versions within a single PDO channel.

[0075] In this step, the receiver can set specific error flags in the control field, along with an error code or brief message, to notify the sender that the current protocol frame is not supported. The advantage of this is that the sender can immediately be aware of version mismatches and take appropriate measures (such as retransmitting data, switching versions, or displaying error messages), thereby achieving compatibility and expansion of a single PDO channel across different protocol versions, enhancing the system's flexibility and scalability.

[0076] According to the above embodiments, by employing mechanisms such as fragmentation identifiers, sequence detection, service identifiers, and protocol version identifiers in the control information, data fragmentation and reassembly, anomaly handling, service classification, and multi-version protocol compatibility can be supported, thereby achieving flexible and reliable processing of large-capacity data, different service types, and multiple protocol versions. This scheme enables the same PDO channel to carry multiple types of service data, improving the utilization and scalability of the communication channel, while enhancing the system's adaptability and reliability in various custom data scenarios such as parameter access, diagnosis, debugging, and extended states.

[0077] This invention also provides a custom protocol data transmission system based on EtherCAT, such as... Figure 5As shown, this custom protocol data transmission system includes a slave object dictionary module, a protocol frame encoding module, a protocol frame decoding module, and an EtherCAT interface module. The slave object dictionary module is configured to define receive channel objects and transmit channel objects for custom protocol communication, and maps these objects to at least one set of receive PDOs and transmit PDOs for process data objects (PDOs). The protocol frame encoding module encapsulates the custom data to be sent according to a preset protocol frame format when any communication node is the sender, generating a protocol frame containing control information, sequence identification information, and a payload data area. The protocol frame decoding module parses the protocol frames received through the PDOs when any communication node is the receiver, identifies the protocol frames based on the control information and sequence identification information, and processes the data in the payload data area. The EtherCAT interface module communicates with both the master and slave stations, sending the protocol frames generated by the protocol frame encoding module to the bus via transmit PDOs, and providing the PDO data received from the bus to the protocol frame decoding module, thus enabling bidirectional custom protocol data communication between the sender and receiver based on PDOs.

[0078] In the above-described custom protocol data transmission system based on EtherCAT, the specific implementation methods for data transmission refer to the relevant content of the embodiments in the above methods, and will not be repeated here.

[0079] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0080] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A custom protocol data transmission method based on EtherCAT, applied to a system containing an EtherCAT master and EtherCAT slave, characterized in that, Includes the following steps: Define receive channel objects and send channel objects for custom protocol communication in the object dictionary of the slave station, and map the receive channel objects and send channel objects to at least one set of process data objects PDOs for receiving PDOs and sending PDOs; The master station or slave station constructs and sends a protocol frame to the peer node in the received PDO. The protocol frame includes control information for indicating the frame status, sequence identification information for identifying the communication order, and a payload data area for carrying custom data. When the receiving party processes PDO data periodically, it identifies the protocol frame based on the control information and the sequence identifier information, and performs parsing processing on the data in the payload data area. The receiver generates a response protocol frame in the transmit PDO based on the parsing and processing results and sends it to the sender; The sender receives the response protocol frame and matches it with the corresponding protocol frame to complete the custom protocol communication based on the PDO.

2. The custom protocol data transmission method based on EtherCAT according to claim 1, characterized in that, The specific steps for the receiving party to identify the protocol frame based on the control information and the sequence identifier information, and to parse the data in the payload data area when periodically processing PDO data, include: The receiver compares the sequence identification information in the currently received protocol frame with the sequence identification information of the processed protocol frames; When the sequence identification information is inconsistent with the processed record, the protocol frame is determined to be a new protocol frame and the data in its payload data area is parsed and processed. When the sequence identifier information matches the processed record, the protocol frame is determined to be a duplicate protocol frame and the parsing process is ignored or the corresponding response protocol frame is returned directly.

3. The custom protocol data transmission method based on EtherCAT according to claim 2, characterized in that, The control information includes at least one of the following: Frame validity identification information used to indicate that the current protocol frame is a valid data frame; Confirmation request identification information used to instruct the sender to request the receiver to return the processing result; This is an acknowledgment information used to indicate to the receiver that the protocol frame processing is complete and a result has been returned; Error indication information used to indicate abnormal situations that occur during protocol frame processing.

4. The custom protocol data transmission method based on EtherCAT according to claim 3, characterized in that, The control information also includes first frame identifier information and last frame identifier information for indicating the data fragmentation status. When the receiving party periodically processes PDO data, identifying the protocol frame based on the control information and the sequence identifier information, and parsing the data in the payload data area, further includes the following steps: When the control information of the protocol frame contains both the first frame identifier information and the last frame identifier information, the data in the payload data area is parsed as complete data. When the control information of the protocol frame contains first frame identification information but not last frame identification information, the data in the payload data area is cached as the starting part of the fragmented data. When the control information of the protocol frame contains the last frame identifier information, the payload data area of ​​the current protocol frame is concatenated with the previously cached fragmented data to form complete data before parsing.

5. The custom protocol data transmission method based on EtherCAT according to claim 4, characterized in that, The specific steps for concatenating the payload data area of ​​the current protocol frame with the previously cached fragmented data to form complete data and then performing parsing processing include: When a protocol frame containing first frame identification information is received, the starting sequence number of the current data reassembly process is established according to the sequence identifier of the protocol frame containing the first frame identification information. When receiving subsequent protocol frames, their sequence identifiers are compared with those of the previous protocol frame to determine whether the received protocol frames arrive in the predetermined order. When a discontinuous sequence identifier is detected, the current data reassembly process is terminated and the cached fragment data is cleared. When a protocol frame containing last frame identifier information and consecutive sequence identifiers is received, the cached fragmented data is concatenated with the payload data in the protocol frame containing last frame identifier information and consecutive sequence identifiers to form complete data and then parsing it.

6. The EtherCAT-based custom protocol data transmission method according to claim 1, characterized in that, The length of the payload data area of ​​the protocol frame is determined based on the available buffer space of the receiving device or the available data length of the PDO. The specific steps include: When the sender generates a protocol frame, the data to be sent is segmented according to the preset maximum payload length. The segmented data is sequentially filled into the payload data area of ​​multiple protocol frames for transmission, ensuring that the payload data length in each protocol frame does not exceed the maximum payload length, so as to guarantee that the receiver can properly parse and process the received protocol frames.

7. The custom protocol data transmission method based on EtherCAT according to claim 1, characterized in that, The protocol frame also includes service identification information for identifying the data service type, and the custom protocol data transmission method further includes: When generating a protocol frame, the sender writes the corresponding service identification information into the protocol frame according to the service type to which the data to be sent belongs; After receiving the protocol frame, the receiver classifies the data in the payload data area according to the service identification information, and calls the processing logic corresponding to the service type for parsing or execution, so that the same PDO communication channel can carry the data transmission of multiple different service types.

8. The custom protocol data transmission method based on EtherCAT according to claim 1, characterized in that, The specific steps by which the receiver generates a response protocol frame in the transmitted PDO based on the parsing processing result and sends it to the sender include: When parsing protocol frames, the receiver identifies abnormal situations such as data verification errors, discontinuous sequences, or mismatched service identifiers. Write the corresponding error flag information and error code into the control information field of the response protocol frame and send it to the sender via PDO; Adjust the receiving or buffering strategy based on the error state, and implement delayed reception or buffering control for subsequent protocol frames to avoid buffer overflow or data corruption.

9. The EtherCAT-based custom protocol data transmission method according to any one of claims 1 to 8, characterized in that, The custom protocol data transmission method further includes: When generating a protocol frame, the sender writes the corresponding protocol version identifier information into the protocol frame; When receiving a protocol frame, the receiver identifies the protocol version based on the protocol version identifier information and selects the corresponding parsing logic or processing strategy based on the version information to ensure compatible processing of different version protocol frames. When an incompatible or unrecognizable protocol version is detected, the receiver sends a version error flag or prompt message to the sender via a response protocol frame, thereby supporting data communication and compatibility extension of different protocol versions within a single PDO channel.

10. A custom protocol data transmission system employing the custom protocol data transmission method based on EtherCAT as described in any one of claims 1-9, characterized in that, The system includes: The slave object dictionary module is configured to define receive channel objects and send channel objects for custom protocol communication, and to map the receive channel objects and send channel objects to at least one set of process data objects (PDOs) for receiving and sending PDOs. The protocol frame encoding module is used to encapsulate the custom data to be sent according to the preset protocol frame format when any communication node is the sender, and generate a protocol frame containing control information, sequence identification information and payload data area. The protocol frame decoding module is used to parse the protocol frames received through PDO when any communication node is the receiver, identify the protocol frames according to the control information and the sequence identification information, and parse and process the data in the payload data area. The EtherCAT interface module is communicatively connected to both the master station and the slave station. It is used to send the protocol frames generated by the protocol frame encoding module to the bus via PDO, and to provide the PDO data received from the bus to the protocol frame decoding module, so as to realize bidirectional custom protocol data communication between the sender and receiver based on the PDO.

Images