Servo self-tuning method and device based on large model agent

Abstract

The application discloses a servo self-tuning method and equipment based on a large model intelligent agent. The method comprises the following steps: presetting a tuning rule template and accessing a servo debugging interface; combining servo self-tuning requirements, device states, current parameters and historical tuning records to form model inputs; determining parameter adjustment through a large model, performing running sampling and collecting performance indicators; comparing the collected results with historical stable parameter records to form adjustment decisions; performing parameter rollback and verification when performance degradation or alarms occur; and iteratively circulating until the tuning target is reached or the iteration upper limit is reached. The method adopts a hierarchical tuning mechanism, establishes historical stable parameter record anchor points, and combines a forced rollback and verification mechanism to effectively solve the problems of easy divergence and low safety in automatic tuning in the prior art, thereby improving the convergence stability and safety of servo system parameter tuning. The application also provides a device, a storage medium and a computer program product for implementing the above method.

Description

Technical Field

[0001] This application relates to the fields of servo drive control and artificial intelligence technology, and in particular to a servo self-tuning method and device based on a large model intelligent agent. Background Technology

[0002] Servo system parameter tuning refers to adjusting the control parameters of the servo driver, such as gain, filtering, feedforward, and inertia, so that the motor and its load can obtain comprehensive dynamic performance that meets the requirements of positioning accuracy, response time, and vibration suppression under specific working conditions.

[0003] In some related technologies, besides relying on engineers' manual trial and error based on experience, automatic parameter tuning is usually achieved using a fixed self-tuning algorithm built into the driver or by introducing traditional heuristic optimization algorithms. In recent years, with the development of intelligent technology, automated tuning schemes have also emerged that utilize intelligent algorithm models to automatically output the next round of parameter adjustment commands by analyzing the equipment's operational feedback data.

[0004] However, servo parameters are strongly physically coupled, and the tuning process is essentially a closed-loop trial-and-error process involving multiple rounds of "write-run-evaluate-readjust". In actual industrial settings, a single parameter change may improve a certain indicator (such as shortening response time) while triggering overshoot, mechanical resonance, or even directly causing drive alarms. Related technologies often focus on calculating the optimal search direction for the next step based on the current state, but when faced with inevitable performance degradation or sudden failures during multiple rounds of trial and error, they lack effective anchoring and strict recovery verification mechanisms based on historical stable operating states. This leads to the automation process easily losing its safety baseline when encountering abnormal or deteriorated parameter combinations, and then continuing to make ineffective attempts based on the deteriorated state, even continuously issuing commands when the equipment is in a high-risk state. This makes it prone to divergence or stagnation under complex operating conditions, resulting in low on-site tuning efficiency and the risk of equipment damage. Summary of the Invention

[0005] This application provides a servo self-tuning method and device based on a large model intelligent agent, which can improve the efficiency of on-site tuning.

[0006] Firstly, this application provides a servo self-tuning method based on a large model intelligent agent. The method includes: pre-setting a tuning rule template in servo debugging software to define the tuning stage and allow adjustment actions, and connecting to a parameter reading interface, a parameter writing interface, a running sampling interface, and a status reading interface; receiving a servo self-tuning requirement containing the tuning target, reading the device status, current parameters, and historical tuning records of the servo device to be tuned, and combining the servo self-tuning requirement, device status, current parameters, historical tuning records, and tuning rule template into a model input; sending the model input to a large model, and performing parameter adjustment and running sampling on the large model corresponding to the current tuning stage: calling the parameter writing interface to write the corresponding parameter values, and calling the running sampling interface to perform running sampling, collecting tuning time, overshoot, oscillation count, and total error. At least one of the vibration frequency and alarm status is used as the acquisition result; the acquisition result is compared with the stable parameter record in the historical tuning record to obtain the comparison result, and a decision to continue adjustment, a stage switching decision, or a parameter rollback decision is formed based on the comparison result. The stable parameter record saves the parameter value, tuning time, and overshoot corresponding to the most recent stable operation; in response to the parameter rollback decision or alarm status, the parameter write interface is called to write back the parameter value corresponding to the stable parameter record, and the parameter read interface is called to read the written back parameter value for verification to obtain the verification result; if the tuning target is not reached, the acquisition result, comparison result, and verification result are written to the historical tuning record and sent to the large model again, and the parameter adjustment and running sampling, comparison, and verification are repeated until the tuning target is reached or the preset iteration limit is reached, and the tuning result is output.

[0007] This embodiment constructs a closed-loop iterative mechanism anchored by historical stable parameter records. Comprehensive information, including equipment status and rule constraints, is input into a large model to guide parameter adjustments. By comparing real-time acquisition results with a stable benchmark, parameter rollback is forcibly triggered when performance degradation or alarms occur. This is coupled with readback verification to confirm parameter recovery, preventing the large model from continuously outputting high-risk commands in a deteriorated state. This ensures a reliable rollback path throughout the tuning process, improving the safety and convergence stability of automated tuning under complex operating conditions.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the tuning rule template sets a coarse tuning stage and a fine tuning stage, and respectively limits the parameter categories that can be written in the coarse tuning stage and the fine tuning stage; the mechanical stiffness level is written in the coarse tuning stage, and the gain parameter or feedforward parameter is written in the fine tuning stage; when no alarm state appears in the continuous acquisition results and the tuning time enters the preset range, the stage switching command is executed.

