A motor control system based on double mcu

Abstract

This invention relates to the field of motor control technology and discloses a motor control system based on dual MCUs. The system includes a first MCU, a second MCU, a motor, and a host computer. The first and second MCUs have identical configurations. Both the first and second MCUs send a master-slave confirmation command upon initial power-up, determining whether they are the master or slave MCU based on the reception of this command. The master MCU receives business instructions from the host computer and determines whether the instructions require collaborative execution. When collaborative execution is required, the master MCU sends the instructions to the slave MCU. The slave MCU controls its corresponding motor to execute the business instructions. This invention achieves autonomous master-slave role confirmation and collaborative business processing within a single code framework, reducing the workload of code development, version iteration, and upgrade maintenance, while improving control efficiency, reducing operational complexity, and enhancing system stability.

Description

Technical Field

[0001] This invention relates to the field of motor control technology, and more specifically to a motor control system based on dual MCUs. Background Technology

[0002] Multi-motor equipment typically uses MCUs (Microcontroller Units) for control. Taking a dual-MCU motor control system with one master and one slave as an example, the master MCU is responsible for distributing and processing operational commands, while the slave MCU is primarily responsible for motor motion management. However, due to the different codes and inconsistent control logic between the master and slave MCUs, additional joint debugging and adaptation are required for control coordination between them, resulting in long control response cycles. Furthermore, when upgrading the control strategy, both sets of code must be modified and verified separately, leading to low iteration efficiency and potential asynchrony issues between master and slave control. In summary, existing motor control systems suffer from low efficiency and high cost. Summary of the Invention

[0003] This invention provides a motor control system based on dual MCUs to solve the problems of low efficiency and high cost in existing motor control systems.

[0004] This invention provides a motor control system based on dual MCUs. The system includes a first MCU, a second MCU, a motor, and a host computer. The first MCU and the second MCU have the same configuration. Both the first MCU and the second MCU are used to send a master-slave confirmation command upon first power-on, and determine whether they are the master MCU or the slave MCU based on the reception of the master-slave confirmation command. The main MCU is used to receive service instructions from the host computer and determine whether the service instructions need to be executed collaboratively. The master MCU is also used to send service instructions to the slave MCU when service instructions need to be executed collaboratively; The MCU controls its own motor to execute business instructions and sends the instruction execution results back to the main MCU.

[0005] This invention significantly reduces the investment throughout the entire lifecycle, including development, testing, and upgrade iterations, by employing identical first and second MCUs. The two MCUs autonomously confirm their master-slave roles through the sending and receiving of master-slave confirmation commands, eliminating the need for manual configuration. After master-slave role confirmation, the master MCU receives the business command and determines whether collaborative execution is required. If collaborative execution is needed, it sends the business command to the slave MCU, enabling the slave MCU to control its motor to execute the command. This achieves autonomous role confirmation and collaborative business processing between master and slave MCUs within a single code framework, reducing the workload of code development, version iteration, and upgrade maintenance. It lowers control costs while improving control efficiency, reducing operational complexity, and enhancing system stability.

[0006] In one optional implementation, the first MCU is specifically configured to confirm itself as a slave MCU upon receiving a master-slave confirmation command, and send a first confirmation message to the second MCU, the first confirmation message indicating that the second MCU is the master MCU; or, The second MCU is specifically used to confirm itself as a slave MCU when it receives a master-slave confirmation instruction, and to send a second confirmation message to the first MCU, the second confirmation message indicating that the first MCU is the master MCU.

[0007] This invention autonomously confirms roles by checking whether the first MCU and the second MCU receive master-slave confirmation instructions, thus avoiding manual configuration errors and achieving real-time, dynamic confirmation of master-slave roles.

[0008] In one optional implementation, the main MCU is also used to control its corresponding motor to execute business instructions and store the instruction execution results when the business instructions do not need to be executed in coordination.

[0009] This invention allows the master MCU to independently control the motor when business instructions do not require collaborative execution, and stores the instruction execution results. This avoids unnecessary communication overhead between the master and slave MCUs, reduces control response delay, and improves control efficiency in scenarios where collaboration is not required.

[0010] In one alternative implementation, the master MCU and slave MCU are also used to store role identifiers, which are used to identify whether they are the master MCU or the slave MCU.

[0011] This invention stores role identifiers, which facilitates direct retrieval later, helps to shorten system startup time, and improves the power-on response efficiency of the control system.

