Reliable CANOpen communication software architecture design method based on embedded controller

Abstract

The invention relates to a reliable CANOpen communication software architecture design method based on an embedded controller, and solves the technical problems of high ROM (Read Only Memory) consumption of a controller MCU (Microprogrammed Control Unit) and high requirements on protocol stack transplantation and professional ability of a user in the prior art. The method is designed according to the retransmission mechanism of the CANOpen master station instruction and the node heartbeat mechanism of the slave station, so that the master station can timely discover the offline condition of the slave station and actively give an alarm, reliable communication of the CANOpen in motion control is realized, the communication state is judged according to the data information fed back by the slave station, and then the effectiveness of sending the CANOpen master station instruction is judged. According to the method, the stability of CANOpen communication can be effectively improved, and the method can be used as a reference for an embedded controller in industrial control or automation industry to quickly realize basic function software architecture design of a CANOpen master station.

Description

Technical Field

[0001] The present invention relates to an embedded motion control technology, and in particular to a reliable CANOpen communication software architecture design method based on an embedded controller. Background Art

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

[0003] Although traditional PLC controllers support CANOpen master functions, they often do not support secondary development or are closed-source systems, which limits users' further customization and optimization, cannot meet some specific needs, and cannot ensure security. In addition, the cost of PLC controllers is relatively high.

[0004] Therefore, in order to save costs and improve autonomous controllability, embedded controllers are often used in some industrial automation scenarios. Embedded controllers play an increasingly important role in the field of industrial automation due to their flexibility and low cost. In order to quickly implement reliable and stable CANOpen communication functions in embedded controllers with limited resources, it is necessary to redesign the software architecture from the software level.

[0005] When implementing CANOpen communication, existing embedded controllers (referred to as controllers) generally implement CANOpen master station functions by transplanting open source protocol stacks. However, this method consumes a lot of ROM of the controller MCU, and also has high requirements for protocol stack transplantation, and also requires high professional ability of users. In addition, when communication is abnormal, this method is not easy to locate the problem and is difficult to maintain. Summary of the invention

[0006] The purpose of the present invention is to solve the technical problems of the prior art that the controller MCU consumes a lot of ROM, requires high professional skills of protocol stack transplantation and users, and to provide a reliable CANOpen communication software architecture design method based on an embedded controller.

[0007] The idea of ​​the present invention is to design the software architecture according to the principles of the network management NMT communication mechanism and the SDO communication mechanism of CANOpen, use the CAN receiving interrupt mechanism of the embedded controller to feedback the CANOpen communication status, and confirm the communication status in real time to ensure reliable communication.

[0008] In order to achieve the above objectives and realize the above concepts, the technical solutions provided by the present invention are as follows:

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

[0010] S0, the controller is used as the CANOpen master station, the motion control object is used as the CANOpen slave station, and the communication between the master station and the slave station is established; each slave station is regarded as a node;

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

[0012] S1, start the node; the node sends a heartbeat message to the controller at every heartbeat time interval;

[0013] S2, initializing the timer of the controller; starting the timer and starting counting; the timer overflows after the count value reaches the timing time;

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

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

[0016] S5, the controller waits for the SDO reply and determines whether to alarm or resend the SDO instruction;

[0017] S6: The controller receives the SDO reply, clears the number of retransmissions, and determines whether the SDO reply is correct:

[0018] If the SDO reply is correct, it is considered that the communication of this SDO instruction is completed 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 reply is abnormal, check the SDO instruction sent by the controller, and after confirming that it is correct, jump to step S3 and resend the SDO instruction;

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

[0021] Furthermore, in step S5, if the controller still does not receive the SDO reply command outside the response timeout threshold (i.e., the response times out), the timeout retransmission mechanism is used to jump to step S3 to resend the SDO instruction; at this time, if the retransmission count threshold is exceeded, it is considered that the communication of the SDO instruction is abnormal, the controller performs fault processing and alarm, and notifies the user to perform maintenance.

[0022] Furthermore, step S5 is specifically as follows:

[0023] S5-1, the controller determines whether it has received the SDO reply command:

[0024] If the controller receives the SDO reply command, it continues to execute step S6;

[0025] If the controller does not receive the SDO reply command, execute step S5-2;

[0026] S5-2, the controller determines whether a response timeout occurs for the second time:

[0027] If there is no response timeout, re-execute step S5-1;

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

[0029] S5-3, the controller determines three times whether the number of retransmissions has been exceeded:

[0030] If the number of retransmissions has not been exceeded, jump to step S3 to resend the SDO instruction;