[0009] This embodiment defines reasonable action boundaries for the large model at different stages by dividing the tuning rule template into coarse and fine tuning stages, thus avoiding blind exploration in the fine parameter space in the early stage and improving the guidance and iterative efficiency of the parameter optimization process.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the acquisition result includes a resonant frequency; when the resonant frequency falls into a preset frequency band, the continued adjustment instruction includes a notch filter parameter writing instruction; after completing the parameter writing corresponding to the notch filter parameter writing instruction, the running sampling is performed again, and the new resonant frequency is written into the historical tuning record.

[0011] This embodiment integrates resonant frequency monitoring into the operational sampling process, proactively intervening when encountering structural resonance risks to prevent the large model from misjudging resonance-induced oscillations as normal control performance degradation, thus ensuring the continuity and safety of the tuning process when facing mechanical resonance interference.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the stable parameter record stores the parameter value, settling time, and overshoot in the absence of an alarm; when the settling time of the current acquisition result is longer than the settling time corresponding to the stable parameter record, the overshoot of the current acquisition result is greater than the overshoot corresponding to the stable parameter record, or an alarm state occurs, a parameter rollback command is executed; when the current acquisition result does not have an alarm state and the settling time is shorter than the settling time corresponding to the stable parameter record, the stable parameter record is refreshed.

[0013] This embodiment establishes a strict monotonic improvement evaluation benchmark. Based on the comparison and backoff logic of the global optimal state, it ensures that the evolution trajectory of the parameters always develops in the direction of dynamic performance improvement, avoids the accumulation of small performance degradation in multiple iterations, and improves the quality of the final tuning result.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes accessing a reset interface; when running sampling fails, the servo device to be tuned is not ready, or an alarm state occurs, closing the parameter writing interface and the running sampling interface, and retaining only the status reading interface and the reset interface; after the status reading interface returns to a runnable state, restoring the parameter writing interface and the running sampling interface.

[0015] This embodiment introduces an anomaly gating mechanism, which cuts off the path for sending control commands at the physical logic level and only reopens the interface after the device status is confirmed to have returned to normal. This avoids receiving new adjustment actions when the driver is in an abnormal response period, thereby improving the operational safety of the device under fault conditions.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, the historical tuning record saves tool call messages, collection results, stable parameter records, and the current tuning stage by round; when the number of rounds exceeds a preset threshold, the starting round record, the latest stable parameter record, and the most recent preset number of round records are retained; when the tuning process continues, the retained historical tuning record is read and the corresponding current tuning stage is continued to be executed.

[0017] This embodiment adopts a round-by-round pruning strategy. This structured data retention method removes invalid trial and error records in the middle while maintaining the core optimization trajectory and safety anchor points. This allows the large model to seamlessly restore the current tuning stage based on a concise and critical historical context when the tuning process is interrupted and resumed, thus improving the system's ability to handle long-cycle debugging tasks and its continuity.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, the servo self-tuning requirement indicates an internal instruction mode or a host computer instruction mode; in the internal instruction mode, the inertia identification interface is called and the motion parameters are provided by the servo device to be tuned; in the host computer instruction mode, the host computer motion parameter reading interface is called and the read load inertia ratio and motion parameters are used to perform operation sampling.

[0019] This embodiment distinguishes between internal instruction mode and host computer instruction mode, dynamically selecting whether to perform inertia identification and motion generation internally by the driver, or to read the actual load inertia ratio and motion parameters from the host computer software to drive the sampling operation. This makes the test conditions of the tuning process match the actual field working environment of the servo driver, avoiding performance deviations between offline testing and online operation, and improving the applicability of the tuning results under different device control architectures.

[0020] In a second aspect, embodiments of this application provide a servo self-tuning device, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the servo self-tuning device to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a servo self-tuning device, cause the servo self-tuning device to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a servo self-tuning device, cause the servo self-tuning device to perform the method described in the first aspect and any possible implementation thereof.

[0023] It is understood that the servo self-tuning device provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. This application constructs a closed-loop iterative mechanism anchored by historical stable parameter records. When performance degradation or alarm occurs, parameter rollback and readback verification are forcibly triggered, which avoids the large model from continuously outputting high-risk instructions in a deteriorated state. This provides a reliable retreat path for the tuning process and improves safety and convergence stability.

[0026] 2. This application integrates resonant frequency monitoring into the operational sampling process, proactively intervenes and writes notch filter parameters when encountering structural resonance risks, preventing the large model from misjudging the oscillations caused by resonance as a degradation of conventional control performance, and ensuring the continuity and safety of the tuning process when facing mechanical resonance interference.

[0027] 3. This application introduces an abnormal gating mechanism to cut off the control command transmission path when the operation fails or an alarm occurs, and only reopens the interface after the device status is confirmed to have returned to normal. This avoids receiving new adjustment actions when the driver is in an abnormal response period, and effectively improves the operational safety of the device under fault conditions. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the overall system architecture of an embodiment of this application;

