A reliable CANOpen communication software architecture design method based on embedded controller

Abstract

This invention relates to a reliable CANOpen communication software architecture design method based on an embedded controller, solving the technical problems of high ROM consumption of the controller MCU, high requirements for protocol stack porting, and high user expertise in existing technologies. Based on the CANOpen master station command retransmission mechanism and the slave station node heartbeat mechanism, this invention enables the master station to promptly detect slave station disconnections and proactively issue alarms, achieving reliable CANOpen communication in motion control. It also determines the communication status based on data feedback from the slave station, thereby judging the validity of the CANOpen master station command transmission. This invention can effectively improve the stability of CANOpen communication and serves as a reference for the rapid implementation of basic CANOpen master station software architecture design in industrial control or automation industries.

Description

Technical Field

[0001] This invention relates to embedded motion control technology, and more specifically to a reliable CANOpen communication software architecture design method based on an embedded controller. Background Technology

[0002] With the rapid development of intelligent manufacturing and automation technologies, CANOpen, as a communication protocol based on the CAN bus, is widely used in motion control, automation and intelligent manufacturing fields due to its high reliability, real-time performance and strong anti-interference capabilities.

[0003] While traditional PLC controllers support CANOpen master station functionality, they often lack secondary development capabilities or are closed-source systems. This limits user customization and optimization, fails to meet specific needs, and compromises security. Furthermore, PLC controllers are relatively expensive.

[0004] Therefore, to save costs and improve self-control, embedded controllers are often used in some industrial automation scenarios. Due to their flexibility and low cost, embedded controllers play an increasingly important role in the field of industrial automation. However, to quickly implement reliable and stable CANOpen communication functions in resource-constrained embedded controllers, a complete redesign of the software architecture is required at the software level.

[0005] Currently, embedded controllers (hereinafter referred to as controllers) typically implement CANOpen communication by porting open-source protocol stacks to achieve CANOpen master station functionality. However, this approach consumes a significant amount of ROM in the controller's MCU, requires a high level of expertise in protocol stack porting, and demands a high level of professional skill from the user. Furthermore, this method makes it difficult to locate problems when communication anomalies occur, resulting in significant maintenance challenges. Summary of the Invention

[0006] The purpose of this invention is to solve the technical problems of high ROM consumption of the controller MCU, high requirements for protocol stack porting and high professional skills of users in the existing technology, and to provide a reliable CANOpen communication software architecture design method based on embedded controller.

[0007] The concept of this invention is to design a software architecture based on the principles of the Network Management (NMT) communication mechanism and the CANOpen SDO communication mechanism, and to use the CAN receive interrupt mechanism of the embedded controller to feed back the CANOpen communication status and confirm the communication status in real time to ensure reliable communication.

[0008] To achieve the above objectives and realize the above concepts, the technical solution provided by the present invention is as follows:

[0009] A reliable CANOpen communication software architecture design method based on an embedded controller, characterized by the following steps:

[0010] S0 establishes communication between the master and slave stations by designating the controller as the CANOpen master station and the motion control object as the CANOpen slave station; each slave station is treated as a node.

[0011] Configure the controller's timing interval, response timeout threshold, retransmission count threshold, and configure the heartbeat interval for each node;

[0012] S1, Start the node; the node sends a heartbeat message to the controller at heartbeat intervals;

[0013] S2, initialize the controller's timer; start the timer to begin counting; the timer overflows after the count value reaches the set time.

[0014] S3 sends an SDO command to the node through the controller;

[0015] S4, the node receives the SDO command and sends an SDO response command to the controller;

[0016] S5, the controller waits for the SDO response and determines whether an alarm is needed or the SDO command should be resent;

[0017] S6, the controller receives the SDO response, resets the retransmission count to zero, and checks whether the SDO response is correct:

[0018] If the SDO response is correct, the communication of that SDO instruction is considered to have ended normally, and the process jumps to step S3 to continue sending the next SDO instruction until the communication of all SDO instructions is completed.