[0031] If the number of retransmissions exceeds the limit, the number of retransmissions is reset to zero, the controller state is set to SDO communication abnormality, the controller performs fault processing and alarms, and notifies the user to perform maintenance; after the maintenance is completed, step S0 is executed again.

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

[0033] SE-1, the controller continuously determines whether the timer overflows:

[0034] If the count value does not reach the timing time, continue to execute steps S3 to S6;

[0035] If the count value reaches the timing time, execute step SE-2;

[0036] SE-2, the controller determines whether it has received the heartbeat message from the node:

[0037] If the controller receives a heartbeat message, it resets the timer and starts counting again;

[0038] If the controller does not receive the heartbeat message, the timer is reset, the controller state is set to node failure, the controller performs fault processing and alarm, and notifies the user to perform maintenance; after the maintenance is completed, step S0 is executed again.

[0039] Further, in step S5, the controller receives an SDO reply command at the CAN receive interrupt.

[0040] Further, in step S1, the controller receives the heartbeat message of the node at the CAN reception interruption.

[0041] Furthermore, step S0 is specifically as follows:

[0042] S0-1, the controller is used as the CANOpen master station, the motion control object is used as the CANOpen slave station, and the communication between the master station and the slave station is established; each slave station is regarded as a node;

[0043] S0-2, reset the node;

[0044] S0-3, configure the node to pre-operational mode;

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

[0046] S0-5, configure the node to operational mode;

[0047] S0-6, set the controller timing time, response timeout threshold and retransmission threshold as needed.

[0048] Further, steps S0-2 to S0-5 are node configuration processes, and step S0-6 is a controller configuration process. The node configuration process and the controller configuration process can be interchanged in order, and the above step S0-6 can also be located between step S0-1 and step S0-2, that is:

[0049] S0-1, the controller is used as the CANOpen master station, the motion control object is used as the CANOpen slave station, and the communication between the master station and the slave station is established; each slave station is regarded as a node;

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

[0051] S0-3, reset the node;

[0052] S0-4, configure the node to pre-operational mode;

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

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

[0055] The beneficial effects of the present invention compared with the prior art are as follows:

[0056] 1. The present invention provides a reliable CANOpen communication software architecture design method based on an embedded controller. The software architecture of CANOpen communication is designed in combination with the SDO communication method. By using the timer of the embedded controller and the CAN external interrupt function, the basic functions of the CANOpen master station can be quickly realized, the project development cycle can be shortened, and reliable CANOpen communication can be realized on the embedded controller.

[0057] 2. The present invention provides a reliable CANOpen communication software architecture design method based on an embedded controller. By using the SDO communication mode of CANOpen, combined with the command retransmission mechanism and fault handling alarm, the communication state can be judged according to the data information fed back by the slave (node ​​heartbeat and SDO reply message), and then the validity of the CANOpen master station command transmission can be judged. The present invention can effectively improve the stability of CANOpen communication, ensure that CANOpen communication is stable and reliable, and significantly improve the product communication capability. It can be used as a reference for the design of software architecture for the rapid implementation of the basic functions of the CANOpen master station by embedded controllers in the industrial control or automation industry.

[0058] 3. The present invention provides a reliable CANOpen communication software architecture design method based on an embedded controller, which can realize the autonomous control of the basic functions of the CANOpen master station, facilitate problem location and product maintenance, and reduce the maintenance cost of the product. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 It is a flow chart of an embodiment of a reliable CANOpen communication software architecture design method based on an embedded controller of the present invention (single SDO instruction). DETAILED DESCRIPTION

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

[0061] The present invention designs a real-time and reliable CANOpen master station communication software architecture based on the standard protocol (DSP402) of CANOpen motion control combined with the controller's timer, interrupt mechanism and SDO communication mode. The design is mainly based on the retransmission mechanism of the CANOpen master station command and the node heartbeat mechanism of the slave station, so that the master station can timely detect the offline situation of the slave station and actively alarm, realize the reliable communication of CANOpen in motion control, and can obtain the communication status in time.

[0062] The basic principle of the present invention is that when the controller sends a CANOpen SDO data packet (i.e., an SDO instruction) to the motion control object, the CAN receiving interrupt service program of the controller determines the validity of the data packet based on the feedback information. If the feedback information corresponding to the CANOpen data packet is not received within a certain time (response timeout threshold), the instruction is resent. When the number of retransmissions exceeds the set retransmission number threshold, the motion control object is considered to be faulty. At the same time, the heartbeat cycle of the motion control object (i.e., the set heartbeat time) is set during initialization, and the controller can timely detect the online status of the motion control object by checking the presence or absence of the heartbeat message of the motion control object at a fixed period.

[0063] In CANOpen communication, a task requires multiple SDO instructions to complete, but because the processing flow of each SDO instruction is basically the same, only a single SDO instruction is used for explanation in the embodiment of the present invention.

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