[0029] Figure 2 This is another flowchart illustrating the servo self-tuning method in the embodiments of this application;

[0030] Figure 3 This is a sequence diagram showing the interaction between the AI ​​Agent, the large model, and the dedicated MCP tool in the embodiments of this application;

[0031] Figure 4 This is a schematic diagram illustrating the decision mapping between the tuning performance feedback index and the parameter adjustment direction in the embodiments of this application;

[0032] Figure 5This is a schematic diagram of the physical device structure of a servo self-tuning device in the embodiments of this application. Detailed Implementation

[0033] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0034] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0035] like Figure 1 As shown, the system provided in this embodiment of the invention includes a user 10, servo debugging software 20, a large model 30, and a servo driver 40. The servo debugging software 20 has a built-in AI Agent 21, system prompts 22, and a dedicated MCP toolset 23; the servo driver 40 is connected to a motor and a load 50. The AI ​​Agent 21 is responsible for receiving self-tuning requests from the user 10, assembling requests sent to the large model 30, parsing and executing tool calls returned by the large model 30, and controlling the entire closed-loop iterative process; the system prompts 22 predefine the complete process and constraint rules for servo self-tuning; the dedicated MCP toolset 23 interfaces with the servo debugging software 20 to operate the servo driver 40, and is used to read and write driver parameters and collect operational feedback data.

[0036] In one embodiment, the dedicated MCP toolset 23 includes, but is not limited to, the following tools:

[0037] (a) A tool for obtaining connected servo devices, used to return a list of currently connected servo devices and their device identifiers;

[0038] (b) A tool for reading servo parameters, used to read the current values ​​of all or specified function code parameters in the servo driver 40;

[0039] (c) A tool for writing servo parameters, used to write one or more parameters and their values ​​to a specified servo driver 40;

[0040] (d) An inertia identification tool used to identify and return the load rotational inertia ratio of the servo system;

[0041] (e) A tool for setting the mechanical stiffness level, used to set a self-adjusting mechanical stiffness level (e.g., 0 to 31).

[0042] (f) Tools for running, sampling and analyzing tuning performance (such as Jog running and sampling tool, trigger oscilloscope sampling tool) are used to drive the motor to run, sample the running process, and analyze tuning performance indicators such as return tuning time, overshoot, number of oscillations, resonant frequency, whether there is an alarm, and whether there is severe vibration.

[0043] (g) A tool for obtaining servo status, used to return the operating status (e.g., not ready, ready, running, fault), emergency stop status and fault codes of servo driver 40;

[0044] (h) A tool for resetting the servo, used to reset the state of the servo driver 40 after a servo alarm.

[0045] In one embodiment, the dedicated MCP tool and the servo debugging software 20 communicate using the Model Context Protocol (MCP). The servo debugging software 20 has a built-in MCP server, which registers the aforementioned tools as callable MCP tools and provides services externally via streamable HTTP. The AI ​​Agent, acting as an MCP client, obtains the tool list and initiates tool calls through the MCP protocol. Thus, the large model 30 only needs to output the decision of "which tool to call and which parameters to pass in," which is then implemented by the AI ​​Agent via the MCP tool into actual read / write and sampling operations on the servo driver 40.

[0046] The following is combined with Figure 2 and Figure 3 The closed-loop iterative process of the servo self-tuning method according to embodiments of the present invention will be described in detail below. Please refer to [link to relevant documentation]. Figure 2 This is a flowchart illustrating a servo self-tuning method in an embodiment of this application.

[0047] S201. In the servo debugging software, preset the tuning rule template for limiting the tuning stage and allowing adjustment actions, and connect to the parameter reading interface, parameter writing interface, running sampling interface and status reading interface.

[0048] Specifically, such as Figure 1As shown, the system provided in this embodiment includes a user terminal, servo debugging software 20, a large model service, and a servo driver 40. The servo debugging software 20 runs on a personal computer or industrial control computer and has pre-installed tuning rule templates and a tool interface layer. The tuning rule templates are used to divide the complete servo self-tuning process into several tuning stages and define the types of adjustment actions allowed in each stage. For example, in one stage, only rigidity level writing is allowed, while gain fine-tuning is not; in another stage, only gain parameter or feedforward parameter writing is allowed, without rigidity level adjustment. The tuning rule templates also include constraints and exit criteria for each stage, ensuring clear switching logic between different stages of the tuning process.

[0049] In a specific embodiment, the tuning rule template is defined using a structured JSON or XML data format, which contains multiple stage nodes. Each stage node specifically contains the following special data structure fields: (1) Stage ID; (2) Allowed Actions, which strictly limits the range of dedicated MCP tools and parameter function codes that can be called in the current stage, such as limiting the modification of gain parameters from 0x01 to 0x05 in the fine-tuning stage; (3) Parameter Bounds, which defines the physical safety upper and lower limits of each parameter and the maximum single adjustment step size (such as a single gain increase not exceeding 10% of the current value); (4) Exit Conditions, which contain logical expressions (such as the tuning time fluctuation being less than 5% for three consecutive rounds and without overshoot). This special data structure provides switching logic for the tuning process and defines a safety boundary for the large model 30 at the physical logic level. It transforms the hardware capacity of the servo driver 40 into mathematical and logical constraints that the large model 30 can resolve, preventing it from outputting parameter combinations that could damage the device under "illusion".