[0012] In one alternative implementation, the first MCU and the second MCU are also used to read the role identifier during non-first power-on, and to confirm whether they are the master MCU or the slave MCU based on the role identifier.

[0013] This invention directly reads the role identifier during non-first power-on cycles and directly confirms whether it is the master MCU or slave MCU based on the role identifier. This avoids the communication waiting overhead caused by repeatedly executing the master-slave role confirmation mechanism, reduces system startup time, and enables the control system to enter the business processing state more quickly, thereby improving the control efficiency of power-on response.

[0014] In one optional implementation, the slave MCU is also used to report slave MCU status information to the master MCU; The main MCU is also used to receive status information from the slave MCU and report the status information of both the slave MCU and the main MCU to the host computer.

[0015] This invention simplifies the communication management complexity of the host computer, reduces communication link overhead, and improves the real-time performance and reliability of status monitoring by having the MCU report its status information to the main MCU, thereby utilizing only the main MCU to report status information to the host computer.

[0016] In one optional implementation, the first MCU and the second MCU are further configured to resend the master-slave confirmation instruction if no master-slave confirmation instruction is received within a preset waiting time, until the first MCU or the second MCU receives the master-slave confirmation instruction or the preset response time is reached.

[0017] This invention, by retransmitting the master-slave confirmation instruction when no master-slave confirmation instruction is received within a preset waiting time, combined with a timeout mechanism, can avoid confirmation failures caused by momentary communication interference or hardware startup delays, thus ensuring the reliable completion of the role confirmation mechanism.

[0018] In one optional implementation, the main MCU is specifically used to split a composite instruction into a first sub-instruction and a second sub-instruction when the business instruction is a composite instruction; Specifically, the main MCU is also used to control its corresponding motor to execute the first sub-instruction and send the second sub-instruction to the slave MCU; The MCU is specifically used to control its corresponding motor to execute the second sub-instruction, and then sends the execution result of the second sub-instruction to the main MCU; Specifically, the main MCU is also used to merge the execution result of the first sub-instruction with the execution result of the second sub-instruction to form the execution result of the compound instruction.

[0019] This invention simplifies the control logic of the host computer by splitting, distributing, and merging composite instructions, eliminating the need for the host computer to issue multiple instructions separately, reducing the number of communication interactions, and improving the efficiency of multi-motor collaborative control.

[0020] In one optional implementation, when there are multiple service instructions, the main MCU is further used to sort the multiple service instructions according to instruction priority; The main MCU is also used to determine whether each service instruction needs to be executed collaboratively according to the sorting result, and to send the service instruction to the slave MCU when the service instruction needs to be executed collaboratively. Specifically, the MCU is also used to interrupt the currently executing business instruction when the priority of the business instruction is higher than the priority of the currently executing business instruction, control its corresponding motor to execute the higher priority business instruction, and resume the execution of the interrupted business instruction after the execution is completed.

[0021] This invention ensures that high-priority control tasks receive timely responses by executing business instructions according to instruction priority, avoiding delays in critical business instructions due to blocking of low-priority tasks, thereby improving the real-time performance and response efficiency of the control system.

[0022] In one alternative implementation, when the first MCU or the second MCU is replaced, the first MCU and the second MCU are also used to redetermine themselves as the master MCU or the slave MCU.

[0023] This invention automatically reconfirms the master-slave roles without manual configuration when the MCU is replaced, reducing the risk of system anomalies caused by incorrect role configuration and improving the system adaptability and reliability in hardware interchange scenarios. Attached Figure Description

[0024] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram of a motor control system based on dual MCUs according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the configuration of a motor according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the business processing according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating role confirmation according to an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0028] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0029] Figure 1 This is a schematic diagram of a motor control system based on a dual MCU according to an embodiment of the present invention, as shown below. Figure 1 As shown, the system includes a first MCU, a second MCU, a motor, and a host computer. The first MCU and the second MCU have the same configuration. Both the first MCU and the second MCU are used to send a master-slave confirmation command upon initial power-on, and determine whether they are the master MCU or the slave MCU based on the reception of the master-slave confirmation command. The master MCU is used to receive business commands issued by the host computer and determine whether the business commands need to be executed collaboratively. The master MCU is also used to send business commands to the slave MCU when collaborative execution is required. The slave MCU is used to control its corresponding motor to execute the business commands and send the command execution results back to the master MCU.