[0065] S0, when the software is initialized, in order to ensure that the slave node parameter configuration is effective and controllable, the node must be reset first. Specifically:

[0066] The controller is used as the CANOpen master station, and the motion control object is used as the CANOpen slave station to establish communication between the master station and the slave station; each slave station is regarded as a node; the controller timing time, response timeout threshold, retransmission threshold, and the heartbeat time of each node are configured.

[0067] S0-1, the controller is used as the CANOpen master station, the motion control object is used as the CANOpen slave station, and the communication between the master station and the slave station is established; each slave station is regarded as a node;

[0068] S0-2, reset the node;

[0069] S0-3, configure the node to pre-operational mode;

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

[0071] S0-5, configure the node to operational mode;

[0072] S0-6, set the controller timing time, response timeout threshold and retransmission 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 each heartbeat time interval. The controller receives the heartbeat message of the node at the CAN receiving interruption.

[0075] S2, initializing the timer of the controller; starting the timer and starting counting; the timer overflows after the count value reaches the timing time.

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

[0077] S4, the node receives the SDO instruction and sends an SDO reply to the controller.

[0078] S5: If the controller does not receive data within a certain period of time, the 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 the node's SDO response data is still not received, then this SDO communication is abnormal and fault handling and alarm are required. Specifically:

[0079] The controller waits for the SDO reply and determines whether to alarm or resend the SDO instruction. If the controller does not receive the SDO reply outside the response timeout threshold, it uses the timeout retransmission mechanism to jump to step S3 to resend the SDO instruction. At this time, if the retransmission threshold is exceeded, it is considered that the communication of the SDO instruction is abnormal, and the controller performs fault processing and alarm, notifying the user to perform maintenance. The controller receives the SDO reply at the CAN receive interrupt. The retransmission count is the number of times the SDO instruction is sent. Each time the SDO instruction is resent, the retransmission count increases once.

[0080] S5-1, the controller determines whether it has received the SDO reply command:

[0081] If the controller receives the SDO reply command, it continues to execute step S6;

[0082] If the controller does not receive the SDO reply command, execute step S5-2;

[0083] S5-2, the controller determines whether a response timeout occurs for the second time:

[0084] If there is no response timeout, re-execute step S5-1;

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

[0086] S5-3, the controller determines three times whether the number of retransmissions has been exceeded:

[0087] If the number of retransmissions has not been exceeded, jump to step S3 to resend the SDO instruction;

[0088] If the number of retransmissions exceeds the limit, the number of retransmissions is reset to zero, the controller state is set to SDO communication abnormality, the controller performs fault processing and alarms, and notifies the user to perform maintenance; after the maintenance is completed, step S0 is executed again.

[0089] S6, when using CANOpen's SDO mode to configure node parameters or query status, the correctness of the SDO reply data is received and checked at the controller's CAN receive interrupt. If the correct data is received, the CANOpen SDO communication ends normally. If abnormal data is received, it is necessary to check whether the SDO data packet sent by the controller is correct, and send it again after confirmation.

[0090] Specifically:

[0091] The controller receives the SDO reply, clears the number of retransmissions, and determines whether the SDO reply is correct:

[0092] If the SDO reply is correct, it is considered that the communication of this SDO instruction is completed 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 reply is abnormal, check the SDO instruction sent by the controller, and after confirming that it is correct, jump to step S3 and resend the SDO instruction.

[0094] In order to enable the controller to detect and handle the node disconnection or communication disconnection in time, the controller uses a timer to periodically query the node heartbeat data, which is received via CAN interrupt. If no node heartbeat data or corresponding flag is received during the query, it indicates that the node is faulty and fault handling and alarm are required. In this embodiment, while executing the above steps S3 to S6, the controller periodically queries the node heartbeat, waits for the timer to overflow, and determines whether an alarm is required. Specifically:

[0095] SE-1, the controller continuously determines whether the timer overflows:

[0096] If the count value does not reach the timing time, continue to execute steps S3 to S6;

[0097] If the count value reaches the timing time, execute step SE-2;

[0098] SE-2, the controller determines whether it has received the heartbeat message from the node:

[0099] If the controller receives a heartbeat message, it resets the timer and starts counting again;

[0100] If the controller does not receive the heartbeat message, the timer is reset, the controller state is set to node failure, the controller performs fault processing and alarm, and notifies the user to perform maintenance; after the maintenance is completed, step S0 is executed again.

[0101] The above content is only an embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any equivalent structural transformations made using the contents of the present invention's specification and drawings, or directly or indirectly applied in other related technical fields, are included in the patent protection scope of the present invention.