[0050] The parameter reading interface is used to read the current values ​​of all or specified function code parameters from the servo driver 40; the parameter writing interface is used to write one or more parameters and their values ​​to the servo driver 40; the run sampling interface is used to trigger the servo driver 40 to run according to given motion parameters and to perform oscilloscope sampling and performance tuning analysis on the running process; the status reading interface is used to obtain the current running status of the servo driver 40, including status information such as servo ready, running, fault, emergency stop, and fault codes. These interfaces connect to the existing communication channels of the servo debugging software 20 to operate the servo driver 40, enabling the parameter adjustment commands output by the subsequent large model 30 to be implemented as actual read, write, and sampling operations on the servo driver 40 through these interfaces.

[0051] S202. Receive the servo self-tuning request containing the tuning target, read the device status, current parameters and historical tuning records of the servo device to be tuned, and combine the servo self-tuning request, device status, current parameters, historical tuning records and tuning rule template into model input.

[0052] Specifically, user 10 inputs servo self-tuning requirements to servo debugging software 20 through dialogue or interface interaction. These requirements include tuning targets, such as target tuning time, allowable overshoot range, positioning accuracy requirements, etc., and may also include motion condition information such as device type, direction of motion, running speed, acceleration and deceleration time, target position, etc.

[0053] After receiving the above request, the servo debugging software 20 calls the status reading interface to obtain the current device status of the servo device to be tuned, including whether the servo is ready, whether there are alarms or faults, etc.; then it calls the parameter reading interface to obtain the parameter values ​​currently written to the servo driver 40; and then it reads the historical tuning record corresponding to the device, which stores the tool call messages, acquisition results and stable parameter records of each round in the previous period.

[0054] The servo debugging software 20 then combines the servo self-tuning requirements, device status, current parameters, historical tuning records, and tuning rule templates to form a structured model input. Furthermore, to enable the general large model 30 to deeply understand the physical meaning of the servo parameters and the complex coupling relationships, the model input also includes pre-constructed system prompts.

[0055] The system prompts specifically include: role definition, setting the large model 30 as a servo debugging expert with senior industrial field experience; a servo physics prior knowledge base, injecting the mapping relationship between servo control theory and common physical phenomena into the large model 30 in text form, such as clearly prompting underlying mechanisms such as "excessive speed loop gain can easily lead to high-frequency mechanical oscillation", "position loop gain needs to maintain a specific ratio with speed loop gain (such as less than 1 / 3 of speed loop gain) to avoid overshoot", and "load inertia ratio mismatch will reduce system response bandwidth and cause low-frequency jitter"; and MCP tool call format specification, strictly defining the JSON format output by the large model 30, requiring it to include the thought process (Thought), the tool name (Tool_Name), and the tool parameters (Arguments).

[0056] Through the aforementioned engineering of prompt words incorporating prior knowledge of physics and strict format constraints, the model input not only enables the large model 30 to learn about equipment status, parameter baselines, and action boundaries, but also transforms the "expert experience" that is difficult to quantify in traditional manual debugging into contextual logic that the large model 30 can understand. This effectively bridges the semantic gap between natural language processing and industrial low-level control commands, enabling the large model 30 to no longer perform blind random searches, but to make targeted parameter adjustment decisions based on control theory, just like a human engineer.

[0057] S203. Send the model input to the large model and perform parameter adjustment and running sampling for the large model corresponding to the current tuning stage: call the parameter writing interface to write the corresponding parameter values, call the running sampling interface to perform running sampling, and collect at least one of the following as the sampling result: tuning time, overshoot, number of oscillations, resonance frequency and alarm status.

[0058] Specifically, such as Figure 3 As shown, the servo debugging software 20 sends the aforementioned model input to the large model 30. The large model 30, based on the current tuning stage defined by the tuning rule template in the model input, as well as the tuning target, equipment status, and historical tuning records, infers the direction of parameter adjustment to be executed and outputs the parameter adjustment command corresponding to the current tuning stage. The servo debugging software 20 parses this parameter adjustment command and calls the parameter writing interface to write the corresponding parameter value to the servo driver 40. For example, in the coarse tuning stage, it writes the stiffness level value, and in the fine tuning stage, it writes the speed loop gain value or position loop gain value. After the parameter writing is completed, the servo debugging software 20 calls the run sampling interface to trigger the servo driver 40 to execute according to the given motion parameters and samples oscilloscope data during the run. The run sampling interface analyzes and processes the sampled data, collecting at least one of the following as the sampling result for this round: tuning time, overshoot, number of oscillations, resonant frequency, and alarm status.

[0059] Among them, the set time is the time it takes for the motor to enter the positioning error zone and remain stable from the start of movement; the overshoot is the maximum deviation of the motor position from the target position; the number of oscillations is the number of times the motor crosses the target position during the positioning process; the resonance frequency is the abnormal peak frequency that appears in the sampling spectrum; and the alarm status is whether the servo driver 40 triggers overcurrent, overvoltage, overload and other protections during operation.

