Stepping motor driving method, device, system and electronic equipment based on ethercat bus and storage medium

Abstract

This disclosure relates to the field of stepper motor control technology, specifically to a stepper motor driving method, apparatus, system, electronic device, and storage medium based on an EtherCAT bus. The system includes an AI-powered computer and stepper motor terminal modules connected via an EtherCAT bus. The AI-powered computer includes a CODESYS controller and a stepper motor drive module. The stepper motor drive module responds to system configuration commands sent by the controller, instantiating axis objects for each terminal module, binding bus connectors, and establishing a mapping between bus PDO addresses and local PDO addresses. When responding to positioning motion commands, it reads actual parameters from the target axis object within the same control cycle, uploads them to the controller to calculate target parameters, writes the target parameters to the output address, and sends them down the bus to the corresponding terminal module for position control. This solution realizes stepper motor drive control under the CODESYS platform, reducing development difficulty and system cost.

Description

Technical Field

[0001] This disclosure relates to the field of stepper motor control technology, specifically to a stepper motor driving method, device, system, electronic device, and storage medium based on the EtherCAT bus. Background Technology

[0002] In the field of industrial automation, as industrial automation evolves towards openness, modularity, and intelligence, control architectures built on standardized software platforms and real-time communication networks have become the core of the industry. In this process, the CODESYS software development platform, adhering to the IEC 61131-3 international standard and the PLCopen specification, has become a common foundation for many equipment manufacturers to build control systems due to its open hardware abstraction. This platform significantly improves system portability and maintainability by decoupling control logic from the underlying hardware. However, while CODESYS motion control systems provide comprehensive bus interfaces and function libraries for various servo drives, they lack a standardized, high-performance drive layer for stepper motors. This deficiency often forces users to choose more expensive servo solutions or invest significant resources in developing their own underlying communication and control logic when developing stepper control applications, increasing project complexity and risk.

[0003] Furthermore, real-time industrial Ethernet technology, especially EtherCAT, has become the mainstream standard for connecting distributed drive units due to its deterministic communication mechanism and nanosecond-level clock synchronization capability. Motion control systems based on the EtherCAT bus are gradually replacing traditional pulse direction control methods and are widely used in multi-axis coordinated motion scenarios due to their advantages such as high synchronization, high real-time performance, and simple wiring.

[0004] However, for applications that heavily utilize stepper motors, such as multi-axis EtherCAT stepper platforms (including precision placement, dispensing equipment, and small handling systems), low-cost servo replacement of laboratory or teaching instruments, and smooth upgrades of old equipment pulse direction drivers to bus control, integrating stepper motors with the CODESYS platform still faces significant challenges. For example, while common EtherCAT stepper motor terminal modules (such as the Beckhoff EL7037 from Beckhoff Automation GmbH) have good hardware performance, they lack a standardized driver interface directly compatible with CODESYS. To achieve a basic and reliable multi-axis stepper motor bus control system, users often need to delve into the EtherCAT slave protocol and manually configure complex PDO mappings and state machine management, leading to long development cycles, high technical barriers, and potential problems such as unstable communication, asynchronous motion, or runaway risks. This severely restricts the rapid deployment of stepper motors in low-cost, multi-axis bus control systems and the efficiency of upgrading old equipment. Therefore, there is an urgent need for a driver adaptation solution that can seamlessly connect CODESYS and EtherCAT stepper terminal modules to reduce development difficulty and system cost, improve device interoperability and field maintenance efficiency, and accelerate its popularization and upgrading in the above application scenarios. Summary of the Invention

[0005] To address the problems in the related technologies, this disclosure provides a stepper motor driving method, apparatus, system, electronic device, and storage medium based on the EtherCAT bus.

[0006] In a first aspect, this disclosure provides a stepper motor drive system based on an EtherCAT bus. The stepper motor drive system includes: an AI computer and one or more stepper motor terminal modules. The AI ​​computer includes a CODESYS controller and a stepper motor drive module. The AI ​​computer is connected to each stepper motor terminal module via an EtherCAT bus. The stepper motor terminal module is used to control the corresponding stepper motor and is connected to the stepper motor through its own set motor terminals. Wherein:

[0007] The CODESYS controller is configured to: generate stepper motor drive instructions and send the stepper motor drive instructions to the stepper motor drive module. The stepper motor drive instructions include: system configuration instructions and positioning motion instructions.

[0008] The stepper motor drive module is configured as follows:

[0009] In response to the system configuration command, instantiate an axis object corresponding to each stepper motor terminal module; bind the EtherCAT bus connector to each axis object; set the operating mode of each axis object to periodic synchronous position mode; for any axis object, based on the EtherCAT bus connector, map the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to the axis object to the local PDO input address and local PDO output address of the axis object respectively;

[0010] In response to the positioning motion command, a target axis object corresponding to the positioning motion command is acquired. Within any control cycle, the actual parameters of the corresponding stepper motor are obtained from the local PDO input address of the target axis object, and the actual parameters are uploaded to the CODESYS controller so that the CODESYS controller can obtain the corresponding target parameters based on the actual parameters. Within any control cycle, the target parameters are acquired; the target parameters are written to the local PDO output address of the target axis object so as to be sent to the corresponding stepper motor terminal module through the EtherCAT bus to realize the position control of the stepper motor.

[0011] Secondly, this disclosure provides a stepper motor driving method based on the EtherCAT bus, applied to an industrial intelligent machine. The industrial intelligent machine includes a CODESYS controller and is connected to one or more stepper motor terminal modules via the EtherCAT bus. The stepper motor terminal modules are used to control corresponding stepper motors and are connected to the corresponding stepper motors through their own set motor terminals. The stepper motor driving method includes:

[0012] Receive stepper motor drive commands sent by the CODESYS controller, the stepper motor drive commands including: system configuration commands and positioning motion commands;

[0013] In response to the system configuration command, instantiate an axis object corresponding to each stepper motor terminal module; bind the EtherCAT bus connector to each axis object; set the operating mode of each axis object to periodic synchronous position mode; for any axis object, based on the EtherCAT bus connector, map the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to the axis object to the local PDO input address and local PDO output address of the axis object respectively;

[0014] In response to the positioning motion command, a target axis object corresponding to the positioning motion command is acquired. Within any control cycle, the actual parameters of the corresponding stepper motor are obtained from the local PDO input address of the target axis object, and the actual parameters are uploaded to the CODESYS controller, so that the CODESYS controller obtains the corresponding target parameters based on the actual parameters. Within any control cycle, the target parameters are acquired; the target parameters are written to the local PDO output address of the target axis object, so as to be sent to the corresponding stepper motor terminal module through the EtherCAT bus, thereby performing position control of the stepper motor.

[0015] Thirdly, this disclosure provides a stepper motor drive device based on an EtherCAT bus, disposed in an AI computer. The AI ​​computer includes a CODESYS controller and is connected to one or more stepper motor terminal modules via an EtherCAT bus. The stepper motor terminal modules are used to control corresponding stepper motors and are connected to the corresponding stepper motors through their own motor terminals. The stepper motor drive device includes:

[0016] The stepper motor drive command receiving module is configured to receive stepper motor drive commands sent by the CODESYS controller, the stepper motor drive commands including system configuration commands and positioning motion commands;

[0017] The system configuration command response module is configured to: in response to the system configuration command, instantiate an axis object corresponding to each stepper motor terminal module; bind an EtherCAT bus connector to each axis object; set the operating mode of each axis object to a periodic synchronous position mode; and for any axis object, map the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to that axis object to the local PDO input address and local PDO output address of that axis object based on the EtherCAT bus connector.

[0018] The positioning motion command response module is configured to respond to the positioning motion command by acquiring the target axis object corresponding to the positioning motion command, obtaining the actual parameters of the corresponding stepper motor from the local PDO input address of the target axis object within any control cycle, uploading the actual parameters to the CODESYS controller so that the CODESYS controller can obtain the corresponding target parameters based on the actual parameters; acquiring the target parameters within any control cycle; writing the target parameters to the local PDO output address of the target axis object, so as to send them to the corresponding stepper motor terminal module through the EtherCAT bus, thereby performing position control on the stepper motor.

[0019] Fourthly, this disclosure provides an electronic device including a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method described in the second aspect.

[0020] Fifthly, this disclosure provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the method described in the second aspect.

[0021] According to the technical solution provided in this disclosure, the stepper motor drive system includes: an AI computer and one or more stepper motor terminal modules. The AI ​​computer includes a CODESYS controller and a stepper motor drive module. The AI ​​computer is connected to each stepper motor terminal module via an EtherCAT bus. The stepper motor terminal module is used to control the corresponding stepper motor and is connected to the stepper motor through its own motor terminals.

[0022] The CODESYS controller is configured to: generate stepper motor drive instructions and send the stepper motor drive instructions to the stepper motor drive module, wherein the stepper motor drive instructions include: system configuration instructions and positioning motion instructions; the stepper motor drive module is configured to: respond to the system configuration instructions, instantiate axis objects corresponding one-to-one with each stepper motor terminal module; bind EtherCAT bus connectors to each axis object; set the working mode of each axis object to periodic synchronous position mode; and for any axis object, map the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to that axis object to the corresponding EtherCAT bus connector. The system defines the local PDO input address and local PDO output address of any axis object; in response to the positioning motion command, it acquires the target axis object corresponding to the positioning motion command; within any control cycle, it retrieves the actual parameters of the corresponding stepper motor from the local PDO input address of the target axis object, and uploads the actual parameters to the CODESYS controller so that the CODESYS controller obtains the corresponding target parameters based on the actual parameters; within any control cycle, it acquires the target parameters; and writes the target parameters into the local PDO output address of the target axis object to send them to the corresponding stepper motor terminal module via the EtherCAT bus to achieve position control of the stepper motor.