Claims

1. A reliable CANOpen communication software architecture design method based on an embedded controller, characterized in that: The following steps are involved: S0, the controller is used as the CANOpen master station, the motion control object is used as the CANOpen slave station, and the communication between the master station and the slave station is established; Consider each slave as a node; Configure the controller's timing time, response timeout threshold, retransmission threshold, and heartbeat time for each node; S1, start the node; the node sends a heartbeat message to the controller at every heartbeat time interval; S2, initializing the timer of the controller; starting the timer and starting counting; the timer overflows after the count value reaches the timing time; S3, sends an SDO instruction to the node through the controller; S4, the node receives the SDO command and sends an SDO reply command to the controller; S5, the controller waits for the SDO reply and determines whether to alarm or resend the SDO instruction; S6: The controller receives the SDO reply, clears the number of retransmissions, and determines whether the SDO reply is correct: If the SDO reply is correct, it is considered that the communication of this SDO instruction is completed 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 reply is abnormal, check the SDO instruction sent by the controller, and after confirming that it is correct, jump to step S3 and resend the SDO instruction; While the steps S3 to S6 are being executed, the controller periodically queries the node heartbeat, waits for the timing to overflow and determines whether an alarm is required.

2. According to claim 1, a reliable CANOpen communication software architecture design method based on an embedded controller is characterized in that: In step S5, if the controller does not receive the SDO reply command outside the response timeout threshold, the timeout retransmission mechanism is used to jump to step S3 to resend the SDO instruction; at this time, if the retransmission number threshold is exceeded, it is considered that the communication of the SDO instruction is abnormal, the controller performs fault processing and alarm, and notifies the user to perform maintenance.

3. According to claim 2, a reliable CANOpen communication software architecture design method based on an embedded controller is characterized in that: Step S5 is specifically as follows: S5-1, the controller determines whether it has received the SDO reply command: If the controller receives the SDO reply command, it continues to execute step S6; If the controller does not receive the SDO reply command, execute step S5-2; S5-2, the controller determines whether a response timeout occurs for the second time: If there is no response timeout, re-execute step S5-1; If the response times out, execute step S5-3; S5-3, the controller determines three times whether the number of retransmissions has been exceeded: If the number of retransmissions has not been exceeded, jump to step S3 to resend the SDO instruction; If the number of retransmissions exceeds the limit, the number of retransmissions is reset to zero, the controller state is set to SDO communication abnormality, the controller performs fault processing and alarms, and notifies the user to perform maintenance; after the maintenance is completed, step S0 is executed again.

4. According to claim 1, a reliable CANOpen communication software architecture design method based on an embedded controller is characterized in that: The specific steps for periodically querying node heartbeats are: SE-1, the controller continuously determines whether the timer overflows: If the count value does not reach the timing time, continue to execute steps S3 to S6; If the count value reaches the timing time, execute step SE-2; SE-2, the controller determines whether it has received the heartbeat message from the node: If the controller receives a heartbeat message, it resets the timer and starts counting again; If the controller does not receive the heartbeat message, the timer is reset, the controller status is set to node failure, the controller performs fault processing and alarm, and notifies the user to perform maintenance; After the maintenance is completed, execute step S0 again.

5. The method for designing a reliable CANOpen communication software architecture based on an embedded controller according to claim 3, characterized in that: In step S5, the controller receives the SDO reply command at the CAN receive interrupt.

6. The method for designing a reliable CANOpen communication software architecture based on an embedded controller according to claim 4, characterized in that: In step S1, the controller receives the heartbeat message of the node at the CAN receiving interrupt.

7. The method for designing a reliable CANOpen communication software architecture based on an embedded controller according to claim 1, characterized in that: Step S0 is specifically as follows: S0-1, the controller is used as the CANOpen master station, the motion control object is used as the CANOpen slave station, and the communication between the master station and the slave station is established; each slave station is regarded as a node; S0-2, reset the node; S0-3, configure the node to pre-operational mode; S0-4, set the node heartbeat time as needed; S0-5, configure the node to operational mode; S0-6, set the controller timing time, response timeout threshold and retransmission threshold as needed.

8. The method for designing a reliable CANOpen communication software architecture based on an embedded controller according to claim 1, characterized in that: Step S0 is specifically as follows: S0-1, the controller is used as the CANOpen master station, the motion control object is used as the CANOpen slave station, and the communication between the master station and the slave station is established; each slave station is regarded as a node; S0-2, set the controller timing time, response timeout threshold and retransmission threshold as needed; S0-3, reset the node; S0-4, configure the node to pre-operational mode; S0-5, set the node heartbeat time as needed; S0-6, configure the node to operational mode.

Images