[0060] S204. Compare the collected results with the stable parameter records in the historical tuning records to obtain the comparison results, and make decisions on continued adjustment, stage switching, or parameter rollback based on the comparison results.

[0061] Specifically, such as Figure 4As shown, the servo debugging software 20 compares the current round of acquisition results with the stable parameter records saved in the historical tuning records to obtain the comparison results. The stable parameter records save the parameter values, tuning time, and overshoot corresponding to the most recent stable operation; that is, in previous iterations, the parameter snapshot recorded when no alarm occurred and the tuning performance did not degrade. The comparison includes: whether the tuning time in the current round of acquisition results is shorter or longer than the tuning time corresponding to the stable parameter records; whether the overshoot in the current round is greater or less than the overshoot corresponding to the stable parameter records; and whether an alarm occurred in the current round.

[0062] Based on the above comparison results, the servo debugging software 20 makes one of three decisions: if the current acquisition result is better than the stable parameter record and the tuning target has not yet been reached, a decision to continue adjustment is made, indicating that parameter optimization will continue in the current direction within the current tuning stage; if the current acquisition result meets the exit criteria for the current tuning stage, a stage switching decision is made, indicating that the current tuning stage will be entered into the next tuning stage; if the current acquisition result is worse than the stable parameter record or an alarm occurs, a parameter rollback decision is made, indicating that the parameters need to be restored to the parameter values ​​corresponding to the stable parameter record. This decision mapping mechanism ensures that the tuning process has a clear safety benchmark as a reference after each iteration, avoiding continued adjustment in the wrong direction after performance degradation.

[0063] S205. In response to parameter rollback decision or alarm status, call the parameter write interface to write back the parameter value corresponding to the stable parameter record, and call the parameter read interface to read the written back parameter value for verification to obtain the verification result.

[0064] Specifically, when a parameter rollback decision is made, or when an alarm state occurs in the current round of data acquisition, the servo debugging software 20 performs parameter rollback and verification operations. The servo debugging software 20 calls the parameter write interface to write the parameter values ​​saved in the stable parameter record back to the servo driver 40, restoring the control parameters of the servo driver 40 to the state of the most recent stable operation. After the write-back is complete, the servo debugging software 20 further calls the parameter read interface to read the written-back parameter values ​​from the servo driver 40, and compares the read parameter values ​​with the parameter values ​​saved in the stable parameter record item by item to confirm whether the parameter rollback has been correctly implemented, thus obtaining the verification result.

[0065] This verification step is included because in real-world industrial environments, communication interruptions, write timeouts, or internal protection logic of the driver can all cause the parameter write-back operation to fail to execute completely. Without read-back verification, subsequent tuning processes may continue based on an incorrect parameter baseline, leading to more serious performance deviations or equipment risks. Through the aforementioned rollback and verification mechanism, the tuning process can always return to a known safe state in the event of performance degradation or anomalies, and confirm that this safe state has indeed been correctly restored.

[0066] S206. If the tuning target is not reached, the collected results, comparison results and verification results are written into the historical tuning record and sent to the large model again. The parameter adjustment and sampling, comparison and verification are repeated until the tuning target or the preset iteration limit is reached, and the tuning result is output.

[0067] Specifically, such as Figure 2 As shown, after the acquisition, comparison, and verification results of this round are generated, if the tuning target has not yet been reached, the servo debugging software 20 writes the above three results into the corresponding current round in the historical tuning record, and recombines the updated historical tuning record with the tuning rule template, device status, etc., into model input, and sends it to the large model 30 again. The large model 30 performs inference again based on the updated model input, outputs the parameter adjustment instructions for the next round, and the servo debugging software 20 executes the closed-loop process of parameter writing, running sampling, comparison, and verification again.

[0068] The aforementioned closed-loop iteration proceeds continuously in the manner of "writing parameters—running sampling—comparing and evaluating—back-off verification—readjusting," gradually approaching the tuning target. When the acquired results meet all the requirements specified in the tuning target, such as tuning time, overshoot, and vibration suppression, the iteration ends and the tuning result is output; or, when the number of iterations in the closed loop reaches the preset iteration limit (e.g., no more than 30 iterations), even if the tuning target has not been fully achieved, the iteration terminates and the current optimal tuning result is output to avoid the impact of prolonged debugging on on-site production. The output tuning result includes the final parameter values ​​written to the servo driver 40 and the corresponding tuning performance indicators.

[0069] In one embodiment, the tuning rule template sets a coarse tuning stage and a fine tuning stage, and limits the parameter categories that can be written in the coarse tuning stage and the fine tuning stage respectively; the mechanical stiffness level is written in the coarse tuning stage, and the gain parameter or feedforward parameter is written in the fine tuning stage; when no alarm state appears in the continuous acquisition results and the tuning time enters the preset range, the stage switching command is executed.

