Canopen communication method and device applied to motor driver and motor driver

Abstract

The application relates to a CANopen communication method and device applied to a motor driver and the motor driver, and the method comprises the following steps: receiving an original SDO request sent by an external application through a CANopen communication protocol, wherein the original SDO request is a batch SDO request generated based on a batch SDO control mechanism; after preprocessing the original SDO request, the original SDO request is cached into an SDO request queue; SDO requests in the SDO request queue are extracted one by one, corresponding processing is conducted, control instructions and response messages are generated, and the process is continued until the SDO request queue is empty. Compared with the prior art, the application has the advantages of improving efficiency and avoiding SDO request loss.

Description

Technical Field

[0001] This invention relates to a motor driver, and more particularly to a CANopen communication method, apparatus, and motor driver for use in a motor driver. Background Technology

[0002] With the rapid development of industries such as logistics, the market demand for AGV (Automated Guided Vehicle) equipment continues to rise. The CANopen protocol, thanks to its relatively fast communication speed and flexible protocol expansion, is gaining increasing popularity in logistics and related fields. At the communication level, CANopen SDO mailbox communication is frequently used in various applications.

[0003] CANopen SDO is a client-server based communication protocol implemented through a request-response mechanism. Because the server (generally referring to a motor driver with a CANopen interface) can only process the next client request after responding to the previous one (generally referring to a host controller), this communication method requires certain timing constraints. In some applications, such as AGV (Automated Guided Vehicle) systems, to reduce the requirements or costs of the host controller, special control requirements arise where clients may continuously send multiple SDO request messages. If the server's processing capacity is limited, requests can easily be lost, preventing responses. Lost client requests can cause system instability and reduce the robustness of the entire control system. Therefore, optimization of the CANopen driver communication protocol is necessary to meet these application requirements.

[0004] Existing traditional CANopen motor drivers have the following main application drawbacks:

[0005] 1) It cannot meet the application requirements of high-speed, batch SDO requests, and is prone to causing request or response loss;

[0006] 2) If a traditional response system is used, the host computer is required to meet the necessary timing relationships, which increases the cost. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of the prior art and provide a CANopen communication method, device, and motor driver for motor drivers that improves efficiency and avoids SDO request loss.

[0008] The objective of this invention can be achieved through the following technical solutions:

[0009] On one hand, the present invention provides a CANopen communication method for motor drivers, comprising the following steps:

[0010] Receive raw SDO requests sent by external applications via the CANopen communication protocol. These raw SDO requests are batch SDO requests generated based on the batch SDO control mechanism.

[0011] After preprocessing the original SDO request, it is cached in the SDO request queue;

[0012] SDO requests are extracted from the SDO request queue one by one, and corresponding processing is performed to generate control commands and response messages until the SDO request queue is empty.

[0013] Furthermore, the original SDO request is generated by the host controller, and the response message is applied to the host controller.

[0014] Furthermore, the preprocessing includes organizing the batch SDO requests.

[0015] On the other hand, the present invention provides a CANopen communication device for a motor driver, comprising:

[0016] The CAN peripheral interface module is used to send raw SDO requests via the CANopen communication protocol. These raw SDO requests are generated based on the batch SDO control mechanism.

[0017] The SDO receive interrupt service module is used to preprocess the original SDO request and then cache it in the SDO request queue.

[0018] The SDO processing state machine module is used to extract SDO requests sequentially from the SDO request queue, process them accordingly, and generate control commands and response messages.

[0019] Furthermore, the original SDO request is generated by the host controller, and the response message is transmitted to the host controller via the CAN peripheral interface module.

[0020] Furthermore, the SDO request queue is stored in a RAM space inside the CANopen protocol stack.

[0021] Furthermore, the preprocessing includes organizing the batch SDO requests.

[0022] Furthermore, the control commands are transmitted to the controlled servo motor via shared memory.

[0023] Thirdly, the present invention provides a CANopen motor driver, including the CANopen communication device as described above.

[0024] Furthermore, the CANopen communication device is located within the Arm core, and the motor driver also includes a DSP core for implementing motor control. The Arm core and the DSP core interact with each other through a shared memory channel.

[0025] Compared with the prior art, the present invention has the following beneficial effects:

[0026] 1) This invention upgrades the original implementation mechanism of CANopen SDO by adding a RAM receive buffer queue to cache request messages that cannot be processed in time. The next request message is processed sequentially after the SDO processing state machine finishes processing the previous request. This fundamentally avoids the problem of SDO request loss.

[0027] 2) This invention significantly shortens the processing time of SDO receive interrupts, improves the real-time processing capability of the client-server model, optimizes the system software architecture, and enhances the robustness and stability of the driver software.

[0028] 3) This invention provides a motor driver with an optimized CANopen communication protocol stack. This motor driver can handle batch SDO requests, avoid SDO request loss or congestion, greatly reduce the implementation cost of the upper controller and driver, greatly improve the situation of SDO response loss in the case of batch SDO requests, effectively improve the functional robustness and system stability of the customer's CANopen application system, and improve the system response efficiency. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the CANopen client-server communication model.

[0030] Figure 2 This is a schematic diagram of the CANopen SDO batch request of the present invention;

[0031] Figure 3 This is a schematic diagram of the CANopen SDO communication device of the present invention;

[0032] Figure 4 This is a schematic diagram of the CANopen motor driver of the present invention. Detailed Implementation

[0033] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0034] Motor control systems typically include a host controller and a driver, which communicate via CANopen. The driver comprises power circuitry and control circuitry; the main control chip (MCU) in the control circuitry implements motor control and CANopen communication. In traditional applications, the host controller sends SDO requests according to a specific timing sequence, the driver responds, and after the response is complete, it processes the next request from the host controller. In this approach, the host controller must wait to receive response messages from the driver to prevent message frame loss, thus reducing the real-time response performance of the communication. This invention addresses these problems by providing a new CANopen communication module that allows the host controller to send SDO requests to the driver in batches, which then processes these batches of SDO requests, improving efficiency and reducing costs.

[0035] like Figure 1 As shown, SDO communication follows a client-server model, with the client application controller acting as the SDO client device and the CANopen driver as the server device. The client sends an SDO request, and the server receives, processes, and responds to the request.

[0036] like Figure 2 The diagram illustrates CANopen SDO batch requests. In this invention, the client controller uses a batch SDO control mechanism to implement field application functions. This type of control application requires the continuous sending of multiple SDO request messages within a short period. However, traditional SDO processing mechanisms generally adhere to a strict request-response timing requirement; that is, the host computer sends the next request message only after receiving the previous response, making this approach unsuitable. This invention allocates dedicated RAM space within the driver to implement an SDO request queue. Upon receipt, SDO request messages are first buffered in the request queue, waiting for the SDO processing state machine to complete processing the previous SDO request and respond to the host computer before proceeding with subsequent processing. This approach effectively avoids the loss of SDO request messages.

[0037] Example 1

[0038] This embodiment provides a CANopen communication method for motor drivers, including the following steps: receiving raw SDO requests sent by an external application via the CANopen communication protocol, wherein the raw SDO requests are batch SDO requests generated based on a batch SDO control mechanism; preprocessing the raw SDO requests and caching them in an SDO request queue; sequentially retrieving SDO requests from the SDO request queue and processing them accordingly to generate control commands and response messages, until the SDO request queue is empty. The raw SDO requests are generated by the host controller, and the response messages act on the host controller. Preprocessing includes organizing the batch SDO requests.

[0039] Example 2

[0040] like Figure 3 As shown, this embodiment provides a CANopen communication device for a motor driver, including: a CAN peripheral interface module 1, used to send raw SDO requests via the CANopen communication protocol, wherein the raw SDO requests are batch SDO requests generated based on a batch SDO control mechanism; an SDO receive interrupt service module 2, used to preprocess the raw SDO requests and cache them in an SDO request queue 3; and an SDO processing state machine module 4, used to extract SDO requests sequentially from the SDO request queue 3, perform corresponding processing, and generate control commands and response messages. The control commands are transmitted to the controlled servo motor via shared memory, and the response messages are sent to the CAN bus network via the CAN peripheral interface module 1 and fed back to the host controller.

[0041] Specifically, the SDO request queue is stored in a RAM space inside the CANopen protocol stack.

[0042] Example 3

[0043] This embodiment provides a CANopen motor driver, including the CANopen communication device as described in Embodiment 2. This driver optimizes the CANopen communication protocol stack processing channel and allocates dedicated SDO RAM storage space to implement a user request queue to cache batch SDO requests from clients, preventing SDO request loss and congestion.