[0019] If the SDO response is abnormal, check the SDO command sent by the controller. If it is correct, proceed to step S3 to resend the SDO command.

[0020] While steps S3 to S6 are being executed, the controller periodically queries the node heartbeat, waits for the timed overflow, and determines whether an alarm is needed.

[0021] Furthermore, in step S5, if the controller still does not receive the SDO response after the response timeout threshold (i.e., response timeout), the timeout retransmission mechanism is used to jump to step S3 to resend the SDO command. At this time, if the retransmission number threshold is exceeded, the communication of the SDO command is considered abnormal, the controller performs fault handling and alarm, and notifies the user to perform maintenance.

[0022] Furthermore, step S5 specifically includes:

[0023] S5-1, the controller checks whether it has received an SDO response command:

[0024] If the controller receives an SDO response, continue to execute step S6;

[0025] If the controller does not receive an SDO response, proceed to step S5-2;

[0026] S5-2, The controller performs a secondary check to determine if a response timeout has occurred:

[0027] If no response is received and the timeout occurs, repeat step S5-1.

[0028] If the response times out, proceed to step S5-3;

[0029] S5-3, the controller checks three times whether the retransmission limit has been exceeded:

[0030] If the number of retransmissions has not exceeded, proceed to step S3 to resend the SDO command;

[0031] If the number of retransmissions is exceeded, the number of retransmissions will be reset to zero, the controller status will be set to SDO communication abnormality, the controller will perform fault handling and alarm, and notify the user to perform maintenance; after the maintenance is completed, step S0 will be executed again.

[0032] Furthermore, the periodic query node heartbeat is specifically as follows:

[0033] SE-1, the controller continuously checks whether a timer overflow has occurred:

[0034] If the count value has not reached the timer period, continue to execute steps S3 to S6;

[0035] If the count value reaches the timer period, proceed to step SE-2;

[0036] SE-2, the controller makes a secondary check to see if it has received a heartbeat message from the node:

[0037] If the controller receives a heartbeat message, it will clear the timer and restart counting;

[0038] If the controller does not receive a heartbeat message, the timer will be cleared, the controller status will be set to node fault, the controller will perform fault handling and alarm, and notify the user to perform maintenance; after the maintenance is completed, step S0 will be executed again.

[0039] Furthermore, in step S5, the controller receives the SDO response at the CAN receive interrupt.

[0040] Furthermore, in step S1, the controller receives the node's heartbeat message at the CAN receive interrupt point.

[0041] Furthermore, step S0 specifically includes:

[0042] S0-1 establishes communication between the master and slave stations by designating the controller as the CANOpen master station and the motion control object as the CANOpen slave station; each slave station is considered a node.

[0043] S0-2, Reset the node;

[0044] S0-3, Configure the node to pre-operation mode;

[0045] S0-4, set the heartbeat time of the node as needed;

[0046] S0-5, Configure the node to the operating mode;

[0047] S0-6, set the controller's timing period, response timeout threshold, and retransmission count threshold as needed.

[0048] Furthermore, steps S0-2 to S0-5 are the node configuration process, and step S0-6 is the controller configuration process. The node configuration process and the controller configuration process can be interchanged. Step S0-6 can also be located between steps S0-1 and S0-2, that is:

[0049] S0-1 establishes communication between the master and slave stations by designating the controller as the CANOpen master station and the motion control object as the CANOpen slave station; each slave station is considered a node.

[0050] S0-2, set the controller's timing time, response timeout threshold, and retransmission count threshold as needed;

[0051] S0-3, reset the node;

[0052] S0-4, Configure the node to pre-operation mode;

[0053] S0-5, set the heartbeat time of the node as needed;

[0054] S0-6, configure the node to the operating mode.

[0055] The advantages of this invention compared to the prior art are:

[0056] 1. This invention provides a reliable CANOpen communication software architecture design method based on an embedded controller. It combines the SDO communication method to design the CANOpen communication software architecture. By using the timer and CAN external interrupt function of the embedded controller, the basic functions of the CANOpen master station can be quickly implemented, shortening the project development cycle and enabling reliable CANOpen communication on the embedded controller.