[0023] This disclosure implements the hardware driving function of the stepper motor in an intelligent machine built with the CODESYS software platform, and uses the EtherCAT bus for high-speed, deterministic communication. It provides a drive system that can seamlessly connect CODESYS and EtherCAT stepper terminal modules, so that motion control no longer depends on hardware combinations of specific brands, but is built on an open and universal computing and communication architecture. This reduces development difficulty and saves system costs, and accelerates the popularization and upgrading in application scenarios such as multi-axis EtherCAT stepper platforms, low-cost servo replacement of laboratory or teaching instruments and equipment, and smooth upgrade of old equipment pulse direction drivers to bus control.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0025] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments, taken in conjunction with the accompanying drawings. In the drawings:

[0026] Figure 1 A structural block diagram of a stepper motor drive system based on an EtherCAT bus according to an embodiment of the present disclosure is shown.

[0027] Figure 2 A flowchart illustrating a stepper motor drive module responding to system configuration commands according to an embodiment of the present disclosure is shown.

[0028] Figure 3 A flowchart illustrating a stepper motor drive module responding to a positioning motion command according to an embodiment of the present disclosure is shown.

[0029] Figure 4 A flowchart illustrating a stepper motor drive module responding to motion control commands according to an embodiment of the present disclosure is shown.

[0030] Figure 5 A flowchart illustrating a stepper motor drive module updating communication status and axis status according to an embodiment of the present disclosure is shown.

[0031] Figure 6 A flowchart illustrating a stepper motor drive module performing open circuit detection and overrun protection according to an embodiment of the present disclosure is shown.

[0032] Figure 7 A flowchart illustrating a stepper motor driving method based on an EtherCAT bus according to an embodiment of the present disclosure is shown.

[0033] Figure 8A structural block diagram of a stepper motor drive device based on an EtherCAT bus according to an embodiment of the present disclosure is shown.

[0034] Figure 9 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0035] In the following, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings to enable those skilled in the art to readily implement them. Furthermore, for clarity, portions unrelated to the description of exemplary embodiments have been omitted from the drawings.

[0036] In this disclosure, it should be understood that terms such as “comprising” or “having” are intended to indicate the presence of features, figures, steps, behaviors, components, parts or combinations thereof disclosed in this specification, and are not intended to exclude the possibility of the presence or addition of one or more other features, figures, steps, behaviors, components, parts or combinations thereof.

[0037] It should also be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0038] As mentioned earlier, the existing CODESYS motion control system lacks a standardized, high-performance drive layer for stepper motors. This results in users facing long development cycles and high technical barriers when developing stepper control applications. Furthermore, it can easily lead to problems such as unstable communication, asynchronous motion, or runaway risks, which severely restricts the rapid deployment of stepper motors in low-cost, multi-axis bus control systems and the efficiency of retrofitting old equipment.

[0039] To reduce the technical difficulty and overall cost of building a stepper control system based on the CODESYS platform and stepper motors, improve equipment interoperability and field maintenance efficiency, and accelerate the popularization and upgrading of multi-axis EtherCAT stepper platforms, low-cost servo replacement of laboratory or teaching instruments and equipment, and smooth upgrade of old equipment pulse direction drivers to bus control, this disclosure provides a stepper motor drive system based on EtherCAT bus that can seamlessly connect CODESYS and stepper motor terminal modules.

[0040] Figure 1 A structural block diagram of a stepper motor drive system based on an EtherCAT bus according to an embodiment of the present disclosure is shown. Figure 1As shown, the stepper motor drive system includes: an AI computer and one or more stepper motor terminal modules. The AI ​​computer includes a CODESYS controller and a stepper motor drive module. The AI ​​computer is connected to each stepper motor terminal module via an EtherCAT bus. The stepper motor terminal module is used to control the corresponding stepper motor and is connected to the stepper motor through its own motor terminals.

[0041] Specifically, for a single-axis stepper motor drive system, the AI ​​is connected to one stepper motor terminal module and one corresponding stepper motor; for a multi-axis stepper motor drive system, the AI ​​is connected to multiple stepper motor terminal modules and multiple corresponding stepper motors.

[0042] In one implementation of this disclosure, the industrial intelligent machine (AI machine) is a Zhongke Times AI machine, which is an industrial control computer conforming to the industry standard x86_64 architecture. It is used to host the control system and operating environment. The CODESYS controller included on the AI ​​machine includes, but is not limited to, the CODESYS application and CODESYS runtime software. The CODESYS runtime software (e.g., CODESYS Control for Linux runtime software) is directly installed and runs on the operating system (e.g., Linux) of the AI ​​machine, providing basic, deterministic real-time task scheduling, memory management, I / O drivers, communication protocol stacks, security mechanisms, and other low-level services. The CODESYS application is a specific control logic program written by engineers in a CODESYS development environment (e.g., an integrated development environment using CODESYS-V3.5-SP18-Patch-4 or higher) using a specific programming language (e.g., Structured Text ST). It includes specific business functions such as control logic, motion control functions, data processing, and alarm handling for specific machines or processes. For example, controlling the entire process of a packaging machine includes all instructions and logic for controlling the stepper motor through the stepper motor terminal module. After compilation, the CODESYS application is downloaded over the network to the AI ​​system running the CODESYS runtime software. The CODESYS runtime software receives and loads the CODESYS application, executing it under its own real-time task scheduling management. Since the AI ​​system communicates with each stepper motor terminal module based on the EtherCAT bus protocol, for the stepper motor drive system, the AI ​​system supports the EtherCAT master protocol, acting as the EtherCAT master responsible for control communication and executing control logic; the stepper motor terminal modules act as EtherCAT slaves, responsible for executing tasks.

[0043] In one implementation of this disclosure, the stepper motor terminal module connected to the AI ​​machine adopts the Beckhoff EL7037 or EL7047 stepper motor terminal module from Beckhoff Automation GmbH, Germany, with firmware version ≥2022-09. The EL7037 and EL7047 are general-purpose and cost-effective solutions for controlling stepper motors. They support various operating modes and can adapt to a wide range of applications. Through field-oriented control, they provide near-servo drive performance while maintaining the cost advantage of stepper motors. The stepper motor terminal module itself has motor terminals, through which a hybrid cable is used to connect to the corresponding stepper motor, which can be a two-phase stepper motor.

[0044] In one implementation of this disclosure, the stepper motor drive module is a software middleware layer located between the CODESYS controller and the EtherCAT physical network, enabling intelligent adaptation between control commands and bus communication. Specifically, the stepper motor drive module serves as the central hub for real-time data exchange, acting as the data channel between the CODESYS controller and the EtherCAT slave station. It manages the input and output of all motion control-related data and is a crucial component ensuring the system's real-time performance. Furthermore, by configuring the stepper motor drive module, the CODESYS controller only needs to handle the pure control algorithm without needing to address how to communicate with specific terminal modules via EtherCAT frames. This significantly simplifies application development and improves code portability and maintainability.

[0045] According to an embodiment of this disclosure, the CODESYS controller is configured to: generate stepper motor drive instructions and send the stepper motor drive instructions to the stepper motor drive module, wherein the stepper motor drive instructions include: system configuration instructions and positioning motion instructions.

[0046] Specifically, the CODESYS controller is responsible for decision-making, calculation, and issuing high-level commands by running the written CODESYS application; the stepper motor drive module is a system library, function block, or service that provides a standard API interface and is responsible for performing low-level device configuration, data mapping, and periodic real-time data exchange. Commands can be issued by calling the function blocks (FBs) or functions provided by the stepper motor drive module through the CODESYS application.

[0047] In one implementation of the stepper motor driver module disclosed herein, the development and operating environment of the stepper motor driver module is shown in Table 1:

[0048] Table 1. Detailed list of development and operation environments for the stepper motor drive module disclosed in this paper.

[0049]

[0050] The implementation files involved in the stepper motor drive module include: PLC source code files and device description files. These two files together constitute a complete CODESYS driver software package. The PLC source code files provide the core function implementation, while the device description files provide the configuration interface and runtime integration support. Specifically, the PLC source code files are driver adapter software for the Beckhoff EL7037 stepper motor terminal module, used to implement stepper motor control functions in CODESYS. The PLC source code files include input / output data type definitions, function block logic implementation, PDO (Process Data Object) mapping methods, control word, position, and speed read / write logic, and interaction logic with the EtherCAT bus. The device description files are used to register the stepper motor drive module in the CODESYS device library, enabling it to be recognized and configured in the device tree. This includes: device identification information, parameter configurations (such as software limits, speed, acceleration, etc.), PDO mapping configurations, and driver registration information.

[0051] In one specific embodiment, the PLC source code file is named "SM3_Drive_ETC_Sinsegye_Stepper.xml", and the device description file is named "DeviceDescription.xml". The SM3_Drive_ETC_Sinsegye_Stepper.xml file mainly contains the following hierarchical structure:

[0052] 1. Top-level project information layer: contains project metadata, such as version information, development environment, author information, etc.

[0053] 2. Data type definition layer: Defines two core data structures: SMC3_Stepper_SpecificInputs (input data structure, containing StatusByte, ActualPosition, ActualVelocity) and SMC3_Stepper_SpecificOutputs (output data structure, containing ControlByte, SetPosition, SetVelocity).

[0054] 3. Function block implementation layer: The core is the SM3_Drive_ETC_Sinsegye_Stepper function block, which inherits from MetaCore_MC.AXIS_REF_MAPPING_SM3, forming a complete axis control object.

[0055] The functional blocks employ a modular partitioning design, comprising: an interface definition area, a method implementation area, and a property definition area. The interface definition area defines the input interfaces (including PDO input structures, ControlEnable, ControlReset, and ReduceTorque), output interfaces (including PDO output structures), and local variables (including myConnector (EtherCAT connector pointer), ReConnectFlag, and dwFlags). The method implementation area is grouped by function, including: PDO data mapping methods, periodic control methods, and auxiliary function methods. The PDO data mapping methods include: data reading methods, such as GetByteFromMap, GetIntFromMap, and GetUDintFromMap, used to read different data types from the EtherCAT PDO; and data writing methods, such as SetByteToMap, SetIntToMap, and SetUDintToMap, used to write different data types to the EtherCAT PDO. The cycle control methods include: an initialization method (Initialize) for establishing connector binding and PDO mapping; processing methods before and after PDO input reading (BeforeReadInputs / AfterReadInputs); and processing methods before and after PDO output writing (BeforeWriteOutputs / AfterWriteOutputs). The attribute definition area includes: input attributes, such as StatusByte, ActualPosition, and ActualVelocity, used to map to specific PDO input addresses; and output attributes, such as ControlByte, SetPosition, and SetVelocity, used to map to specific PDO output addresses.

[0056] 4. Library dependencies

[0057] The PLC source code file declares several required library dependencies: task management library (CmpIecTask), log library (CmpLog), IO standard library (IoStandard), SM3 runtime library (SM3_RBase), SM3 shared library (SM3_Shared), standard library (Standard), system type library (SysTypes2), error handling library (CmpErrors2), and axis control base library (MetaCore_MC).

[0058] In one specific embodiment, the device description file is named "DeviceDescription.xml", which mainly contains the following hierarchical structure:

[0059] 1. Device identification section, including: DeviceIdentification: contains device type (1027), device ID (10020020), and version number (1.0.0.0). DeviceInfo: contains device name, icon file reference, etc.

[0060] 2. In the connector configuration section, two key connectors are configured: Parent connector (connectorId="1"): Logical driver interface (Common.SoftMotion.Logical), role is parent. Child connector (connectorId="0"): Physical driver interface (Common.SoftMotion.EtherCAT.Beckhoff.EL7037), role is child, corresponding to the specific EL7037 module.