[0070] Specifically, the tuning rule template divides the tuning process into two stages: a coarse-tuning stage and a fine-tuning stage. In the coarse-tuning stage, the tuning rule template limits the allowed parameter categories to mechanical stiffness levels. During this stage, the parameter adjustment commands of the large model 30 can only target changes in stiffness levels. By intelligently searching within the stiffness level range (e.g., 0 to 31 levels), the tuning target is approximated level by level, rapidly shortening the tuning time with larger step sizes. In the fine-tuning stage, the tuning rule template limits the allowed parameter categories to gain parameters or feedforward parameters, such as velocity loop proportional gain, velocity loop integral time constant, position loop gain, or position feedforward coefficient. During this stage, the large model 30 performs small-scale adjustments to these parameters to further optimize the tuning time and overshoot based on the coarse-tuning.

[0071] The criterion for stage switching is as follows: if no alarm occurs in several consecutive rounds of data collection, and the tuning time has entered a preset range (i.e., the tuning time is below a certain upper threshold but has not yet met the final target, or the improvement margin of continued coarse tuning has approached saturation), then a stage switching decision is executed, switching from the coarse tuning stage to the fine tuning stage. This two-stage strategy allows the tuning process to approach the target range with high efficiency in the early stages and to perform refined optimization with high accuracy in the later stages, avoiding blind large-scale searches in the fine tuning parameter space.

[0072] In one embodiment, the acquisition result includes the resonant frequency; when the resonant frequency falls into the preset frequency band, the continued adjustment instruction includes a notch filter parameter writing instruction; after completing the parameter writing corresponding to the notch filter parameter writing instruction, the running sampling is performed again, and the new resonant frequency is written into the historical tuning record.

[0073] Specifically, during the sampling process, the sampling interface performs spectral analysis on the sampled data. When an abnormal peak with concentrated energy appears in the spectrum, the frequency corresponding to the peak is written as the resonance frequency into the acquisition result. When the resonance frequency in the current round of acquisition results falls into the preset frequency band (i.e., falls into the typical frequency range of mechanical resonance of the servo system), it indicates that there is a risk of mechanical resonance under the current parameter combination. At this time, the adjustment decision includes the notch filter parameter writing instruction, that is, the next round of parameter adjustment instruction output by the large model 30 is to set the notch filter to suppress the resonance frequency.

[0074] According to the instruction, the servo debugging software 20 calls the parameter writing interface to set the center frequency of the notch filter to the detected resonant frequency, and sets the corresponding notch width and notch depth. After the notch filter parameters are written, the servo debugging software 20 calls the running sampling interface again to perform running sampling, to check whether the resonance has been effectively suppressed, and writes the resonant frequency in the new round of sampling into the historical tuning record for reference in subsequent iterations. If the resonant frequency in the new acquisition result no longer falls within the preset frequency band, it indicates that the notch filter setting is effective, and the tuning process continues to execute subsequent parameter optimization according to the normal logic of the current tuning stage.

[0075] In one embodiment, the stable parameter record stores the parameter values, settling time, and overshoot in the absence of alarms. When the settling time of the current acquisition result is longer than the settling time corresponding to the stable parameter record, the overshoot of the current acquisition result is greater than the overshoot of the stable parameter record, or an alarm occurs, a parameter rollback command is executed. When the current acquisition result does not have an alarm and the settling time is shorter than the settling time corresponding to the stable parameter record, the stable parameter record is refreshed.

[0076] Specifically, the stability parameter record serves as a safety benchmark during the tuning process. It stores the servo drive's 40 parameter values, corresponding tuning time, and overshoot in an alarm-free state. The updating and use of the stability parameter record follows this logic:

[0077] When the tuning time in the current round of data acquisition is longer than the tuning time saved in the stable parameter record, it indicates that the parameter adjustment in this round has led to a degradation in tuning performance, and a parameter rollback decision should be made.

[0078] When the overshoot in the current round of data acquisition is greater than the overshoot recorded in the stable parameter record, it indicates that the parameter adjustment in this round has led to a worsening of the overshoot, and the parameter rollback decision is executed accordingly.

[0079] When an alarm occurs in the current data collection, parameter rollback decision will be executed regardless of changes in the setting time and overshoot.

[0080] In all three scenarios described above, parameter rollback and readback verification are performed as described in step S205. Conversely, if no alarm occurs in the current round of data acquisition and the tuning time is shorter than the tuning time saved in the stable parameter record, it indicates that the current round of parameter adjustment has brought about positive improvement. In this case, the parameter values, tuning time, and overshoot of the current round are refreshed and written into the stable parameter record, ensuring that the stable parameter record always points to the currently known optimal stable state. Throughout the above tuning process, a verified safety parameter anchor point is maintained to ensure that a reliable recovery to the known good state can be achieved after any round of adjustment failure.

[0081] In one embodiment, when the sampling operation fails, the servo device to be tuned is not ready, or an alarm occurs, the parameter writing interface and the sampling operation interface are closed, and only the status reading interface and the reset interface are retained; after the status reading interface returns to the runnable state, the parameter writing interface and the sampling operation interface are restored.