[0057] 2. This invention provides a reliable CANOpen communication software architecture design method based on an embedded controller. By using CANOpen's SDO communication mode, combined with a command retransmission mechanism and fault handling alarms, the communication status can be determined based on the data information fed back by the slave station (node ​​heartbeat and SDO response messages), thereby determining the validity of the CANOpen master station command transmission. This invention can effectively improve the stability of CANOpen communication, ensure stable and reliable CANOpen communication, significantly improve product communication capabilities, and can serve as a reference for the rapid implementation of basic CANOpen master station functional software architecture design in industrial control or automation industries.

[0058] 3. The present invention provides a reliable CANOpen communication software architecture design method based on an embedded controller, which enables the CANOpen master station to achieve independent and controllable basic functions, facilitates problem location and product maintenance, and reduces product maintenance costs. Attached Figure Description

[0059] Figure 1 This is a flowchart (single SDO instruction) of an embodiment of a reliable CANOpen communication software architecture design method based on an embedded controller according to the present invention. Detailed Implementation

[0060] The specific technical solutions in the embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0061] This invention designs a real-time and reliable CANOpen master communication software architecture based on the CANOpen motion control standard protocol (DSP402), combined with the controller's timer, interrupt mechanism, and SDO communication method. The design primarily utilizes the CANOpen master command retransmission mechanism and the slave node heartbeat mechanism, enabling the master station to promptly detect slave disconnections and proactively issue alarms, thus achieving reliable CANOpen communication in motion control and timely obtaining communication status.

[0062] The basic principle of this invention is as follows: when the controller sends a CANOpen SDO data packet (i.e., an SDO command) to the motion-controlled object, the controller's CAN receive interrupt service routine determines the validity of the data packet based on the feedback information. If no feedback information corresponding to the CANOpen data packet is received within a certain time (response timeout threshold), the command is retransmitted. When the number of retransmissions exceeds the set retransmission threshold, the motion-controlled object is considered to be faulty. Simultaneously, the motion-controlled object's heartbeat cycle (i.e., the set heartbeat time) is set during initialization. By periodically checking for the presence or absence of the motion-controlled object's heartbeat message, the controller can promptly detect the online status of the motion-controlled object.

[0063] In CANOpen communication, a task requires multiple SDO instructions to complete. However, since the processing flow of each SDO instruction is basically the same, this embodiment of the invention will only describe a single SDO instruction.

[0064] Figure 1 A flowchart illustrating a reliable CANOpen communication software architecture design method based on an embedded controller, provided for embodiments of the present invention, specifically includes the following steps:

[0065] S0, during software initialization, to ensure the effective and controllable configuration of slave node parameters, a node reset must be performed first. Specifically:

[0066] Establish communication between the master and slave stations by using the controller as the CANOpen master station and the motion control object as the CANOpen slave station; treat each slave station as a node; configure the controller's timing, response timeout threshold, retransmission number threshold, and configure the heartbeat time of each node.

[0067] S0-1 establishes communication between the master and slave stations by designating the controller as the CANOpen master station and the motion control object as the CANOpen slave station; each slave station is considered a node.

[0068] S0-2, Reset the node;

[0069] S0-3, Configure the node to pre-operation mode;

[0070] S0-4, set the heartbeat time of the node as needed;

[0071] S0-5, Configure the node to the operating mode;

[0072] S0-6, set the controller's timing period, response timeout threshold, and retransmission count threshold as needed.

[0073] In other embodiments of the present invention, step S0-6 may also be located between step S0-1 and step S0-2.

[0074] S1, Start the node; the node sends a heartbeat message to the controller at regular heartbeat intervals. The controller receives the node's heartbeat message at the CAN receive interrupt point.

[0075] S2, initialize the controller's timer; start the timer to begin counting; the timer overflows after the count value reaches the set time.

[0076] S3 sends an SDO command to the node through the controller.

[0077] S4, the node receives the SDO command and sends an SDO response command to the controller.