[0061] 3. Parameter Configuration Section (Grouped by Function): Group 1: AXIS_REF Standard Parameters, including basic axis configuration parameters such as: wDriveID: unique identifier for the terminal module; bVirtual: whether it is a virtual axis; iMovementType: motion type (0: module, 1: finite); Group 2: AXIS_REF Scaling Parameters, defining the conversion relationship between engineering units and the internal units of the terminal module, such as: dwRatioTechUnitsDenom / iRatioTechUnitsNum: technical unit conversion ratio; ScalingIncs: pulses per revolution; ScalingUnits: number of engineering units per revolution; InvertDirection: direction reversal flag; Group 3: Standard Drive Settings, including: FeedbackType Feedback type (Internal / Encoder / NoFeedback); fSetActTimeLagCycles: Time lag between setpoint and actual value; Fourth group: Driver input / output mapping configuration, this is the core part, which defines the PDO mapping relationship in detail, including: Output mapping: Defines the EtherCAT object dictionary address of output variables such as ControlByte, SetPosition, SetVelocity; Input mapping: Defines the EtherCAT object dictionary address of input variables such as StatusByte, ActualPosition, ActualVelocity; Each mapping parameter includes: parameter ID, default value, object dictionary address (e.g., 16#7010:01), bit offset, bit length and other detailed information.

[0062] 4. Driver instantiation configuration section, including: DriverInfo: declares the required libraries (SM3_Drive_ETC and SM3_Drive_ETC_Sinsegye_Stepper); FBInstance: function block instance configuration, used to specify: function block name (SM3_Drive_ETC_Sinsegye_Stepper), initialization method (Initialize), and four cycle call methods and their call timing in the bus cycle task.

[0063] When generating execution software that can run on an AI machine based on PLC source code files and device description files, first, a new project is created in the CODESYS development environment, selecting a controller model compatible with the source code. Then, the PLC source code files and device description files are imported. In the DeviceDescription.xml file, a device type named "SM3_Drive_ETC_Sinsegye_Stepper" is defined. A custom drive device is then registered in the CODESYS device tree through the device description file, making it recognizable as "SM3_Drive_ETC_Sinsegye_Stepper". The specific steps include: placing the DeviceDescription.xml file in the device description directory of the project; registering the device description file in the device tree via "Install Device Description File"; after registration, the "SM3_Drive_ETC_Sinsegye_Stepper" device type can be found in the EtherCAT slave list, and the device can be dragged and dropped under the EtherCAT master station to configure its parameters (such as scaling ratio, limit, mapping parameters, etc.); after importing the PLC source code file and device description file, compile the project to generate executable code, and finally deploy the project to the CODESYS runtime software system of the AIJ.

[0064] Before controlling the stepper motor's motion, system configuration commands must first be issued to initialize, parameterize, and prepare the entire EtherCAT stepper motor drive system. In practice, this can be achieved by writing logic in the initialization phase of the CODESYS application and calling the initialization methods provided by the stepper motor drive module.

[0065] Figure 2 A flowchart illustrating a stepper motor drive module responding to system configuration commands according to an embodiment of the present disclosure is shown. Figure 2 As shown, when processing system configuration commands, the stepper motor drive module includes the following steps S210~S240:

[0066] In step S210, an axis object corresponding to each stepper motor terminal module is instantiated.

[0067] In this disclosure, the "axis object" is a logical entity in the software, which is a complete abstraction of a physical motion axis (i.e., a stepper motor controlled by a stepper motor terminal module). It encapsulates the axis's state, configuration parameters, control interface, and real-time data buffer.

[0068] In this disclosure, the "physical motion axis" corresponding to the "axis object" is a bus axis. The device description file contains definitions of relevant parameters for the physical motion axis. These parameters are used to configure and control the behavior, performance, and motion characteristics of the physical or logical axis associated with the axis object. For example, the device description file defines AXIS_REF:Standard (standard parameters), which defines the basic configuration and motion control parameters of the axis. These parameters typically correspond to standard fields in the AXIS_REF structure or similar data structures. These parameters are read when the axis object is instantiated and used to configure the corresponding fields in the AXIS_REF structure. Additionally, the device description file also defines AXIS_REF:Scalings (scaling parameters), which defines the conversion relationship between engineering units and the internal units of the terminal module. This is crucial for converting physical quantities such as "position, velocity, and acceleration" from user units (e.g., millimeters, degrees) to the internal units of the terminal module (e.g., pulses, increments).

[0069] As mentioned earlier, in the DeviceDescription.xml file disclosed herein, a device type named “SM3_Drive_ETC_Sinsegye_Stepper” is defined. This device type corresponds to an axis object, which is a function block instance. Its definition comes from the SM3_Drive_ETC_Sinsegye_Stepper function block in the PLC source code file.

[0070] Before performing this step, the user needs to add the required "SM3_Drive_ETC_Sinsegye_Stepper" device to the CODESYS device tree. For example, if there are three stepper motor terminal modules in the system, the user needs to add three device instances: Drive1, Drive2 and Drive3, which correspond to the first stepper motor terminal module, the second stepper motor terminal module and the third stepper motor terminal module, respectively.

[0071] During system runtime, the CODESYS runtime software scans the device tree, reads the FBInstance configuration from the device description file, and creates a function block instance for each device node. Assuming there are three device nodes, three function block instances are created, i.e., three axis objects. Next, the system reads the default parameter values ​​from the device description file and initializes the parameters of each axis object, including automatically assigned or user-specified wDriveID (a unique axis identifier), scaling parameters, etc. Finally, each instantiated axis object contains input data structures, output data structures, local variables, and inherited axis control variables. In this way, each stepper motor terminal module has a unique EtherCAT node address, and the wDriveID parameter of each axis object corresponds to a physical node address.

[0072] In step S220, the EtherCAT bus connector is bound to each axis object.

[0073] In the CODESYS SoftMotion architecture, the EtherCAT bus connector IoConfigConnector is an abstract data structure representing the communication channel with the physical device. It contains: device type information, node address, etc.

[0074] PDO mapping configuration and communication status information. When the system starts, CODESYS creates a connector instance for each EtherCAT slave device. During connector initialization, key information is set, such as: the stepper motor terminal module type corresponding to the connector (e.g., 1027 for EL7037), EtherCAT node address, PDO mapping configuration pointer, parent connector pointer, and status flags.

[0075] The binding of EtherCAT bus connectors to each axis object is primarily implemented in the `Initialize` method of the PLC source code. When the device starts, the CODESYS runtime system calls the `Initialize` method of each axis object. Within the `Initialize` method, each axis object saves the passed connector pointer to the `myConnector` variable, thus establishing a bidirectional relationship between the axis object and the connector. Specifically, the axis object accesses the connector data structure through the `myConnector` pointer, avoiding data copying and improving communication efficiency; the connector calls methods in the axis object and passes parameters through function block instance references.

[0076] This disclosure provides each axis object with a channel to access the physical device by binding an EtherCAT bus connector to it. On one hand, this ensures that if a stepper motor terminal module or corresponding axis object fails, the failure is completely confined to that single axis object and will not spread to other axes objects through shared resources or data channels. This isolation enables graceful degradation; even if some axes fail, the remaining axes can continue to operate normally, significantly improving the availability and robustness of the entire motion control system. On the other hand, independent connector binding provides each axis object with a dedicated communication channel and data buffer, eliminating resource contention and data conflicts between multiple axes. PDO data read / write operations for each axis object can be performed in parallel, significantly reducing bus communication latency. Simultaneously, direct pointer access to the connector by the axis object avoids data copying overhead, ensuring stable cycle times and predictable response performance for each axis under demanding real-time control scenarios. Furthermore, the modular architecture allows for independent configuration, debugging, and maintenance of individual axis objects. Engineers can modify parameters, update firmware, or replace hardware for specific axes without stopping the entire system. Furthermore, during development, each axis object can be tested and verified as an independent unit, greatly simplifying the debugging process.

[0077] In step S230, the working mode of each axis object is set to periodic synchronous position mode.

[0078] In EtherCAT and CODESYS SoftMotion, the Cyclic Synchronous Position (CSP) mode is both periodic and synchronous. This means that control commands are sent in each fixed EtherCAT bus cycle, and the command sending and status reading of all axes are strictly synchronized. The controller directly sends the target position, and the stepper motor terminal module is responsible for the position closed loop.

[0079] The periodic synchronous position mode is one of the standard bus control modes defined in the driver specification CiA 402. Its core feature is that the stepper motor drive commands of the controller are strictly synchronized with the communication cycle of the bus.

[0080] In step S240, for any axis object, based on the EtherCAT bus connector, the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to the any axis object are mapped to the local PDO input address and local PDO output address of the any axis object.

[0081] In this context, the PDO (Process Data Object) is the basic unit of EtherCAT real-time data exchange. Before mapping, a mapping configuration needs to be predefined in the device description file for each data variable to be exchanged. For output variables (such as control bytes, target position, and target speed), specify their target address in the EtherCAT object dictionary in the format "index:subindex" (e.g., mapping control bytes to 16#7010:01). For input variables (such as status bytes, actual position, and actual speed), similarly define the corresponding object dictionary source address (e.g., mapping status bytes to 16#6010:01). Each mapping configuration also includes parameters such as data type, bit length, and bit offset; these configurations serve as static metadata for the driver software.

[0082] In the actual mapping establishment process, after the system starts and instantiates the axis object, dynamic mapping establishment is performed during the initialization phase. When the Initialize method of the axis object is called, the system passes in the EtherCAT connector pointer associated with the axis object. Subsequently, by calling the SM0.GetMappingParams function, the following key operations are performed: First, the static configuration in the device description file is parsed to obtain the object dictionary address (index and sub-index) of each variable; then, the I / O configuration system is queried through the connector, and the I / O configuration system further requests the actual physical memory address of the object dictionary entry from the EtherCAT master stack; finally, the obtained physical memory address information is filled into the corresponding entry in the PDO mapping array inherited by the axis object. The connector acts as a query intermediary, assisting the axis object in obtaining dynamically allocated physical memory addresses from the address allocation system managed by the EtherCAT master stack. Through this process, a lookup table from logical indexes to runtime-allocated physical memory addresses is established within the axis object, rather than a direct mapping to fixed bus addresses.

[0083] Once the CODESYS controller generates positioning motion commands, the entire execution process is carried out under strict timing control of the EtherCAT bus cycle. Figure 3 A flowchart illustrating a stepper motor drive module responding to positioning motion commands according to an embodiment of the present disclosure is shown. Figure 3 As shown, when processing system configuration commands, the stepper motor drive module includes the following steps S310~S340:

[0084] In step S310, in response to the positioning motion command, the target axis object corresponding to the positioning motion command is obtained.

[0085] Among them, positioning motion commands specifically refer to control commands whose primary objective is to control the actuator to reach a specific spatial position or sequential position. The core characteristics of these commands are target orientation and accuracy requirements. Their ultimate goal is to enable the controlled object (such as the mechanical load of a stepper motor) to accurately and stably reach one or more target positions specified by the command. Positioning motion commands include, but are not limited to: PTP (Point-to-Point) motion control commands and discrete motion control commands.

[0086] Upon receiving a positioning motion command, the controller first parses the command to extract the target axis identifier specified in it. The controller maintains a list of axis object references, established during system configuration, where each reference corresponds to a physical stepper motor terminal module. Then, based on the parsed axis identifier, the controller searches this list to retrieve the corresponding axis object reference. This search process relies on a unique identifier (such as wDriveID) assigned during axis object initialization, ensuring accurate positioning of the physical axis specified in the command.

[0087] In step S320, within any control cycle, the actual parameters of the corresponding stepper motor are obtained from the local PDO input address of the target axis object, and the actual parameters are uploaded to the CODESYS controller so that the CODESYS controller can obtain the corresponding target parameters based on the actual parameters.

[0088] According to embodiments of this disclosure, the local PDO input address of the axis object contains actual parameter variables, and the local PDO output address of the axis object contains target parameter variables. The actual parameters include actual position and actual speed, and the target parameters include target position and target speed. The step of obtaining the corresponding actual parameters of the stepper motor from the local PDO input address of the target axis object and uploading the actual parameters to the CODESYS controller includes:

[0089] The actual parameters of the corresponding stepper motor are read from the actual parameter variables of the local PDO input address of the target axis object, so that the CODESYS controller can obtain the actual parameters of the stepper motor driven by the stepper motor terminal module corresponding to the target axis object by returning the actual parameters through a callback function.

[0090] At the start of each bus cycle, the system, according to the timing configured in the device description file, first calls the BeforeReadInputs method of the selected axis object. This method mainly performs some pre-reading preparations, typically calling the parent class implementation to complete general preparations. Afterwards, the EtherCAT master hardware automatically performs input data exchange: the master sends EtherCAT frames to all connected slaves, and each stepper motor terminal module fills its actual parameters (including actual position, actual speed, etc.) into its respective Transmit Process Data Object (TxPDO). The master then reads data from all slaves' TxPDOs and stores it in a pre-defined input data image area in the master's memory. Each axis object's data has a specific offset address in this image area; these addresses have been associated with the axis object's input mapping array through a mapping mechanism during system initialization.

[0091] After the hardware completes the input data reading, the system calls the AfterReadInputs method of the selected axis object. The core task of this method is to perform data reading and state updates. It triggers the data reading process by accessing the input properties defined internally by the axis object (such as ActualPosition and ActualVelocity). The Get accessors of these properties internally call the corresponding mapping read methods (such as GetByteFromMap and GetUDintFromMap). The mapping read method finds the corresponding input mapping array entry for the property based on a pre-established mapping table, retrieves the physical memory address allocated by the EtherCAT master station, and then directly reads the raw byte data from that address. Since EtherCAT communication uses little-endian byte order, the method needs to recombine the read bytes into the required data type in the correct order (e.g., combining 4 bytes into a 32-bit unsigned integer). The combined data is assigned to the axis object's input structure variable and is also converted to a signed integer format and stored in the axis object's internal state variable. Finally, the method calls the parent class implementation to complete the general post-read processing and updates the diagnostic information of the connector associated with the axis object.

[0092] The upload of actual parameters is not done actively, but automatically through the feedback mechanism of the CODESYS SoftMotion architecture. The actual position and velocity variables within the axis object are stored in units internal to the terminal module (e.g., pulse count, pulses / second). The CODESYS controller periodically retrieves the axis status by calling a standard motion control status read function block (e.g., MC_ReadAxisStatus) and passing a reference to the axis object. When the controller reads the status, the underlying system automatically retrieves the actual parameter values ​​from the axis object and converts these internal unit values ​​into user-understandable engineering units (e.g., millimeters, degrees / second) based on the scaling parameters (e.g., ScalingIncs and ScalingUnits) defined in the device description file. The converted actual position and velocity values ​​are then populated into the output of the status read function block for use by the controller in motion planning or logical judgment. This process is transparent to the user program, ensuring that the controller obtains standardized engineering values ​​that can be directly used for calculation.

[0093] After obtaining the actual parameters, the CODESYS controller calculates new target parameters in its own control loop or motion planner. Specifically, the controller compares the target position commanded by the user with the actual position to calculate the position error; using control algorithms such as PID, it calculates the basic velocity compensation command based on the position error; simultaneously, the trajectory planner generates smooth velocity and acceleration feedforward signals based on the target position and velocity required by the command; finally, the feedback compensation and feedforward signals are combined to obtain the final target velocity command to be sent to the terminal module. The calculated target parameters (mainly target position and target velocity) are still in engineering units. Subsequently, the controller passes these engineering unit target parameters to the axis object by setting the parameters (such as target position and target velocity) of the motion control function block associated with the axis object. The base class of the axis object automatically converts these engineering unit values ​​back to the internal unit values ​​required by the terminal module according to the same scaling parameters and stores them in its internal target setting variable, preparing for the next step of writing to the terminal module.

[0094] In step S330, within any control cycle, the target parameter is acquired; the target parameter is written to the local PDO output address of the target axis object, so as to be sent to the corresponding stepper motor terminal module through the EtherCAT bus to realize the position control of the stepper motor.

[0095] According to an embodiment of this disclosure, obtaining the target parameter includes: reading the target parameter from the target data variable of the target axis object, wherein the target parameter is written to the target data variable of the target axis object by the CODESYS controller through a callback function.

[0096] According to an embodiment of this disclosure, writing the target parameter to the local PDO output address of the target axis object includes: writing the target parameter to the target parameter variable of the local PDO output address of the target axis object.

[0097] Later in the same control cycle, the system calls the BeforeWriteOutputs method of the selected axis object. This method is responsible for preparing and writing the output data. Specifically, it assigns the target position and target velocity values, which have been converted to internal units and stored internally by the axis object, to output structure variables. Then, the actual write operation is triggered by assigning these output structure variables to the axis object's output properties (such as SetPosition and SetVelocity). Each output property's Set accessor internally calls the corresponding mapping write method (such as SetByteToMap and SetUDintToMap). The mapping write method finds the corresponding entry in the output mapping array based on the mapping index, obtains the target physical memory address, and then splits the data value to be sent into individual bytes in little-endian byte order, writing them sequentially to the memory area pointed to by that address. At this point, the target parameters have been written from the axis object's internal variables to the location allocated for this specific axis object in the EtherCAT master station's output data image area via the mapping mechanism.

[0098] After the BeforeWriteOutputs method completes, the EtherCAT master hardware automatically performs the final sending action during the output data exchange phase of the cycle. The master packs the contents of the entire output data image area in memory into the EtherCAT data frame to be sent. As this frame is transmitted on the bus, each slave module reads its own node's data segment (i.e., its respective receive process data object RxPDO) in real time. Specifically, the selected stepper motor terminal module extracts the control bytes, set position, and set speed data mapped to it from the bus frame and updates the corresponding entries in its internal object dictionary (e.g., sub-indices 0x01, 0x17, and 0x33 of index 0x7010). Once the terminal module hardware detects a change in the values ​​of these object dictionary entries, it immediately drives the stepper motor to perform the corresponding movement according to the new set position and speed, achieving precise position control. After the output data exchange is complete, the runtime system also calls the AfterWriteOutputs method of the axis object to perform some post-processing work, thus completing a full "read-calculate-write" control cycle. This cycle repeats continuously with the EtherCAT bus cycle, achieving continuous closed-loop control of the stepper motor.

[0099] According to embodiments of this disclosure, the local PDO output address of the axis object includes a control word variable, and the stepper motor drive instruction further includes a motion control instruction. Figure 4 A flowchart illustrating a stepper motor drive module responding to motion control commands according to an embodiment of the present disclosure is shown. Figure 4 As shown, the stepper motor drive module, when processing motion control commands, includes the following steps S410~S430:

[0100] In step S410, the specified axis object corresponding to the motion control command is obtained.

[0101] In step S420, control data is obtained based on the control data variables of the specified axis object.

[0102] According to embodiments of this disclosure, the control data variables include: a first control data variable, a second control data variable, and a third control data variable. When acquiring control data based on the control data variables of the specified axis object, the following steps S421-S423 are included:

[0103] In step S421, the presence or absence of an enable command is detected based on the first control data variable of the specified axis object, and the first control data is generated according to the detection result.

[0104] In step S422, the presence or absence of a reset command is detected based on the second control data variable of the specified axis object, and second control data is generated according to the detection result.

[0105] In step S423, a torque reduction command is detected based on the third control data variable of the specified axis object, and third control data is generated according to the detection result.

[0106] Wherein, the first control data, the second control data, and the third control data are all Boolean values.

[0107] In one implementation of this disclosure, the CODESYS controller generates control data primarily through two parallel mechanisms: direct generation by user program logic and automatic generation by motion control function blocks.

[0108] In the user program logic, the user writes the control logic according to process requirements. The controller program reads external input signals (such as buttons on the operation panel, sensor status, and instructions from the host computer) and internal state machine logic, and generates control data after comprehensive judgment. This control data is assigned to global variables associated with the axis object. For example, when the operator presses the "Start" button, the program sets the corresponding enable control variable to TRUE; when the system detects a terminal module fault, the program generates a reset control pulse; when the motor temperature exceeds the safety threshold, the program activates torque reduction control.

[0109] For the automatic generation of motion control function blocks, CODESYS provides a standardized motion control instruction library. When users call these function blocks in their programs, the function blocks automatically generate corresponding control data based on their states. For example, when the MC_Power function block is called and its Enable input is TRUE, it automatically sets the enable control data for the corresponding axis object; the MC_Reset function block generates a reset pulse signal with a controllable time width during execution. These function blocks encapsulate state machines and timing logic that conform to motion control standards, ensuring that the generation of control data is both standardized and reliable.

[0110] Control data is transferred from the CODESYS controller to the axis objects using a variable join binding mechanism. In this disclosure, each axis object instance has three specific Boolean input variables: ControlEnable, ControlReset, and ReduceTorque. Developers associate control variables in the user program with these axis object input variables by establishing join relationships in the variable declaration section. This join is determined at compile time and manifests as direct data transfer at runtime, without any intermediate conversion process. The CODESYS controller updates the values ​​of these control variables in each scan cycle, and the axis objects read these values ​​as control data sources in each EtherCAT bus cycle.

[0111] Furthermore, motion control commands are translated into operations on control data variables at the controller level. Whether the logic is directly written by the user or the commands are generated through standard function blocks, they ultimately manifest as assignment operations on the control data variables of the axis objects. The controller maintains a task scheduling system to ensure that the updates of control data are synchronized with the PLC scan cycle and also coordinated with the execution timing of the motion control function blocks. In a multi-tasking environment, control data may be generated from tasks of different priorities; the system ensures data consistency through interlocking and synchronization mechanisms.

[0112] In one implementation of this disclosure, the detection of control data variables for a specified axis object is performed within the `BeforeWriteOutputs` method of the axis object. The system first detects the enable command. This detection process is achieved by reading the `ControlEnable` input variable of the axis object, which has received control data from the controller via a variable connection. The detection logic can not only simply read the variable value but also make a comprehensive judgment based on the internal state of the axis object. The axis object internally maintains a `bRegulatorOn` state variable, which reflects the actual enable state of the terminal module's power section. The final generated first control data is the logical OR result of the `ControlEnable` signal sent by the controller and the `bRegulatorOn` state within the axis object. This design ensures that even if the controller does not temporarily send an enable command, as long as the terminal module itself is in an enabled state, the corresponding control bits will still be correctly set, avoiding unnecessary state transitions.

[0113] In one implementation of this disclosure, the detection of the reset command is relatively simple but has strict timing requirements. The system directly reads the value of the ControlReset input variable as the second control data. However, in practical applications, the reset command usually needs to appear in pulse form, i.e., a brief high-level pulse followed by a return to a low level. For this reason, the axis object or upper-level controller needs to implement pulse width management. When a reset command is detected, the system starts a timer that automatically clears the reset flag after a set time. This design ensures that the reset signal is not accidentally continuously activated, while giving the terminal module sufficient response time. Since the reset operation of the terminal module is only effective in a specific state, the detection of the reset command is generally performed after the enable detection.

[0114] In one implementation of this disclosure, the detection of the torque reduction command is based on the ReduceTorque input variable, and its value is directly used as the third control data. Torque reduction is typically used in scenarios such as motor overheat protection or energy-saving operation, so its detection logic may include additional conditional checks. In some implementations, the axis object monitors internal temperature variables or external protection signals, and when an abnormality is detected, torque reduction may be automatically activated even if the controller does not explicitly send a torque reduction command. The generated third control data may be a simple Boolean value or an adjustable percentage value, depending on the control precision supported by the terminal module.

[0115] The detection of three control data points is executed sequentially within the same method call, but independently. The detection process includes multiple safety checks: first, it verifies whether the control data variables are correctly connected; then, it checks the reasonableness of the values; and finally, it makes a final judgment based on the current state of the axis object. For example, if the terminal module is in a faulty state, the system may refuse to execute or delay execution even if an enable command is received. The detection process also includes anti-jitter processing to avoid false detections caused by signal noise.

[0116] In step S430, a control word is constructed based on the control data, and the control word is written into the control word variable of the local PDO output address of the specified axis object, so as to be sent to the stepper motor terminal module corresponding to the specified axis object through the EtherCAT bus.

[0117] In one implementation of this disclosure, the control word is constructed in the BeforeWriteOutputs method of the axis object. The system uses bit manipulation techniques to combine three independent control data into an 8-bit control byte. Specifically, the construction rules are as follows: the first control data (enable) is placed in bit 0 (least significant bit), the second control data (reset) is placed in bit 1, and the third control data (torque reduction) is placed in bit 2. The remaining bits (bits 3-7) are set to fixed values ​​or reserved as zero according to the terminal module protocol requirements.

[0118] Bitwise operations are implemented through a dedicated `Bit_Operation` method. This method takes three arguments: a pointer to the address of the target byte, the bit index (0-7) to be operated on, and the value to be set (TRUE or FALSE). Internally, it first generates a bitmask—left-shifting the number 1 by the specified number of bits—and then, depending on the value to be set, either sets the bit using a logical OR operation or adds the bit using a logical AND operation. By calling this method three times, the three control bits of the control word are set respectively.

[0119] In one implementation of this disclosure, the constructed control word needs to be written to the local PDO output address of the axis object. This process is triggered via the property accessor mechanism. When the control word is assigned to the ControlByte property, the property's Set accessor is automatically invoked. The Set accessor internally calls the SetByteToMap method, which takes two parameters: the PDO mapping index (fixed to 0 for ControlByte) and the control word value to be written.

[0120] The `SetByteToMap` method first checks the validity of the mapping by checking if `m_ameOutputs[0].usiBitLength` is zero. If the mapping is valid, the method directly obtains the physical memory address allocated by the EtherCAT master station from `m_ameOutputs[0].dwAddress`. Since the control word is single-byte data, the method directly writes the byte value to the memory location pointed to by this address without byte order conversion. After the write operation is complete, the method returns `TRUE` to indicate success; if the mapping is invalid, it returns `FALSE` and may trigger error handling.

[0121] After the control word is written to the master station's memory, it is automatically sent out during the output phase of the same EtherCAT bus cycle. The EtherCAT master station hardware packages the memory area containing all slave station output data into a data frame. For the EL7037 stepper module, the control word is mapped to a specific location in the object dictionary (typically index 0x7010, sub-index 0x01). As the data frame is transmitted on the bus, each slave station reads its own data segment in real time.

[0122] After receiving the control word, the EL7037 module parses the meaning of each bit: bit 0 determines whether to enable the power section, bit 1 triggers a fault reset, and bit 2 controls the torque output level. The terminal module hardware immediately adjusts its internal state based on these control bits. For example, when the enable bit changes from 0 to 1, the terminal module starts power output, and the motor obtains holding torque; when a pulse appears in the reset bit, the terminal module clears the fault register; when the torque reduction bit is activated, the terminal module limits the output current to a set ratio.

[0123] In this disclosure, the entire control word issuance process strictly adheres to the real-time requirements of EtherCAT. From control data generation to final drive execution, the data flow goes through multiple stages: user program generates control data, variable concatenation is passed to axis objects, detection and construction are performed in BeforeWriteOutputs, SetByteToMap is written to memory, EtherCAT hardware packages and sends the data, and the terminal module receives and parses the data. Each stage has strict timestamps and synchronization mechanisms to ensure that control commands for all axes in a multi-axis system take effect synchronously.

[0124] According to embodiments of this disclosure, the local PDO input address of the axis object includes a status word variable, and the stepper motor drive module further includes operations for status word parsing and axis state machine mapping. In one implementation of this disclosure, the status word parsing and axis state machine mapping operations are primarily implemented in the AfterReadInputs method of the axis object, which is called after the input phase of each EtherCAT bus control cycle. This method is responsible for processing the raw status data read from the terminal module, converting it into standardized axis states, and updating the communication status information.

[0125] Figure 5 A flowchart illustrating the updating of communication status and axis status by a stepper motor drive module according to an embodiment of the present disclosure is shown. Figure 5 As shown, the specific steps include S510~S560:

[0126] In step S510, within a preset specified control cycle, the status word variable of the local PDO input address of each axis object is polled to see if it has changed. For the axis object that has changed, the first bit of the status word variable of the local PDO input address of the axis object is used to determine whether the corresponding stepper motor terminal module is in an enabled state.

[0127] In the AfterReadInputs method, the status word variable has been read from the EL7037 terminal module into the input structure variable in.StatusByte of the axis object via PDO mapping. At this point, the system determines the enable status by reading the first bit of the status word variable (bit index 0, i.e., the bit after the least significant bit). In one specific implementation, if the first bit is 1, it indicates that the power section of the terminal module is enabled, and the motor is energized; if the first bit is 0, it indicates that the power section of the terminal module is disabled, and the motor is de-energized.

[0128] In step S520, the second bit of the status word variable of the local PDO input address of the axis object is used to determine whether the corresponding stepper motor terminal module is in an idle state.

[0129] The idle state determination is based on the second bit (bit index 1) of the status word. This bit typically indicates whether the terminal module has completed all motion commands and is in a ready state. In one specific implementation, when the second bit is 1, it indicates that the terminal module is in an idle state; when the second bit is 0, it indicates that the terminal module is in a busy state.

[0130] In step S530, the third bit of the status word variable of the local PDO input address of the axis object is used to determine whether the corresponding stepper motor terminal module is in an alarm state.

[0131] The alarm status is determined based on the third bit (bit index 2) of the status word, which indicates whether an error or warning condition has been detected. In one specific implementation, when the third bit is 1, it indicates that an alarm condition exists; when the third bit is 0, it indicates that the terminal module is operating normally.

[0132] In step S540, state information is generated based on the judgment result, and the state information is updated to the state variable of the axis object, so that the CODESYS controller can obtain the current state information of the stepper motor terminal module corresponding to the axis object by reading the callback function of the state variable.

[0133] Specifically, if the axis is disabled and there is no alarm, the status information is "axis disabled," and the status information "MC_AXISSTATE_DISABLED" indicating that the axis is disabled is updated to the status variable of any axis object. If the axis is enabled, idle, and there is no alarm, the status information is "axis stationary and ready," and the status information "MC_AXISSTATE_STANDSTILL" indicating that the axis is stationary and ready is updated to the status variable of any axis object. If the axis is enabled, busy, and there is no alarm, the status information is "axis disabled," and the motion parameters (such as actual speed) are used to further determine whether the axis is in "uniform motion," "acceleration," or "deceleration," and the parameters indicating the corresponding status information are updated to the status variable of any axis object. If there is an alarm, the status information is "axis erroneously stopped," and the status information "MC_AXISSTATE_ERRORSTOP" indicating that the axis is disabled is updated to the status variable of any axis object.

[0134] During the state variable update process, the system detects whether the state has changed. If a change occurs, a callback can be triggered at the end of each control cycle to obtain the current state information of the stepper motor terminal module corresponding to any of the axes.

[0135] In step S550, the communication status variables of the EtherCAT bus connector are obtained, and the communication status variables are parsed by calling the CODESYS function IoMgrConfigSetDiagnosis to obtain the communication status of the EtherCAT bus connector.

[0136] Specifically, the system first obtains raw communication status data from the EtherCAT bus connector. This data is stored in the connector's status variables in the form of bit flags, containing multi-level information such as physical link, data exchange, clock synchronization, watchdog status, and various error counts. Then, the system calls the CODESYS standard function IoMgrConfigSetDiagnosis, which performs deep parsing of these raw bit flags: it decomposes the 32-bit status flag word by function, identifying specific states such as whether the link is normal, whether synchronization is maintained, whether the watchdog timeout has occurred, and the number of CRC errors, and assesses the severity of each problem according to preset rules. The function further converts these discrete status bits into structured diagnostic information, including an overall status rating, a detailed problem list, statistical data, and recovery suggestions, and stores these diagnostic results in a diagnostic buffer associated with the connector. If a serious fault is detected, the function also triggers a corresponding event notification. The entire process aims to transform the low-level hardware communication status into high-level semantic information that the upper-level system can understand and process.

[0137] In step S560, the communication status between each axis object and the corresponding stepper motor terminal module through the EtherCAT bus connector is obtained according to the communication status of the EtherCAT bus connector. The communication status of each axis object is updated to the communication status variable of each axis object, so that the CODESYS controller can obtain the communication status between each axis object and the corresponding stepper motor terminal module through the EtherCAT bus connector through the callback function.

[0138] Specifically, based on the connector-level communication diagnostic information parsed in step S550, the system further derives and updates the communication status of a specific axis object bound to the connector. First, the system maps the general status of the connector to the specific context of the axis object, considering factors such as the axis's position in the EtherCAT network topology and the criticality of its data exchange, to calculate the axis-level communication quality indicators, response time characteristics, and load level. Next, the system updates a series of communication status variables within the axis object: setting a comprehensive communication status (e.g., normal, warning, error) and sub-statistics (e.g., link interruption, synchronization loss, response timeout), updating detailed Boolean status flags (e.g., physical link normal, logical connection established, active data exchange), and refreshing statistical information (e.g., CRC error count, link loss count). The system also maintains a circular buffer for communication status history records for trend analysis. Based on the updated status, the system intelligently decides whether to initiate an automatic reconnection process and manages the number and interval of reconnection attempts. Finally, if a significant change occurs in the communication status (such as a shift from normal to fault), the system asynchronously notifies the CODESYS controller via a callback mechanism, transmitting callback data containing detailed information such as event type, old and new statuses, timestamps, and quality scores. This allows the controller to respond promptly, for example, by logging alarms or adjusting control strategies. The entire process ensures that the communication status of each axis object is independently, accurately, and in real-time monitored and managed, and synchronized with the upper-level control system.

[0139] According to embodiments of this disclosure, the local PDO input address of the axis object includes actual parameter variables, which include actual position variables and actual speed variables. The axis object includes target data variables and status variables, where the target data variables include target position variables. The stepper motor drive module further includes operations for wire breakage detection and runaway protection. This operation is performed within a preset specified control cycle by monitoring the communication status contained in the communication status variables of each axis object. Figure 6 A flowchart illustrating a stepper motor drive module performing open circuit detection and overspeed protection according to an embodiment of the present disclosure is shown. Figure 6 As shown, the specific steps include S610~S660:

[0140] In step S610, for any of the axis objects, the communication state contained in the communication state variable of that axis object is read.

[0141] Specifically, within each preset EtherCAT bus control cycle, the system first accesses the communication status variable maintained internally by the specified axis object. This variable, which has been updated in previous cycles through steps S550 and S560, contains the axis-level communication status derived from connector diagnostic information. The system reads the enumerated value or status code stored in this variable. This value comprehensively reflects multi-dimensional information such as physical link quality, data exchange activity, synchronization status, and error statistics, representing the overall health and reliability of the real-time data exchange between the axis object and its corresponding stepper motor terminal module via the EtherCAT bus.

[0142] In step S620, it is determined whether the communication state is a normal communication state. If it is an abnormal communication state, step S630 is executed; if it is a normal communication state, step S640 is executed.

[0143] Specifically, the system performs logical judgments on the read communication status. The core of the judgment is to check whether the status belongs to a preset set of normal communication statuses. A normal status is usually defined as a stable link, periodic data updates without timeouts, and clock synchronization maintained without critical errors. If the judgment result is yes (i.e., the status value is within the normal range), the process proceeds to step S640 to continue subsequent status and security checks. If the judgment result is abnormal, it indicates that one or more faults such as communication link interruption, synchronization loss, or response timeout have been detected, and the process proceeds to step S630 to attempt to restore the communication connection.

[0144] In step S630, the EtherCAT bus connection function is called to establish an EtherCAT bus connection between any axis object and the corresponding stepper motor terminal module.

[0145] Specifically, when an abnormal communication status is detected, the system calls a dedicated EtherCAT bus connection function (or reconnection sequence). This function does not simply retry; instead, it performs a series of standardized recovery operations: first, it safely suspends the currently malfunctioning data exchange process; then, it attempts to reinitialize the communication protocol stack of the stepper motor terminal module corresponding to the faulty axis object, including renegotiating communication parameters, rebuilding the PDO mapping relationship, and finally reactivating the periodic data exchange service. This process aims to re-establish a stable and reliable EtherCAT bus logical connection between the specific axis object and its physical terminal module, while ensuring that communication with other normal nodes on the bus is not affected.

[0146] In step S640, the state variable of any axis object is detected to obtain the current state of the stepper motor terminal module corresponding to any axis object.

[0147] Specifically, after the communication status is confirmed to be normal, the system then checks the status variables of the axis object. These variables were updated in the "AfterReadInputs" method of the previous control cycle based on the status words read and parsed from the terminal module. Specifically, it checks the "enable status" flag mapped in the status variables, which represents whether the power section inside the terminal module is active. This check is to confirm that the terminal module hardware is ready to receive and execute motion commands, which is one of the important prerequisites for preventing "runaway" motion.

[0148] In step S650, it is detected whether the current state is an enabled state.

[0149] If the current state is disabled, then step S660 is executed; otherwise, the process ends normally.

[0150] Specifically, the system performs a Boolean check on the "enable state" flag obtained in step S640 to determine whether the terminal module is currently in an enabled state. If the detection result is "yes" (enable state is true), it means that the terminal module is in a controlled active state and can safely receive new position or speed commands. Therefore, the protection logic ends, allowing the normal motion control process to continue. If the detection result is "no" (enable state is false), it indicates that the power section of the terminal module is not turned on, and the motor is in a free state (can be manually pushed). If a new position setting value is sent to it at this time, once the terminal module is suddenly enabled, the motor may experience uncontrollable violent movement (i.e., "runaway"), so the protection logic in step S660 is executed.

[0151] In step S660, the overspeed protection logic operation is performed, including: reading the actual position in the actual position variable of the local PDO input address of any axis object, and writing the actual position into the target position variable of any axis object, so that the stepper motor driven by the stepper motor terminal module corresponding to any axis object does not move when the current enabled state is enabled.

[0152] Specifically, when a terminal module is detected as disabled, the system immediately executes the runaway protection logic. First, it reads the latest value from the "Actual Position Variable" in the axis object's local PDO input address mapping. This value represents the current true position of the stepper motor rotor (in pulses). Then, the system directly writes this read actual position value into the "Target Position Variable," which stores motion commands within the axis object. The core purpose of this operation is to force the "Target Position" and "Actual Position" to align instantaneously at the moment the terminal module is enabled. Therefore, when the terminal module is subsequently enabled, since there is no deviation between the setpoint and the feedback value, the position loop will not generate a speed correction command, ensuring the motor remains stationary at the moment of enable, without any unexpected movement, effectively preventing a runaway accident. After the protection action is completed, the process ends normally.

[0153] Figure 7 A flowchart illustrating a stepper motor driving method based on an EtherCAT bus according to an embodiment of the present disclosure is shown. The method is applied to an AI computer, which includes a CODESYS controller. The AI ​​computer is connected to one or more stepper motor terminal modules via an EtherCAT bus. The stepper motor terminal modules are used to control corresponding stepper motors and are connected to the corresponding stepper motors through their own set motor terminals. The stepper motor driving method includes the following steps S710~S730:

[0154] In step S710, a stepper motor drive command sent by the CODESYS controller is received. The stepper motor drive command includes a system configuration command and a positioning motion command.

[0155] In step S720, in response to the system configuration command, an axis object corresponding to each stepper motor terminal module is instantiated; an EtherCAT bus connector is bound to each axis object; the operating mode of each axis object is set to periodic synchronous position mode; for any axis object, based on the EtherCAT bus connector, the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to the any axis object are mapped to the local PDO input address and local PDO output address of the any axis object.

[0156] In step S730, in response to the positioning motion command, a target axis object corresponding to the positioning motion command is acquired. Within any control cycle, the actual parameters of the corresponding stepper motor are obtained from the local PDO input address of the target axis object, and the actual parameters are uploaded to the CODESYS controller so that the CODESYS controller obtains the corresponding target parameters based on the actual parameters. Within any control cycle, the target parameters are acquired. The target parameters are written to the local PDO output address of the target axis object so as to be sent to the corresponding stepper motor terminal module through the EtherCAT bus to realize the position control of the stepper motor.

[0157] Figure 8 This diagram illustrates a structural block diagram of a stepper motor drive device based on an EtherCAT bus according to an embodiment of the present disclosure. The stepper motor drive device is disposed in an AI computer, which includes a CODESYS controller. The AI ​​computer is connected to one or more stepper motor terminal modules via an EtherCAT bus. Each stepper motor terminal module controls a corresponding stepper motor and connects to the corresponding stepper motor through its own motor terminals. The stepper motor drive device includes: a stepper motor drive command receiving module configured to receive stepper motor drive commands sent by the CODESYS controller, the stepper motor drive commands including system configuration commands and positioning motion commands; and a system configuration command response module configured to: instantiate an axis object corresponding to each stepper motor terminal module in response to the system configuration command; bind an EtherCAT bus connector to each axis object; set the operating mode of each axis object to a periodic synchronous position mode; and, for any axis object, perform a positioning motion command based on the EtherCAT bus. The T-bus connector maps the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to any axis object to the local PDO input address and local PDO output address of any axis object, respectively. The positioning motion command response module is configured to, in response to the positioning motion command, acquire the target axis object corresponding to the positioning motion command; within any control cycle, acquire the actual parameters of the corresponding stepper motor from the local PDO input address of the target axis object, upload the actual parameters to the CODESYS controller so that the CODESYS controller obtains the corresponding target parameters based on the actual parameters; within any control cycle, acquire the target parameters; write the target parameters to the local PDO output address of the target axis object, so as to send them to the corresponding stepper motor terminal module via the EtherCAT bus to achieve position control of the stepper motor.

[0158] This disclosure implements the hardware driving function of the stepper motor in an intelligent machine built with the CODESYS software platform, and uses the EtherCAT bus for high-speed, deterministic communication. It provides a drive system that can seamlessly connect CODESYS and EtherCAT stepper terminal modules, so that motion control no longer depends on hardware combinations of specific brands, but is built on an open and universal computing and communication architecture. This reduces development difficulty and saves system costs, and accelerates the popularization and upgrading in application scenarios such as multi-axis EtherCAT stepper platforms, low-cost servo replacement of laboratory or teaching instruments and equipment, and smooth upgrade of old equipment pulse direction drivers to bus control.

[0159] Figure 9 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown. Figure 9 As shown, the electronic device includes a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method steps as described in any of the above method embodiments.

[0160] This disclosure also provides a computer-readable storage medium, which may be a computer-readable storage medium included in the electronic device or computer system described in the above embodiments; or it may be a standalone computer-readable storage medium not assembled into a device. The computer-readable storage medium stores one or more programs, which are used by one or more processors to perform the methods described in this disclosure.

[0161] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements any of the methods described in this disclosure.

[0162] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

Claims

1. A stepper motor drive system based on EtherCAT bus, characterized in that, The stepper motor drive system includes: an AI computer and one or more stepper motor terminal modules. The AI ​​computer includes a CODESYS controller and a stepper motor drive module. The AI ​​computer is connected to each stepper motor terminal module via an EtherCAT bus. The stepper motor terminal module is used to control the corresponding stepper motor and is connected to the stepper motor through its own motor terminals. The CODESYS controller is configured to: generate stepper motor drive instructions and send the stepper motor drive instructions to the stepper motor drive module. The stepper motor drive instructions include: system configuration instructions and positioning motion instructions. The stepper motor drive module is configured as follows: In response to the system configuration command, instantiate an axis object corresponding to each stepper motor terminal module; bind the EtherCAT bus connector to each axis object; set the operating mode of each axis object to periodic synchronous position mode; for any axis object, based on the EtherCAT bus connector, map the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to the axis object to the local PDO input address and local PDO output address of the axis object respectively; In response to the positioning motion command, a target axis object corresponding to the positioning motion command is acquired. Within any control cycle, the actual parameters of the corresponding stepper motor are obtained from the local PDO input address of the target axis object, and the actual parameters are uploaded to the CODESYS controller so that the CODESYS controller can obtain the corresponding target parameters based on the actual parameters. Within any control cycle, the target parameters are acquired; the target parameters are written to the local PDO output address of the target axis object so as to be sent to the corresponding stepper motor terminal module through the EtherCAT bus to realize the position control of the stepper motor.

2. The stepper motor drive system according to claim 1, characterized in that, The local PDO output address of the axis object contains a control word variable, and the stepper motor drive instructions further include motion control instructions. The stepper motor drive module is also configured to: Obtain the designated axis object corresponding to the motion control command, obtain control data based on the control data variables of the designated axis object, construct a control word according to the control data, and write the control word into the control word variable of the local PDO output address of the designated axis object, so as to send it to the stepper motor terminal module corresponding to the designated axis object through the EtherCAT bus.

3. The stepper motor drive system according to claim 2, characterized in that, The control data variables include: a first control data variable, a second control data variable, and a third control data variable. Obtaining control data based on the control data variables of the specified axis object includes: Based on the first control data variable of the specified axis object, the presence or absence of an enable command is detected, and first control data is generated according to the detection result; based on the second control data variable of the specified axis object, the presence or absence of a reset command is detected, and second control data is generated according to the detection result; based on the third control data variable of the specified axis object, the presence or absence of a torque reduction command is detected, and third control data is generated according to the detection result; wherein, the first control data, the second control data, and the third control data are all Boolean values; The step of constructing a control word based on the control data includes: sequentially concatenating the first control data, the second control data, and the third control data to generate the control word.

4. The stepper motor drive system according to claim 1, characterized in that, The local PDO input address of the axis object contains actual parameter variables, and the local PDO output address of the axis object contains target parameter variables. The actual parameters include actual position and actual speed, and the target parameters include target position and target speed. The step of obtaining the corresponding actual parameters of the stepper motor from the local PDO input address of the target axis object and uploading the actual parameters to the CODESYS controller includes: The actual parameters of the corresponding stepper motor are read from the actual parameter variables of the local PDO input address of the target axis object, so that the CODESYS controller can obtain the actual parameters of the stepper motor driven by the stepper motor terminal module corresponding to the target axis object through the callback function that returns the actual parameters; The step of obtaining the target parameter includes: reading the target parameter from the target data variable of the target axis object, wherein the target parameter is written to the target data variable of the target axis object by the CODESYS controller through a callback function; The step of writing the target parameter to the local PDO output address of the target axis object includes: writing the target parameter to the target parameter variable of the local PDO output address of the target axis object.

5. The stepper motor drive system according to claim 1, characterized in that, The local PDO input address of the axis object contains a status word variable, and the stepper motor drive module is further configured as follows: Within a preset control cycle, the status word variable of the local PDO input address of each axis object is polled to see if it has changed. For the axis object that has changed, the first bit of the status word variable of the local PDO input address of the axis object is used to determine whether the corresponding stepper motor terminal module is in an enabled state; the second bit of the status word variable of the local PDO input address of the axis object is used to determine whether the corresponding stepper motor terminal module is in an idle state; the third bit of the status word variable of the local PDO input address of the axis object is used to determine whether the corresponding stepper motor terminal module is in an alarm state; status information is generated based on the determination results, and the status information is updated in the status variable of the axis object, so that the CODESYS controller can obtain the current status information of the stepper motor terminal module corresponding to the axis object by reading the callback function of the status variable. The stepper motor drive module is further configured to: acquire the communication status variable of the EtherCAT bus connector, parse the communication status variable by calling the CODESYS function IoMgrConfigSetDiagnosis to obtain the communication status of the EtherCAT bus connector, acquire the communication status between each axis object and the corresponding stepper motor terminal module through the EtherCAT bus connector based on the communication status of the EtherCAT bus connector, update the communication status of each axis object to the communication status variable of each axis object, so that the CODESYS controller can obtain the communication status between each axis object and the corresponding stepper motor terminal module through the EtherCAT bus connector via a callback function.

6. The stepper motor drive system according to claim 5, characterized in that, The local PDO input address of the axis object contains actual parameter variables, including actual position variables and actual speed variables. The axis object contains target data variables and state variables, including target position variables. The stepper motor drive module is further configured to: Within a preset specified control cycle, the communication status contained in the communication status variable of each axis object is monitored, including: for any axis object, reading the communication status contained in the communication status variable of that axis object, determining whether the communication status is a normal communication status; if it is an abnormal communication status, calling the EtherCAT bus connection function to establish an EtherCAT bus connection between the axis object and the corresponding stepper motor terminal module; if it is a normal communication status, detecting the status variable of that axis object to obtain the current status of the stepper motor driven by the stepper motor terminal module corresponding to that axis object; when the current status is disabled, executing the overspeed protection logic operation, including: reading the actual position in the actual position variable of the local PDO input address of that axis object, writing the actual position into the target position variable of that axis object, so that the stepper motor driven by the stepper motor terminal module corresponding to that axis object has no movement when the current enabled status is enabled.

7. A stepper motor driving method based on EtherCAT bus, applied to industrial intelligent machines, characterized in that, The AI-powered machine includes a CODESYS controller. The AI-powered machine is connected to one or more stepper motor terminal modules via an EtherCAT bus. Each stepper motor terminal module is used to control a corresponding stepper motor and is connected to the corresponding stepper motor through its own set motor terminals. The stepper motor driving method includes: Receive stepper motor drive commands sent by the CODESYS controller, the stepper motor drive commands including: system configuration commands and positioning motion commands; In response to the system configuration command, instantiate an axis object corresponding to each stepper motor terminal module; bind the EtherCAT bus connector to each axis object; set the operating mode of each axis object to periodic synchronous position mode; for any axis object, based on the EtherCAT bus connector, map the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to the axis object to the local PDO input address and local PDO output address of the axis object respectively; In response to the positioning motion command, a target axis object corresponding to the positioning motion command is acquired. Within any control cycle, the actual parameters of the corresponding stepper motor are obtained from the local PDO input address of the target axis object, and the actual parameters are uploaded to the CODESYS controller so that the CODESYS controller can obtain the corresponding target parameters based on the actual parameters. Within any control cycle, the target parameters are acquired; the target parameters are written to the local PDO output address of the target axis object so as to be sent to the corresponding stepper motor terminal module through the EtherCAT bus to realize the position control of the stepper motor.

8. A stepper motor drive device based on EtherCAT bus, installed in an industrial intelligent machine, characterized in that, The AI ​​device includes a CODESYS controller. The AI ​​device is connected to one or more stepper motor terminal modules via an EtherCAT bus. Each stepper motor terminal module controls a corresponding stepper motor and connects to the corresponding stepper motor through its own motor terminals. The stepper motor drive device includes: The stepper motor drive command receiving module is configured to receive stepper motor drive commands sent by the CODESYS controller, the stepper motor drive commands including system configuration commands and positioning motion commands; The system configuration command response module is configured to: in response to the system configuration command, instantiate an axis object corresponding to each stepper motor terminal module; bind an EtherCAT bus connector to each axis object; set the operating mode of each axis object to a periodic synchronous position mode; and for any axis object, map the bus PDO input address and bus PDO output address of the stepper motor terminal module corresponding to that axis object to the local PDO input address and local PDO output address of that axis object based on the EtherCAT bus connector. The positioning motion command response module is configured to respond to the positioning motion command by acquiring the target axis object corresponding to the positioning motion command, obtaining the actual parameters of the corresponding stepper motor from the local PDO input address of the target axis object within any control cycle, uploading the actual parameters to the CODESYS controller so that the CODESYS controller can obtain the corresponding target parameters based on the actual parameters; acquiring the target parameters within any control cycle; and writing the target parameters to the local PDO output address of the target axis object so as to send them to the corresponding stepper motor terminal module through the EtherCAT bus to realize the position control of the stepper motor.

9. An electronic device, characterized in that, It includes a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method of claim 7.

10. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the computer instructions are executed by the processor, they implement the method of claim 7.

Images