[0082] Specifically, during the tuning process, when the running sampling interface returns a running failure (e.g., the motor fails to complete the movement as instructed), when the status reading interface returns that the servo device to be tuned is not ready (e.g., the servo enable is not established or is in an emergency stop state), or when an alarm state appears in the acquisition results (e.g., overcurrent alarm, overload alarm, encoder failure, etc.), the servo debugging software 20 enters an abnormal gating state.

[0083] In this state, the servo debugging software 20 disables the parameter writing interface and the run sampling interface, meaning that no parameter writing operations or run trigger operations are allowed to be performed on the servo driver 40. Only the status reading interface and the reset interface remain available. The status reading interface is used to continuously monitor the status changes of the servo driver 40, and the reset interface is used to perform a fault reset operation on the servo driver 40 after confirming safe conditions. When the device status returned by the status reading interface becomes runnable again (i.e., the servo is ready and there are no alarms or emergency stops), the servo debugging software 20 restores the availability of the parameter writing interface and the run sampling interface, and the tuning process can continue. This anomaly gating mechanism ensures that no high-risk parameter writing or run trigger commands are sent to the servo driver 40 when the device is in an abnormal operating state, thereby ensuring the safety of the equipment and personnel during the tuning process.

[0084] In one embodiment, the historical tuning record saves tool call messages, collection results, stable parameter records, and the current tuning stage by round; when the number of rounds exceeds a preset threshold, the starting round record, the latest stable parameter record, and the most recent preset number of round records are retained; when the tuning process continues, the retained historical tuning record is read and the corresponding current tuning stage is continued to be executed.

[0085] Specifically, historical tuning records are organized and saved by round. Each round contains the tool call messages executed in that round (i.e., which interface was called and which parameters were passed in), the collection results of that round (i.e., the tuning performance indicators obtained after running the sampling), the stable parameter record snapshot at the end of that round, and the current tuning stage identifier of that round.

[0086] like Figure 3As shown, the above information is recorded in the form of structured messages, rather than plain text, enabling the large model 30 to accurately identify the operation content and results of each round when receiving historical tuning records. When the number of rounds generated by the closed-loop iteration exceeds a preset threshold, the historical tuning records are pruned to control the length of the context sent to the large model 30: the starting round record (containing the initial device state and initial parameter baseline of the tuning process), the latest stable parameter record (containing the currently known optimal safety state), and the most recent preset number of round records (containing the adjustment direction and acquisition results of the most recent rounds) are retained, while detailed records of intermediate rounds are discarded. When the tuning process needs to be resumed due to dialogue interruption, software reconnection, or user pause, the servo debugging software 20 reads the retained historical tuning records, restores the current tuning stage identifier and stable parameter record from them, and continues to execute the corresponding current tuning stage, instead of starting the entire tuning process from the beginning.

[0087] In one embodiment, the servo self-tuning requirement indicates either internal command mode or host computer command mode; in internal command mode, the inertia identification interface is called and motion parameters are provided by the servo device to be tuned; in host computer command mode, the host computer motion parameter reading interface is called and the read load inertia ratio and motion parameters are used to perform operation sampling.

[0088] Specifically, servo self-tuning supports two operating modes. When user 10 inputs servo self-tuning requirements, they can select either internal command mode or host computer command mode. In internal command mode, motion is generated internally by the servo driver 40. The servo debugging software 20 calls the inertia identification interface to trigger the servo driver 40 to perform the inertia identification process to obtain the load inertia ratio. Motion parameters (including motion direction, running speed, acceleration and deceleration time, target position, etc.) are provided internally by the servo driver 40 based on the inertia identification results and preset configuration. During the tuning process, the running sampling interface transmits the above motion parameters to the servo driver 40 to trigger operation.

[0089] In host computer command mode, motor movement is controlled by host computer software (such as a PLC program or motion control card). The servo driver 40 itself does not generate motion commands. In this case, the servo debugging software 20 calls the host computer motion parameter reading interface to sample and obtain the load inertia ratio and actual motion parameters from the host computer software. During the tuning process, the read load inertia ratio and motion parameters are used to perform running sampling. The difference between the two modes lies in the source of motion commands and the method of inertia acquisition, but the subsequent parameter adjustment, acquisition comparison, backtracking verification, and closed-loop iteration logic remain consistent. The large model 30 selects the corresponding interface call method for tuning according to the mode category indicated in the model input and the rules of the corresponding mode in the tuning rule template.

[0090] It should be noted that the large model 30 described in this invention can be various large language models deployed locally or in the cloud; the servo debugging software 20 described in this invention can run on a personal computer, an industrial control computer, or a dedicated debugging device; this invention does not limit the specific servo driver 40 model, motor type, or parameter function code number. The specific strategies in the above embodiments (such as rigidity level range, iteration upper limit, threshold value, recipe format, etc.) are merely examples, and those skilled in the art can adjust them according to actual needs.

[0091] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0092] The servo self-tuning device in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 5 This is a schematic diagram of the physical device structure of a servo self-tuning device in the embodiments of this application.

[0093] It should be noted that, Figure 5 The structure of the servo self-tuning device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0094] like Figure 5 As shown, the servo self-tuning device includes a Central Processing Unit (CPU) 501, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 502 or a program loaded from storage portion 508 into Random Access Memory (RAM) 503, such as performing the methods described in the above embodiments. The RAM 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An Input / Output (I / O) interface 505 is also connected to the bus 504.