[0030] Specifically, traditional motor control systems employ a dual-MCU architecture with one master and one slave. The master and slave MCUs differ in function, chip type, development platform, and program code, necessitating targeted development and integration for both. This increases complexity in code management and iteration, as well as version upgrades and management, significantly raising development costs and time investment. Furthermore, it results in long control response cycles and low efficiency in control strategy iteration. Therefore, this invention uses two MCUs with identical configurations. Specifically, the chip selection and pinout of the two MCUs are consistent, enhancing circuit design reusability. Simultaneously, the code for both MCUs is completely identical, requiring only one set of source code to be maintained, and subsequent version management is more efficient. Thus, reuse can be achieved throughout the entire process, from circuit design and code development to version management, significantly reducing investment throughout the development, testing, and upgrade iterations, thereby improving system stability and control efficiency.

[0031] Since the two MCUs are completely identical, a role confirmation mechanism is needed to distinguish between master and slave. Upon initial power-up, both MCUs send a master-slave confirmation command, and the master-slave role is automatically confirmed based on the reception of this command, without the need for manual configuration.

[0032] Figure 2 This is a schematic diagram of the configuration of a motor according to an embodiment of the present invention, as shown below. Figure 2 As shown, each motor carries an ID number and corresponds to an independent drive control circuit. Two MCUs are assigned corresponding motors for targeted control; for example, the master MCU controls motors 1 and 2, and the slave MCU controls motors 3 and 4. After the master and slave roles are confirmed, the master and slave MCUs begin business processing. The master MCU receives and parses the business instructions from the host computer, determining which motor should execute the instruction based on the ID number carried in the instruction. If the motor is configured to be controlled by the slave MCU, the business instruction needs to be executed collaboratively by the slave MCU, and the master MCU will pass the business instruction through to the slave MCU. Optionally, since the master and slave MCUs run the same code and use a pass-through mechanism, the slave MCU does not need to perform secondary parsing of the business instructions and can directly execute the instructions passed through by the master MCU, thus shortening the response delay from instruction reception to execution. The slave MCU controls the motor corresponding to the business instruction to execute the instruction and returns the execution result to the master MCU. The above process realizes autonomous role confirmation and collaborative business processing of master and slave MCUs within a single code framework, reducing the workload of code development, version iteration, and upgrade maintenance, and improving control efficiency while reducing control costs.

[0033] In some optional implementations, the first MCU is specifically used to confirm itself as a slave MCU when it receives a master-slave confirmation instruction, and send a first confirmation message to the second MCU, the first confirmation message indicating that the second MCU is a master MCU; or, the second MCU is specifically used to confirm itself as a slave MCU when it receives a master-slave confirmation instruction, and send a second confirmation message to the first MCU, the second confirmation message indicating that the first MCU is a master MCU.

[0034] Specifically, both the first and second MCUs send master-slave confirmation commands via USART3. In terms of hardware connection, only the USART3 receiver of the slave MCU is connected to the USART3 transmitter of the master MCU, while the USART3 transmitter of the slave MCU is left unconnected. Therefore, only the slave MCU can receive the master-slave confirmation command. Based on this, if the first MCU receives the master-slave confirmation command, it indicates that the first MCU is the slave MCU. At this time, it sends a first confirmation message to the second MCU via UART4 to confirm that it is the master MCU. Similarly, if the second MCU receives the master-slave confirmation command, it indicates that the second MCU is the slave MCU. At this time, it sends a second confirmation message to the first MCU via UART4 to confirm that it is the master MCU. Through this mechanism, two identical MCUs can autonomously complete the master-slave role confirmation without manual configuration, avoiding manual configuration errors and realizing real-time, dynamic confirmation of the master-slave role.

[0035] In some optional implementations, the main MCU is also used to control its corresponding motor to execute business instructions and store the instruction execution results when the business instructions do not need to be executed in coordination.

[0036] Specifically, if the service instruction does not include the ID number of the motor controlled by the slave MCU, it indicates that the service instruction does not require collaborative execution. In this case, the master MCU can directly control the motor corresponding to the service instruction to execute the instruction. The master MCU stores the instruction execution result locally for later reporting to the host computer or for fault tracing. This method avoids unnecessary communication overhead between the master and slave MCUs, reduces control response delay, and thus improves control efficiency in scenarios where collaboration is not required.