[0078] S5: If the controller does not receive data within a certain time, a timeout retransmission mechanism is used to ensure that the controller's SDO data is sent to the node normally. If the number of retransmissions exceeds the retransmission threshold and no SDO response data is received from the node, then this SDO communication is abnormal, and fault handling and alarms are required. Specifically:

[0079] The controller waits for the SDO response and determines whether an alarm is needed or the SDO command should be retransmitted. If the controller does not receive the SDO response before the response timeout threshold, it uses the timeout retransmission mechanism to jump to step S3 to retransmit the SDO command. If the retransmission count threshold is exceeded, the communication of the SDO command is considered abnormal, and the controller performs fault handling and alarm, notifying the user for maintenance. The controller receives the SDO response at the CAN receive interrupt point. The retransmission count is the number of times the SDO command has been sent; each time the SDO command is retransmitted, the retransmission count increases by one.

[0080] S5-1, the controller checks whether it has received an SDO response command:

[0081] If the controller receives an SDO response, continue to execute step S6;

[0082] If the controller does not receive an SDO response, proceed to step S5-2;

[0083] S5-2, The controller performs a secondary check to determine if a response timeout has occurred:

[0084] If no response is received and the timeout occurs, repeat step S5-1.

[0085] If the response times out, proceed to step S5-3;

[0086] S5-3, the controller checks three times whether the retransmission limit has been exceeded:

[0087] If the number of retransmissions has not exceeded, proceed to step S3 to resend the SDO command;

[0088] If the number of retransmissions is exceeded, the number of retransmissions will be reset to zero, the controller status will be set to SDO communication abnormality, the controller will perform fault handling and alarm, and notify the user to perform maintenance; after the maintenance is completed, step S0 will be executed again.

[0089] S6, when using CANOpen's SDO method for node parameter configuration or status query, the correctness of the SDO response data is received and checked at the controller's CAN receive interrupt. If correct data is received, the CANOpen SDO communication ends normally. If abnormal data is received, the SDO data packet sent by the controller needs to be checked for correctness, and then resent after confirmation.

[0090] Specifically:

[0091] Upon receiving the SDO response, the controller resets the retransmission count to zero and checks if the SDO response is correct.

[0092] If the SDO response is correct, the communication of that SDO instruction is considered to have ended normally, and the process jumps to step S3 to continue sending the next SDO instruction until the communication of all SDO instructions is completed.

[0093] If the SDO response is abnormal, check the SDO command sent by the controller. If it is correct, proceed to step S3 to resend the SDO command.

[0094] To ensure the controller can promptly detect and handle node downtime or communication loss, it uses a timer to periodically query node heartbeat data, which is received via CAN interrupt. If no node heartbeat data or corresponding flag is received during the query, it indicates a node fault, requiring fault handling and an alarm. In this embodiment, while steps S3 to S6 are being executed, the controller periodically queries the node heartbeat, waits for the timer to overflow, and determines whether an alarm is needed. Specifically:

[0095] SE-1, the controller continuously checks whether a timer overflow has occurred:

[0096] If the count value has not reached the timer period, continue to execute steps S3 to S6;

[0097] If the count value reaches the timer period, proceed to step SE-2;

[0098] SE-2, the controller makes a secondary check to see if it has received a heartbeat message from the node:

[0099] If the controller receives a heartbeat message, it will clear the timer and restart counting;

[0100] If the controller does not receive a heartbeat message, the timer will be cleared, the controller status will be set to node fault, the controller will perform fault handling and alarm, and notify the user to perform maintenance; after the maintenance is completed, step S0 will be executed again.

[0101] The above description is merely one embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any equivalent structural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are included within the scope of patent protection of the present invention.

Claims