[0095] The following components are connected to I / O interface 505: input section 506 including audio input devices, push-button switches, etc.; output section 507 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 508 including a hard disk, etc.; and communication section 509 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 509 performs communication processing via a network such as the Internet. Drive 510 is also connected to I / O interface 505 as needed. Removable media 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 510 as needed so that computer programs read from them can be installed into storage section 508 as needed.

[0096] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the various functions defined in the present invention.

[0097] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0099] Specifically, the servo self-tuning device in this embodiment includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the servo self-tuning method provided in the above embodiment.

[0100] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the servo self-tuning device described in the above embodiments; or it may exist independently and not assembled into the servo self-tuning device. The storage medium carries one or more computer programs that, when executed by a processor of the servo self-tuning device, cause the servo self-tuning device to implement the servo self-tuning method provided in the above embodiments.

[0101] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0102] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0103] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A servo self-tuning method based on a large model intelligent agent, characterized in that, The method includes: In the servo debugging software, preset tuning rule templates are used to limit the tuning stage and allow adjustment actions, and connect to parameter reading interface, parameter writing interface, running sampling interface and status reading interface; Receive a servo self-tuning request containing the tuning target, read the device status, current parameters and historical tuning records of the servo device to be tuned, and combine the servo self-tuning request, the device status, the current parameters, the historical tuning records and the tuning rule template into a model input; The model input is sent to the large model, and the parameters corresponding to the current tuning stage and the running sampling are performed on the large model: Call the parameter writing interface to write the corresponding parameter value, call the running sampling interface to perform running sampling, and collect at least one of the following as the sampling result: set time, overshoot, number of oscillations, resonant frequency and alarm status; The acquisition results are compared with the stable parameter records in the historical tuning records to obtain a comparison result. Based on the comparison result, a decision to continue adjustment, a stage switching decision, or a parameter rollback decision is formed. The stable parameter records save the parameter values, tuning time, and overshoot corresponding to the most recent stable operation. In response to the parameter rollback decision or the alarm status, the parameter writing interface is called to write back the parameter value corresponding to the stable parameter record, and the parameter reading interface is called to read the written parameter value for verification to obtain the verification result. If the tuning target is not reached, the acquisition results, comparison results, and verification results are written into the historical tuning record and sent to the large model again. The parameter adjustment and sampling, comparison, and verification are repeated until the tuning target or the preset iteration limit is reached, and the tuning result is output.

2. The method according to claim 1, characterized in that, The tuning rule template sets up a coarse tuning stage and a fine tuning stage, and respectively limits the parameter categories that can be written in the coarse tuning stage and the fine tuning stage; the mechanical stiffness level is written in the coarse tuning stage, and the gain parameter or feedforward parameter is written in the fine tuning stage; when the continuous acquisition results do not show the alarm state and the tuning time enters the preset interval, the stage switching command is executed.

3. The method according to claim 1, characterized in that, The acquisition result includes the resonant frequency; when the resonant frequency falls into the preset frequency band, the continued adjustment instruction includes a notch filter parameter writing instruction; after completing the parameter writing corresponding to the notch filter parameter writing instruction, the running sampling is performed again, and the new resonant frequency is written into the historical tuning record.

4. The method according to claim 1, characterized in that, The stable parameter record stores the parameter value, the settling time, and the overshoot when there is no alarm. When the settling time of the current acquisition result is longer than the settling time corresponding to the stable parameter record, the overshoot of the current acquisition result is greater than the overshoot corresponding to the stable parameter record, or an alarm occurs, the parameter rollback instruction is executed. When the current acquisition result does not have an alarm and the settling time is shorter than the settling time corresponding to the stable parameter record, the stable parameter record is refreshed.

5. The method according to claim 1, characterized in that, The method further includes accessing a reset interface; when the running sampling fails, the servo device to be tuned is not ready, or the alarm state occurs, the parameter writing interface and the running sampling interface are closed, and only the status reading interface and the reset interface are retained; After the status reading interface returns to the runnable state, the parameter writing interface and the running sampling interface are restored.

6. The method according to claim 1, characterized in that, The historical tuning record is saved by round, including tool call messages, acquisition results, stable parameter records, and the current tuning stage. When the number of rounds exceeds a preset threshold, the starting round record, the latest stable parameter record, and the most recent preset number of round records are retained. When the tuning process continues, the retained historical tuning record is read and the corresponding current tuning stage is executed.

7. The method according to claim 1, characterized in that, The servo self-tuning requirement indicates either internal command mode or host computer command mode; in the internal command mode, the inertia identification interface is called and the motion parameters are provided by the servo device to be tuned; in the host computer command mode, the host computer motion parameter reading interface is called and the running sampling is performed using the read load inertia ratio and the motion parameters.

8. A servo self-tuning device, characterized in that, The servo self-tuning device includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the servo self-tuning device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the servo self-tuning device, the servo self-tuning device performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on a servo self-tuning device, the servo self-tuning device performs the method as described in any one of claims 1-7.

Images