[0037] Figure 3 This is a schematic diagram of the business processing according to an embodiment of the present invention, such as... Figure 3 As shown, the master MCU receives and parses the service instruction, determining whether it requires coordinated execution. If coordinated execution is required, the master MCU sends the instruction to the slave MCU. The slave MCU receives the instruction, controls the corresponding motor to execute it, and sends the execution result back to the master MCU. If coordinated execution is not required, the master MCU controls the corresponding motor to execute the instruction and obtains the execution result.

[0038] In some alternative implementations, the master MCU and slave MCU are also used to store role identifiers, which are used to identify whether they are the master MCU or the slave MCU.

[0039] Specifically, role identifiers are used to distinguish the master and slave roles of the first and second MCUs in the control system. The role identifier corresponding to the master MCU is the master MCU identifier, and the role identifier corresponding to the slave MCU is the slave MCU identifier. After the master-slave role confirmation is completed, the first and second MCUs write their own role identifiers into their internal FLASH memory based on the confirmation result. The FLASH memory is non-volatile, and the identifier information will not be lost even after the system is powered off. It should be noted that the role identifiers are not present in the FLASH memory during the initial power-on. Through the above storage operation, when the system is powered on again subsequently, the master and slave MCUs can directly read the role identifiers from the FLASH memory without re-executing the role confirmation mechanism, thereby shortening the system startup time and improving the power-on response efficiency of the control system.

[0040] In some alternative implementations, the first MCU and the second MCU are also used to read the role identifier during non-first power-on and to identify themselves as the master MCU or slave MCU based on the role identifier.

[0041] Specifically, during non-initial power-on cycles, the first and second MCUs directly read the stored role identifiers from their respective FLASH memories to determine whether they are the master or slave MCU. Since the role identifiers are already fixed during the initial power-on, there is no need to send master-slave confirmation commands again via USART3, avoiding the communication waiting overhead caused by repeatedly executing the role confirmation mechanism, reducing system startup time, and enabling the control system to enter the business processing state more quickly, thus improving the control efficiency of power-on response.

[0042] In some optional implementations, the slave MCU is also used to report slave MCU status information to the master MCU; the master MCU is also used to receive slave MCU status information and report slave MCU status information and master MCU status information to the host computer.

[0043] Specifically, the status information includes the MCU's operating status, operating parameters, fault information, and real-time operating data of the controlled motor. The slave MCU periodically or event-triggeredly collects its own status information during operation and actively reports it to the master MCU through the communication interface between the master and slave MCUs. The master MCU receives and temporarily stores the status information reported by the slave MCU, and simultaneously collects its own status information. After summarizing and integrating the two, it reports them to the host computer. Through this mechanism, the host computer does not need to communicate separately with the master and slave MCUs; it only needs to interact with the master MCU to obtain complete status information of the entire control system. This simplifies the communication management complexity of the host computer, reduces communication link overhead, and improves the real-time performance and reliability of status monitoring.

[0044] In some optional implementations, the first MCU and the second MCU are also used to resend the master-slave confirmation instruction if no master-slave confirmation instruction is received within a preset waiting time, until the first MCU or the second MCU receives the master-slave confirmation instruction or the preset response time is reached.

[0045] Specifically, the preset waiting time refers to the maximum time that the first or second MCU will wait to receive the master-slave confirmation command after sending it. The first and second MCUs each send the master-slave confirmation command and start timing. If neither the first nor the second MCU receives the master-slave confirmation command within the preset waiting time, the current communication link is considered unresponsive. At this point, the first and second MCUs resend the master-slave confirmation command, and timing continues. This retransmission process is repeated until one of the following two conditions is met: first, the first or second MCU successfully receives the master-slave confirmation command; second, the accumulated time reaches the preset response time. At this point, the system determines that the response has timed out, indicating that neither MCU can currently receive any confirmation command. Through this retransmission and timeout mechanism, confirmation failures caused by momentary communication interference or hardware startup delays can be avoided, ensuring the reliable completion of the role confirmation mechanism.

[0046] Figure 4 This is a schematic diagram of role confirmation according to an embodiment of the present invention, such as... Figure 4As shown, the first MCU and the second MCU read their respective FLASH memories. If a role identifier exists, it indicates that this is not the first power-on, and no further role confirmation is needed; subsequent business processing can proceed according to the role identifier. If no role identifier exists, it indicates that this is the first power-on, and both the first and second MCUs send a master-slave confirmation command. If it is not received within a preset waiting time, it is resent until either the first or second MCU receives it, or the preset response time is reached. Due to the hardware connection settings, only the slave MCU can receive this command; therefore, the MCU that receives the master-slave confirmation command is identified as the slave MCU. If the first MCU is the slave MCU, it sends a first confirmation message to the second MCU; if the second MCU is the slave MCU, it sends a second confirmation message to the first MCU. The MCU that receives the confirmation message can then identify itself as the master MCU. The master and slave MCUs store the role identifier in their respective FLASH memories.