1. A reliable CANOpen communication software architecture design method based on an embedded controller, characterized in that, Includes the following steps: S0: The controller is set as the master station of CANOpen, and the motion control object is set as the slave station of CANOpen, establishing communication between the master station and the slave station; Each slave station is treated as a node; Configure the controller's timing interval, response timeout threshold, retransmission count threshold, and configure the heartbeat interval for each node; S1, Start the node; The node sends a heartbeat message to the controller at heartbeat intervals; The controller receives the node's heartbeat message at the CAN receive interrupt point; S2, initialize the controller's timer; start the timer to begin counting; the timer overflows after the count value reaches the set time. S3 sends an SDO command to the node through the controller; S4, the node receives the SDO command and sends an SDO response command to the controller; S5, the controller waits for the SDO response and determines whether an alarm is needed or the SDO command needs to be resent; the controller receives the SDO response at the CAN receive interrupt point; S6, the controller receives the SDO response, resets the retransmission count to zero, and checks whether the SDO response is correct: If the SDO response is correct, the communication of that SDO instruction is considered to have ended normally, and the process jumps to step S3 to continue sending the next SDO instruction until the communication of all SDO instructions is completed. If the SDO response is abnormal, check the SDO command sent by the controller. If it is correct, proceed to step S3 to resend the SDO command. While steps S3 to S6 are being executed, the controller periodically queries the node heartbeat, waits for the timed overflow, and determines whether an alarm is needed. The periodic query node heartbeat specifically refers to: SE-1, the controller continuously checks whether a timer overflow has occurred: If the count value has not reached the timer period, continue to execute steps S3 to S6; If the count value reaches the timer period, proceed to step SE-2; SE-2, the controller makes a secondary check to see if it has received a heartbeat message from the node: If the controller receives a heartbeat message, it will clear the timer and restart counting; If the controller does not receive a heartbeat message, the timer will be cleared, the controller status will be set to node fault, the controller will perform fault handling and alarm, and notify the user to perform maintenance. After maintenance is complete, repeat step S0.

2. The reliable CANOpen communication software architecture design method based on an embedded controller according to claim 1, characterized in that: In step S5, if the controller does not receive an SDO response outside the response timeout threshold, it uses the timeout retransmission mechanism to jump to step S3 to resend the SDO command. If the retransmission count threshold is exceeded, the communication of the SDO command is considered abnormal, the controller performs fault handling and alarm, and notifies the user to perform maintenance.

3. The reliable CANOpen communication software architecture design method based on an embedded controller according to claim 2, characterized in that, Step S5 is as follows: S5-1, the controller checks whether it has received an SDO response command: If the controller receives an SDO response, continue to execute step S6; If the controller does not receive an SDO response, proceed to step S5-2; S5-2, The controller performs a secondary check to determine if a response timeout has occurred: If no response is received and the timeout occurs, repeat step S5-1. If the response times out, proceed to step S5-3; S5-3, the controller checks three times whether the retransmission limit has been exceeded: If the number of retransmissions has not exceeded, proceed to step S3 to resend the SDO command; If the number of retransmissions is exceeded, the number of retransmissions will be reset to zero, the controller status will be set to SDO communication abnormality, the controller will perform fault handling and alarm, and notify the user to perform maintenance; after the maintenance is completed, step S0 will be executed again.

4. The reliable CANOpen communication software architecture design method based on an embedded controller according to claim 1, characterized in that, Step S0 specifically includes: S0-1 establishes communication between the master and slave stations by designating the controller as the CANOpen master station and the motion control object as the CANOpen slave station; each slave station is considered a node. S0-2, Reset the node; S0-3, Configure the node to pre-operation mode; S0-4, set the heartbeat time of the node as needed; S0-5, Configure the node to the operating mode; S0-6, set the controller's timing period, response timeout threshold, and retransmission count threshold as needed.

5. The reliable CANOpen communication software architecture design method based on an embedded controller according to claim 1, characterized in that, Step S0 specifically includes: S0-1 establishes communication between the master and slave stations by designating the controller as the CANOpen master station and the motion control object as the CANOpen slave station; each slave station is considered a node. S0-2, set the controller's timing time, response timeout threshold, and retransmission count threshold as needed; S0-3, reset the node; S0-4, Configure the node to pre-operation mode; S0-5, set the heartbeat time of the node as needed; S0-6, configure the node to the operating mode.

Images