[0044] In a specific implementation, the CANopen communication device is located within the Arm core, and the motor driver also includes a DSP core for implementing motor control. The Arm core and the DSP core interact with each other through a shared memory channel.

[0045] The CANopen motor driver consists of a power circuit and a control circuit. The power circuit outputs the current and voltage for motor control, while the control circuit implements the motor control algorithm and peripheral modules. For example... Figure 4 As shown, the control circuit includes a CANopen communication device and a motor control module. The CANopen communication device includes a CAN peripheral interface module, which is responsible for receiving and sending CANopen message frames. The other parts of the CANopen communication device are implemented based on the CANopen protocol stack, which runs on an Arm core. The protocol stack has been functionally optimized and allocates a certain amount of RAM space specifically for storing batch SDO request messages from the host controller. The motor control module is implemented based on a DSP core, which is responsible for handling the motor control part. The Arm core and the DSP core communicate through an IPC shared memory mechanism, and an internal bus is used to improve message processing speed.

[0046] This motor driver, based on the existing CANopen protocol stack software, significantly improves the situation of SDO response loss in the case of batch SDO requests by adding an SDO request queue. This effectively enhances the functional robustness and system stability of the customer's CANopen application system and improves system response efficiency. Its basic functional flow is as follows:

[0047] 1) The CAN peripheral interface module is responsible for receiving and sending CANopen SDO messages and triggering message interrupt signals;

[0048] 2) The interrupt service routine processes the received raw SDO request, organizes the request data, and sends the data to the SDO request queue inside the protocol stack.

[0049] 3) The SDO request queue buffers the received SDO request messages;

[0050] 4) The SDO processing state machine is responsible for retrieving request messages from the SDO request queue one by one, processing the request messages, and sending the processed response messages to the CAN peripheral module.

[0051] 5) The CAN peripheral module sends the received SDO response message to the CAN bus network;

[0052] 6) The CAN protocol stack realizes data interaction with the DSP motor control module through a shared memory channel. The DSP core is responsible for processing motor control and executing motor operation instructions.

[0053] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A CANopen communication method applied to a motor driver, characterized in that, Includes the following steps: Receive raw SDO requests sent by external applications via the CANopen communication protocol. These raw SDO requests are batch SDO requests generated based on the batch SDO control mechanism. After the original SDO request is preprocessed by the SDO receive interrupt service module, it is cached in the SDO request queue, which is stored in a RAM space inside the CANopen protocol stack. The SDO processing state machine module sequentially extracts SDO requests from the SDO request queue, processes them accordingly, and generates control commands and response messages until the SDO request queue is empty. The control commands are then transmitted to the controlled servo motor via shared memory.

2. The CANopen communication method for motor drivers according to claim 1, characterized in that, The original SDO request is generated by the host controller, and the response message acts on the host controller.

3. The CANopen communication method for motor drivers according to claim 1, characterized in that, The preprocessing includes organizing the batch SDO requests.

4. A CANopen communication device for use in motor drivers, characterized in that, include: The CAN peripheral interface module is used to send raw SDO requests via the CANopen communication protocol. These raw SDO requests are generated based on the batch SDO control mechanism. The SDO receive interrupt service module is used to preprocess the original SDO request and then cache it in the SDO request queue, which is stored in a RAM space inside the CANopen protocol stack. The SDO processing state machine module is used to extract SDO requests one by one from the SDO request queue, process them accordingly, and generate control instructions and response messages. The control instructions are transmitted to the controlled servo motor through shared memory.

5. The CANopen communication device for a motor driver according to claim 4, characterized in that, The original SDO request is generated by the host controller, and the response message is applied to the host controller through the CAN peripheral interface module.

6. The CANopen communication device for a motor driver according to claim 4, characterized in that, The preprocessing includes organizing the batch SDO requests.

7. A CANopen motor driver, characterized in that, Includes the CANopen communication device as described in any one of claims 4-6.

8. The CANopen motor driver according to claim 7, characterized in that, The CANopen communication device is located within the Arm core, and the motor driver also includes a DSP core for implementing motor control. The Arm core and the DSP core interact with each other through a shared memory channel.

Images