[0047] In some optional implementations, the master MCU is specifically used to split a composite instruction into a first sub-instruction and a second sub-instruction when the business instruction is a composite instruction; the master MCU is also specifically used to control its corresponding motor to execute the first sub-instruction and send the second sub-instruction to the slave MCU; the slave MCU is specifically used to control its corresponding motor to execute the second sub-instruction and send the instruction execution result of the second sub-instruction to the master MCU; the master MCU is also specifically used to merge the instruction execution result of the first sub-instruction and the instruction execution result of the second sub-instruction to form the instruction execution result of the composite instruction.

[0048] Specifically, a composite instruction is a business instruction issued by the host computer that requires the coordinated operation of multiple motors. It carries the ID numbers of both the motors controlled by the main MCU and the motors controlled by the slave MCU. Upon receiving the composite instruction, the main MCU parses it, splitting it into a first sub-instruction and a second sub-instruction based on the motor ID numbers. The first sub-instruction carries only the ID number of the motor controlled by the main MCU, while the second sub-instruction carries only the ID number of the motor controlled by the slave MCU. After splitting, the main MCU controls the motor corresponding to the first sub-instruction to execute the instruction, while simultaneously transmitting the second sub-instruction to the slave MCU. Upon receiving the second sub-instruction, the slave MCU controls the motor corresponding to the second sub-instruction to execute the instruction and returns the execution result to the main MCU. After receiving the execution result from the slave MCU, the main MCU merges it with the execution result of the first sub-instruction to form the complete execution result of the composite instruction, which is then reported to the host computer. Through the above-mentioned splitting, distribution, and merging mechanism, the master and slave MCUs can collaboratively complete complex business instructions involving multiple motors without the need for the host computer to issue multiple instructions separately. This simplifies the control logic of the host computer, reduces the number of communication interactions, and improves the efficiency of multi-motor collaborative control.

[0049] In some optional implementations, when there are multiple service instructions, the master MCU is further configured to sort the multiple service instructions according to their instruction priorities; the master MCU is further configured to determine, according to the sorting results, whether each service instruction needs to be executed collaboratively, and when the service instructions need to be executed collaboratively, send the service instructions to the slave MCU; the slave MCU is further configured to interrupt the currently executing service instruction when the priority of the service instruction is higher than the priority of the currently executing service instruction, control its corresponding motor to execute the service instruction with higher priority, and resume the execution of the interrupted service instruction after the execution is completed.

[0050] Specifically, if the host computer issues multiple service instructions, the master MCU can sort these instructions according to a preset priority rule, with instructions listed earlier in the order having higher priority. After sorting, the master MCU processes each service instruction sequentially from highest to lowest priority, determining whether the instruction requires collaborative execution from the slave MCU. If collaborative execution is required, the master MCU sends the service instruction to the slave MCU. Upon receiving the service instruction, the slave MCU compares its priority with the priority of the currently executing service instruction. If the newly received service instruction has a higher priority, the slave MCU interrupts the currently executing service instruction and controls its corresponding motor to execute the higher-priority service instruction. After the higher-priority instruction is completed, the slave MCU restores the previously interrupted execution context and continues executing the interrupted service instruction. Through this process, high-priority control tasks are ensured to receive timely responses, avoiding delays in critical control instructions due to low-priority task blocking, thereby improving the real-time performance and response efficiency of the control system.

[0051] In some alternative implementations, when the first MCU or the second MCU is replaced, the first MCU and the second MCU are also used to redetermine themselves as the master MCU or the slave MCU.

[0052] Specifically, in practical applications, such as laboratory testing, product certification, or after-sales maintenance, if an MCU fails, it can be replaced by an MCU from another board to form a usable board. After the MCU is replaced, the replacement MCU does not rely on the original master-slave configuration of its source board, nor is it affected by the role identifier before the replacement. Instead, it re-executes the master-slave confirmation process after power-on, dynamically determining its own role based on the current command reception. This effectively avoids master-slave role conflicts caused by MCU hardware replacement, reduces the risk of system anomalies caused by incorrect role configuration, and significantly improves the system's adaptability and maintainability in hardware interchange scenarios.

[0053] The dual-MCU-based motor control system provided in this embodiment significantly reduces the investment throughout the entire lifecycle, including development, testing, and upgrade iterations, by using identical first and second MCUs. The two MCUs autonomously confirm their master-slave roles through the sending and receiving of master-slave confirmation commands, eliminating the need for manual configuration. After master-slave role confirmation, the master MCU receives the business command and determines whether collaborative execution is required. If collaborative execution is needed, it sends the business command to the slave MCU, enabling the slave MCU to control its motor to execute the command. This achieves autonomous role confirmation and collaborative business processing between the master and slave MCUs within a single code framework, reducing the workload of code development, version iteration, and upgrade maintenance. It lowers control costs while improving control efficiency, reducing operational complexity, and enhancing system stability.

[0054] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A motor control system based on dual MCUs, characterized in that, The system includes a first MCU, a second MCU, a motor, and a host computer, wherein the first MCU and the second MCU have the same configuration; Both the first MCU and the second MCU are used to send a master-slave confirmation command upon first power-on, and determine whether they are the master MCU or the slave MCU based on the reception of the master-slave confirmation command; The main MCU is used to receive service instructions issued by the host computer and determine whether the service instructions need to be executed collaboratively. The master MCU is also used to send the service instruction to the slave MCU when the service instruction needs to be executed collaboratively; The slave MCU is used to control its corresponding motor to execute the business instructions and send the instruction execution results to the master MCU.

2. The system according to claim 1, characterized in that, Specifically, the first MCU is used to confirm itself as a slave MCU upon receiving the master-slave confirmation instruction, and send first confirmation information to the second MCU, wherein the first confirmation information indicates that the second MCU is the master MCU; or, The second MCU is specifically used to confirm itself as a slave MCU when it receives the master-slave confirmation instruction, and to send a second confirmation message to the first MCU, wherein the second confirmation message indicates that the first MCU is the master MCU.

3. The system according to claim 1, characterized in that, The main MCU is also used to control its corresponding motor to execute the business instruction when the business instruction does not need to be executed in coordination, and to store the instruction execution result.

4. The system according to claim 1, characterized in that, The master MCU and the slave MCU are also used to store role identifiers, which are used to identify whether they are the master MCU or the slave MCU.

5. The system according to claim 4, characterized in that, The first MCU and the second MCU are also used to read the role identifier when powering on for the first time, and to confirm whether they are the master MCU or the slave MCU based on the role identifier.

6. The system according to claim 1, characterized in that, The slave MCU is also used to report slave MCU status information to the master MCU; The master MCU is also used to receive the status information of the slave MCU and report the status information of the slave MCU and the master MCU to the host computer.

7. The system according to claim 1, characterized in that, The first MCU and the second MCU are also used to resend the master-slave confirmation instruction if they do not receive the master-slave confirmation instruction within a preset waiting time, until the first MCU or the second MCU receives the master-slave confirmation instruction or the preset response time is reached.

8. The system according to claim 1, characterized in that, The main MCU is specifically used to split the business instruction into a first sub-instruction and a second sub-instruction when the business instruction is a composite instruction; Specifically, the main MCU is also used to control its corresponding motor to execute the first sub-instruction and send the second sub-instruction to the slave MCU; The slave MCU is specifically used to control its corresponding motor to execute the second sub-instruction and send the instruction execution result of the second sub-instruction to the master MCU; Specifically, the main MCU is further configured to merge the instruction execution result of the first sub-instruction with the instruction execution result of the second sub-instruction to form the instruction execution result of the composite instruction.

9. The system according to claim 1, characterized in that, When there are multiple service instructions, the main MCU is further configured to sort the multiple service instructions according to instruction priority; The main MCU is further configured to determine, according to the sorting result, whether each service instruction needs to be executed collaboratively, and when the service instruction needs to be executed collaboratively, send the service instruction to the slave MCU. Specifically, the MCU is further configured to interrupt the currently executing business instruction when the priority of the business instruction is higher than the priority of the currently executing business instruction, control its corresponding motor to execute the higher-priority business instruction, and resume the execution of the interrupted business instruction after the execution is completed.

10. The system according to claim 1, characterized in that, When the first MCU or the second MCU is replaced, the first MCU and the second MCU are also used to redetermine themselves as the master MCU or the slave MCU.

Images