Motion stage script execution system supporting online programming debugging
By embedding a C language interpreter and motion control function library into the motion control system, online programming debugging and concurrent execution of multiple scripts are realized, solving the problems of insufficient programming flexibility and real-time debugging capabilities in existing technologies, and improving the system development efficiency and equipment utilization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- WUXI XIVI SCI & TECH CO LTD
- Filing Date
- 2026-02-27
- Publication Date
- 2026-06-30
Smart Images

Figure CN122309028A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of motion control software development, and in particular to a motion table script execution system that supports online programming and debugging. Background Technology
[0002] In the fields of high-end precision manufacturing and semiconductor equipment, the level of automation and intelligence of motion control systems directly determines production efficiency and process accuracy. Traditional motion table control systems typically rely on pre-built, closed, instruction-set-based proprietary scripting languages provided by manufacturers, allowing users to automate processes by arranging predefined motion command sequences. However, with increasing process complexity, production tasks increasingly require the integration of complex logical judgments, dynamic parameter calculations, and multi-axis collaborative interpolation motions, placing higher demands on the programming flexibility and computational capabilities of control scripts. To address this issue, two main technical approaches have emerged in the industry: one is to introduce external programming languages as functional supplements into traditional control environments, but these typically exist as static function libraries and require specific bridging syntax for invocation by the main control script, resulting in cumbersome processes and difficult debugging; the other is to utilize embeddable C / C++ interpreters to build interactive motion control environments, aiming to achieve a task-level programming platform independent of specific electromechanical equipment. Meanwhile, Web-based remote programming and debugging technologies have gained traction in education and development due to their convenience, allowing developers to complete code editing and basic debugging on a browser-based platform. These technological advancements all point to one goal: to provide a more robust, open, and easy-to-use programming interface for motion control systems to meet the needs of flexible manufacturing.
[0003] While existing technologies offer various approaches to solving motion control programming problems, they all have significant limitations, failing to meet the high-reliability and high-efficiency online development and debugging requirements of industrial scenarios. First, most existing solutions fail to provide a complete programming environment based on general-purpose high-level languages. For example, calling C functions in a controller requires declaration and bridging using a specific basic scripting language, resulting in rigid syntax that limits the full potential of C and increases the learning and usage costs for users. Second, real-time debugging capabilities are severely lacking. Most industrial-oriented solutions lack source-code-level online debugging functionality, making it difficult to locate program errors. Some remote debugging systems implemented in academic research have complex architectures, typically relying on monitoring programs residing on the target device, making direct integration into resource-constrained real-time motion controllers difficult, and lacking the convenience of web-based interaction. Third, existing methods often focus on the sequential execution of single tasks and single scripts, lacking effective management and resource isolation mechanisms for concurrent execution of multiple tasks and multiple scripts. Meanwhile, programming environments, debuggers, and motion control kernels are typically loosely coupled, failing to provide an integrated closed-loop system from code writing and online debugging to real-time execution, and thus unable to support complex, multi-threaded automated production processes. Therefore, based on these challenges, this invention proposes a motion table script execution system that supports online programming and debugging. Summary of the Invention
[0004] To address the aforementioned issues, the present invention aims to provide a motion table script execution system that supports online programming and debugging. This system eliminates the learning and conversion costs associated with dedicated scripting languages, enables source-code-level single-step execution, breakpoint debugging, and real-time status monitoring of motion control scripts, improves development and debugging efficiency and program security, and allows multiple automated tasks to run independently and reliably on the same control platform simultaneously, thereby meeting the complex production needs of modern precision manufacturing.
[0005] To achieve the above objectives, this invention provides a motion table script execution system supporting online programming and debugging. The core of this system lies in constructing a unified execution environment. This environment embeds a complete C language interpreter, capable of directly parsing and executing user-submitted script text conforming to C language syntax, and dynamically mapping function calls to a pre-packaged motion control function library. The system dynamically creates and maintains an independent execution context for each running script through a concurrent execution and isolation management unit, ensuring that multiple scripts can be executed concurrently safely and in isolation. Simultaneously, the system integrates an online interactive debugging interface, which allows the external command control engine to dynamically switch between full-speed running and interactive debugging modes. In debugging mode, the engine can respond to single-step or breakpoint commands, pause execution, and provide a complete state snapshot, including variable snapshots and execution pointer positions. Furthermore, the system includes a safety execution monitor and a logic verification module, performing real-time safety compliance checks on running motion commands and static analysis and early warning of script logic, thus forming a closed-loop technical solution.
[0006] In a first aspect, the present invention provides a motion table script execution system that supports online programming and debugging, comprising: An integrated script execution engine integrates an interpreter based on a subset of C language syntax and a motion control function library in a single execution environment, which is used to directly parse script text that conforms to a preset subset of C language syntax and convert it into control instructions for the motion table. The dynamic performance optimization module is used to automatically identify and mark key code paths whose execution frequency or computational complexity exceeds a preset standard as hot paths during script execution based on a preset hotspot weight factor model, and submit the intermediate representation sequence of the hotspot path to the just-in-time compiler to generate and cache optimized local machine code. The concurrent execution and isolation management unit is used to create and maintain an independent execution context with a complete lifecycle for each user script, and to schedule multiple execution contexts to run in isolation and concurrently in the script execution engine; An online interactive debugging interface is used to receive external debugging commands during script execution and control the script execution engine to switch between full-speed running mode and interactive debugging mode. In the interactive debugging mode, the engine pauses in response to single-step or breakpoint commands and provides feedback on its real-time running status through the interface.
[0007] Furthermore, when parsing scripts, the interpreter based on a subset of C language syntax identifies semicolon-separated statements in the standard C language syntax structure as the smallest atomic execution unit, and performs priority syntax compliance checks and resource pre-allocation on atomic units containing motion control function calls to ensure the accuracy of instruction parsing and execution efficiency.
[0008] Furthermore, the motion control function library encapsulates the basic motion and interpolation motion instructions of the motion table in the form of function interfaces. The input parameters and return value types of each function interface follow the C language data type specifications, enabling the script to dynamically construct and modify motion parameters through variable passing, arithmetic operations, and logical judgments, thereby realizing complex and variable motion trajectory planning.
[0009] Furthermore, the execution context includes a dedicated data storage area and an instruction execution pointer; the concurrent execution and isolation management unit schedules the execution of each context through polling or event-driven mechanisms, and ensures that the data storage areas of each context do not interfere with each other, thereby ensuring data security and system stability when multiple scripts run concurrently.
[0010] Furthermore, the concurrent execution and isolation management unit also integrates resource conflict prediction and arbitration; The arbitrator is used to perform forward-looking kinematic simulation calculations on a virtual timeline based on the future motion instructions prefetched from the queues of each execution context before scheduling multiple execution contexts to execute concurrently. This is to detect and attempt to resolve kinematic conflicts or hardware resource competition that may be caused by different execution contexts in the future time window, and to dynamically adjust the execution timing of each context or propose instruction modification suggestions based on the prediction results.
[0011] Furthermore, the online interactive debugging interface has a runtime state snapshot function in interactive debugging mode, which can capture and report the current execution pointer position, variable memory snapshot, and queue of motion control functions to be executed, so that developers can fully grasp the runtime state and perform effective debugging.
[0012] Furthermore, the script execution engine also includes a safety execution monitor, which monitors in real time any abnormal states that may be caused by motion control function calls during script execution. When an abnormality is detected, the monitor forcibly interrupts the current script execution, saves the error context, and notifies the online interactive debugging interface, thereby preventing equipment damage and improving the reliability of system operation.
[0013] Furthermore, the safety execution monitor performs real-time compliance checks on the motion instruction sequence in the script based on preset kinematic constraint rules and system resource thresholds, so as to achieve proactive safety protection for the motion process.
[0014] Furthermore, the online interactive debugging interface works in conjunction with the secure execution monitor to provide intelligent analysis of the execution trajectory. This function continuously records the key state sequence and instruction flow during script execution, and automatically triggers backtracking analysis based on the records when an abnormality is detected. By comparing the abnormal state with the historical normal state, it locates and reports the root cause code location and related variable evolution chain that caused the abnormality.
[0015] Furthermore, the system also includes a script logic verification module, which performs static analysis and early warning on the nesting depth of loops, recursive function calls, and timing logic conflicts of motion instructions in the script after the script is loaded and before it is officially executed, so as to eliminate potential logical errors before running and improve development efficiency.
[0016] Furthermore, the integrated script execution engine supports defining and calling user-defined functions in the script, and the user-defined functions can nest and call function interfaces in the motion control function library, thereby enhancing the modularity and code reusability of the script.
[0017] Secondly, a method for executing motion table scripts that supports online programming and debugging is also provided. This method is based on the system described in the first aspect and includes: It provides an integrated script execution environment with an embedded C language interpreter and motion control function library; Receive script text submitted by the user that conforms to a preset subset of C language syntax, and create an execution context for the script with independent storage space and execution pointer; Perform lexical and syntactic analysis on the script to transform its content into a sequence of atomic execution units; Responding to user commands, it switches between full-speed execution and interactive debugging modes; In full-speed execution mode, each atomic unit is executed sequentially, and the corresponding motion control function is called to drive the motion table; In interactive debugging mode, based on the received single-step or breakpoint instructions, it executes one or a group of atomic units and then pauses, and provides a snapshot of the execution status. During execution, motion control commands are monitored and anomalies are handled in real time for safety. The scheduler manages the execution contexts of multiple scripts, enabling them to run concurrently and in isolation within the execution environment.
[0018] The term "full-speed operation" refers to the script execution engine sequentially executing atomic units at the highest continuous speed supported by the system, without waiting for user-interactive debugging commands. This execution flow incorporates a real-time compliance check by a safety execution monitor. Specifically, each motion control function, after being called but before its instructions are actually sent to the motion stage hardware driver layer, must pass the check by the safety execution monitor. Only if the check passes is the instruction sent; if the check fails, execution is immediately interrupted and an exception handling process is triggered. Therefore, the essence of full-speed operation is continuous execution without debugging intervention while ensuring safety, rather than ignoring safety checks.
[0019] This invention provides a motion table script execution system supporting online programming and debugging. Its core lies in creating a unified software execution environment that natively integrates a complete C language interpreter and a dedicated motion control function library. The system receives standard C language scripts written by users, parses them directly into executable instructions through the interpreter, and dynamically calls functions from the motion control library to drive the device. To meet industrial concurrency requirements, the system designs a concurrent and isolated multi-script execution management mechanism, assigning an independent execution context to each task to ensure safety and stability. Crucially, the solution deeply integrates an online interactive debugging interface, enabling the system to dynamically switch between full-speed operation and interactive debugging modes supporting single-step and breakpoint operations, providing real-time feedback on the running status. Furthermore, the solution integrates multiple protection mechanisms covering static script logic verification and runtime security monitoring, forming an integrated technical closed loop from code writing, online debugging, security verification to multi-task concurrent execution.
[0020] This system significantly improves the development efficiency, operational safety, and task processing capabilities of motion control systems. First, by adopting the general-purpose C language as its scripting language, it completely eliminates the burden on users learning specialized control languages, greatly enhancing programming flexibility and functionality, and making it possible to implement complex logic and algorithmic control. Second, the built-in online interactive debugging function provides a debugging experience consistent with general development environments, enabling precise monitoring and rapid error localization of control scripts, significantly shortening the development and debugging cycle and enhancing program reliability. Third, its concurrent, resource-isolated multi-task execution architecture allows the system to reliably handle multiple automated processes simultaneously, improving the overall utilization and productivity of the equipment. Finally, the continuous safety monitoring and logic verification mechanism provides proactive protection for the motion control process, effectively preventing equipment risks caused by program errors, thereby achieving a comprehensive improvement in system performance.
[0021] Beneficial effects By implementing the motion table script execution system supporting online programming and debugging provided by the present invention, the following technical effects are achieved: (1) The integrated C language script execution engine effectively bridges the general programming ecosystem and the field of dedicated motion control by embedding a standard C language interpreter and motion control library. It eliminates the barrier for users to learn dedicated scripting languages and makes it possible to build complex and flexible control logic using rich C language syntax, data structures and algorithm libraries, thus achieving a close coupling between the computing power of high-level programming languages and the control needs of industrial equipment.
[0022] (2) The concurrent and isolated execution context management mechanism enables the system architecture to handle multiple tasks concurrently by instantiating an independent virtual execution environment for each script. It not only ensures the strict isolation and security of resources and data during the runtime of multiple automated tasks, but also provides basic support for the simultaneous independent operation of multiple complex processes. It is a key architectural guarantee for achieving high-efficiency and high-utilization operation of equipment in modern flexible manufacturing.
[0023] (3) The dynamic performance optimization module identifies and optimizes critical code paths at runtime, effectively extending the script system's execution capabilities from handling simple sequential logic to efficiently handling high-computational-load control algorithms, including complex mathematical operations and real-time trajectory planning. This allows the system to achieve execution efficiency close to that of natively compiled code while maintaining the flexibility of script programming, significantly improving the system's real-time response and ability to handle complex tasks.
[0024] (4) The intelligent analysis function of execution trajectory, by integrating state records, backtracking analysis and difference comparison, upgrades the system's debugging mechanism from providing static breakpoint snapshots to a dynamic diagnostic tool with causal reasoning capabilities. It effectively solves the problem of locating nondeterministic anomalies and timing errors, and can automatically track and present the complete logical chain from the anomaly symptoms to the programming root cause, greatly improving the depth and efficiency of development debugging and system maintenance.
[0025] (5) Resource conflict prediction and arbitrator introduces a forward-looking collaborative scheduling capability for concurrent execution of multiple scripts. By performing virtual simulation and conflict detection before the actual driving of motion commands, the risk of resource competition and motion interference can be actively avoided, thereby improving the concurrent execution mode of the system from safe parallelism that relies on isolation protection to intelligent collaboration that enables efficient and orderly cooperation between tasks, thus optimizing the overall equipment utilization and task flow smoothness. Attached Figure Description
[0026] To make the above-described motion table script execution system supporting online programming and debugging of the present invention more apparent and understandable, the accompanying drawings used in the specific embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0027] Figure 1 This is a flowchart illustrating the method described in this application; Figure 2 A flowchart illustrating the lifecycle of a single storage buffer. Detailed Implementation
[0028] Example 1: This embodiment provides a motion table script execution system and method that supports online programming and debugging. The method flow is as follows: Figure 1 As shown, in its specific implementation, it constructs a fully closed-loop software environment, which is especially suitable for scenarios in fields such as semiconductor manufacturing and precision machining where there are extremely high requirements for the flexible development and reliable operation of motion control programs.
[0029] The initial step in system operation is script input. Users can submit pre-written scripts conforming to C language syntax via a network interface through a monitoring computer or remote terminal connected to the motion controller. This system abandons the traditional, feature-limited, and syntactically unique proprietary instruction sets common in motion controllers, instead adopting the internationally recognized C language standard as the scripting specification. This fundamental shift eliminates the need for users to learn a new domain-specific language, allowing them to directly utilize familiar programming paradigms such as variable definitions, rich operators, complex data types, loop control statements, and function encapsulation to express complex motion logic and calculation processes. After receiving the complete script text, the network transmission module securely stores it in the motion controller's local non-volatile memory. This step not only provides a stable data source for subsequent parsing and execution but also lays the foundation for script version management and reuse.
[0030] Once the script is saved, the integrated script execution engine begins its workflow. This engine is a deeply integrated software module, fundamentally integrating a complete C language interpreter with a motion control function library specifically encapsulated for motion table operation within the same execution environment. This means there are no additional bridging layers or conversion interfaces between the interpreter and the motion control instructions, thus ensuring execution efficiency and directness. During the initialization phase, the engine actively loads functions that may be used in the C language standard library, and simultaneously loads the motion control function library into memory. The design of this motion control function library follows the principles of high cohesion and low coupling in software engineering. It encapsulates all possible movements of the motion table, such as single-axis absolute and relative motion, multi-axis linear and circular interpolation, and the setting of motion parameters such as speed and acceleration, into C language functions with clearly defined parameter lists and return values. The interface design of these functions is consistent with that of standard C library functions. Users can call motion instructions such as MoveLinear or SetVelocity in scripts as naturally as they would call printf or sin. The call parameters can be dynamically set through variables, arithmetic expressions, or the results of logical operations, thus achieving a deep integration of the algorithmic capabilities of general programming languages with precision motion control.
[0031] When the execution engine begins parsing the script, its embedded C interpreter operates according to a sophisticated process. The interpreter first initiates lexical analysis, which acts like a fine scanner, reading the script text character by character and breaking it down into a series of meaningful words, or tokens, according to C's lexical rules. These tokens include keywords, identifiers, constants, operators, and delimiters. The token sequence generated by lexical analysis is sequentially fed into a parsing stack or buffer, preparing it for the next stage of syntax analysis. Next, the syntax analysis process begins, reading content from the token sequence and identifying the program's structure according to C's grammar rules. It's important to note that the parser recognizes a complete statement in C that ends with a semicolon as the smallest indivisible atomic unit of execution. Whether it's a simple assignment statement or a complex function call, anything ending with a semicolon is considered an atomic unit. This granular approach, based on natural grammatical elements, lays a solid foundation for subsequent precise execution control, especially single-step debugging. The result of syntax analysis is that the entire script is transformed into an ordered list of these atomic execution units in sequence.
[0032] After the script is successfully parsed, the system's concurrent execution and isolation management unit intervenes to create and manage the script's runtime environment, such as... Figure 2 As shown. This unit instantiates an independent execution context for each script to be executed, i.e. Figure 2 The memory buffer in the context is a lightweight virtual execution environment with a complete lifecycle. Its lifecycle begins in the creation phase, where the system allocates a dedicated data storage area and initializes an instruction execution pointer for that context. When the system needs to run multiple automated tasks concurrently, the concurrent execution and isolation management unit creates such an execution context for each script. Subsequently, this unit manages these contexts through a scheduler, allowing them to enter the execution phase in a time-sharing and alternating manner within the integrated script execution engine. Because the data storage areas of each context are physically or logically isolated, modifications to variables or memory operations in one script will not affect another script, thus achieving safe and isolated concurrent execution of multiple scripts at a macroscopic level, greatly improving device utilization and the system's multitasking capabilities. When a script finishes execution or is forced to terminate, the context enters the destruction phase, and all its occupied resources are reclaimed by the system, completing its entire lifecycle.
[0033] The script's execution control boasts high flexibility thanks to its online interactive debugging interface. This interface serves as a two-way communication channel between the system and the user, allowing for in-depth intervention and observation during script execution. Users can send debugging commands to the system via monitoring software, controlling the engine to dynamically switch between two modes: full-speed execution mode and interactive debugging mode. In full-speed execution mode, the engine executes atomic units sequentially and rapidly from the current execution pointer until the script terminates or encounters an unhandled exception. This mode is suitable for the rapid, automated execution of verified scripts. In interactive debugging mode, the engine's behavior becomes highly controllable. Once this mode is entered, execution pauses, awaiting further user instructions. Users can set various breakpoints, such as line breakpoints or conditional breakpoints. Users can also send single-step execution commands. When the engine receives a single-step execution command or reaches a breakpoint, it executes the current atomic unit precisely and then immediately pauses again. During pauses, the online interactive debugging interface proactively collects snapshots of the current runtime state, including but not limited to: the position of the execution pointer, the names and current values of all active variables, function call stack information, and a list of pending motion control functions already in the queue. This state information is fed back to the user's monitoring interface in real time, allowing the user to clearly and intuitively observe the actual effects and internal state changes after each step of the script's execution, just as in a general integrated development environment. Furthermore, the system supports calling printf-like output functions within the script to directly print debugging information and intermediate calculation results to the console, further enhancing debugging convenience. This mechanism completely changes the predicament of blind debugging of motion control programs, enabling logical errors and calculation errors to be detected and located in a timely manner before they cause equipment malfunctions, significantly improving development efficiency and system security.
[0034] To ensure absolute reliability in complex industrial environments, the system incorporates a multi-layered safety mechanism. The integrated script execution engine includes a safety execution monitor, a resident runtime monitoring module. Its responsibility is to monitor all calls to motion control library functions during script execution in real time. This monitor embeds a set of preset kinematic constraints and system resource thresholds. Before each motion command is actually sent to the hardware driver layer, the safety execution monitor performs a real-time compliance check on its parameters and the context of the command sequence—a proactive check. For example, it can determine whether a rapid positioning command will exceed mechanical limits, or whether a complex interpolation path is kinetically feasible. Upon detecting potential violations or abnormal states that could cause equipment damage or system crashes, the safety execution monitor immediately interrupts the current script execution, preserves the complete error context, and immediately alerts the user through an online interactive debugging interface, thus achieving proactive protection. In addition to dynamic runtime monitoring, the system can also perform static analysis through an optional script logic verification module after script loading and before formal startup. This module scans the script code, checking for issues such as excessively deep nested loops, safe function recursion, and timing or logical conflicts between different motion instructions, and provides warnings accordingly. This dual security mechanism forms a comprehensive protection network, greatly improving the robustness and reliability of the entire system when facing complex and unknown user scripts.
[0035] Example 2: Traditional line-by-line interpretation execution suffers from significant performance bottlenecks for frequently invoked loops and functions in motion control scripts. Building upon the aforementioned embodiments, this embodiment proposes a hybrid execution engine, the core of which lies in the combination of static analysis and dynamic optimization. The system first parses the C language script into a platform-independent, semantically rich intermediate representation, which preserves the control flow and data flow structure of the source code. During the initial interpretation execution, the engine dynamically identifies hotspot code blocks whose execution frequency exceeds a preset threshold through a lightweight monitoring module. For these hotspot paths, the engine triggers a just-in-time (JIT) compiler to dynamically compile the corresponding intermediate representation sequence into efficient native machine code for the target processor and cache it. Subsequently, execution jumps directly to the compiled native code block, bypassing redundant interpretation steps, thereby achieving an order-of-magnitude improvement in the execution speed of critical control logic. This mechanism is transparent to the user, maintaining the interactivity and debuggability of the script system.
[0036] After the syntax analysis phase, instead of directly generating the interpreted instruction stack, the entire script is converted into a custom static single-assignment intermediate representation. This intermediate representation contains rich type information and operation semantics.
[0037] The system incorporates an intermediate representation-based interpreter for initial and non-hotspot path execution. Simultaneously, a lightweight monitor is attached to the interpreter, maintaining an execution counter for each basic code block.
[0038] To more intelligently determine hotspot paths, a hotspot weighting factor is introduced to comprehensively evaluate the necessity of optimizing code segments:
[0039] In the formula, This is the hotspot weight value; the larger the value, the more necessary the code block is for just-in-time compilation optimization. The actual total number of clock cycles consumed during the observation period for executing the target code segment is obtained by reading the processor performance counter; The reference clock cycle constant; Let $\frac{ ... To give the first Preset weighting coefficients for class operations, For the first in this code segment The total number of times the class operation occurs; For reference complexity baseline values; This is the execution frequency factor, which is the number of times the code segment is executed during the observation period; , and For configurable weighting coefficients, satisfying .
[0040] When the calculated hotspot weight exceeds a preset threshold, the monitor marks the code block as a hotspot and submits the intermediate representation sequence of the code block, as well as the type specialization information of the current execution context, to the just-in-time compilation queue.
[0041] The background just-in-time (JIT) compiler retrieves the hotspot intermediate representation sequence from the queue, performs a series of optimizations, and generates optimized native machine code. The compiled machine code is stored in a code cache associated with the source script location.
[0042] Subsequently, when the execution flow reaches the code block again, the scheduler at the interpreter's front end checks the code cache. If a cached cache is found, execution jumps directly to the cached native machine code; after execution, it returns to the interpreter to continue executing the subsequent intermediate representation. If a cached cache is found or the compiled code is invalid, execution falls back to interpreting the intermediate representation.
[0043] Establish a lifecycle management strategy for code caching. When a script is modified, a debug breakpoint is set in a hotspot path, or a change in execution mode is detected, the associated cached machine code will be automatically invalidated to ensure the consistency of execution results.
[0044] To verify the performance gains of the engine, comparative tests were conducted in a standard testing environment. The test platform used an embedded motion controller with an ARM Cortex-A53 core and a main frequency of 1.2GHz as the runtime environment for the script execution system. The comparison object was a pure interpreted execution baseline system on this controller without an integrated dynamic performance optimization module. The test scripts covered typical motion control scenarios, including: trajectory planning algorithms with multi-layered nested loops and trigonometric function calculations; dense instruction sequences of multi-axis linear interpolation and circular interpolation; and flow control logic with complex conditional branches. During the tests, the threshold and weight coefficients of the hotspot weight factors were set to pre-calibrated system default values. Performance data were based on the statistical average of multiple runs. The execution speed improvement factor and latency reduction percentage were within the statistical range of the results obtained from the above-mentioned multiple test scripts, and their specific values were related to the computational density of the script, the proportion of hotspot code blocks, and the characteristics of the hardware platform.
[0045] Compared to conventional script systems that rely on pure interpretation, this hotspot path acceleration engine can improve the execution speed of motion control scripts containing computationally intensive loops by 10 to 50 times. For example, an interpretation execution cycle that originally required 500 microseconds can be shortened to 10-50 microseconds after compilation. This enables the efficient implementation of real-time-critical functions such as complex motion planning algorithms and online trajectory correction at the script layer, expanding the applicability of script systems from simple sequential logic control to high-performance real-time computing, while reducing overall system response latency by approximately 30%-70%. Results show that this engine can effectively identify and optimize the execution paths of computationally intensive loops or frequently called trajectory planning functions contained in motion control scripts. The overall system response latency is significantly reduced, especially when handling computationally intensive tasks such as multi-axis collaboration and high-precision trajectory tracking, where the stability and determinism of task cycle time are significantly improved.
[0046] Example 3: Traditional debuggers only provide static snapshots at breakpoints, making it difficult to reproduce and locate non-deterministic anomalies in motion control that depend on specific timing or conditions. Building upon the aforementioned embodiments, this embodiment designs a deep debugging mechanism. Its core is the continuous, low-overhead recording of program execution trajectories and snapshots of key system states, forming an execution log that can be traced back. When an anomaly occurs or a checkpoint is manually triggered by the user, the system not only captures the current state but also automatically backtracks and analyzes the execution trajectory within a window period preceding the anomaly. By comparing the system state differences at the time of the anomaly with historical normal reference points and applying association rule analysis, the system can automatically infer the program logic segment or external condition most likely to cause the anomaly, thereby expanding the root cause location from a single point to a causal chain, greatly improving the efficiency of debugging complex concurrent and timing-related problems.
[0047] A fixed-size circular buffer is allocated in system memory. During script execution, a lightweight logger runs continuously, writing a concise record to the buffer at very low frequency or only when specific events occur. The recorded content may include: the program counter, hash values of critical global and local variables, motion instruction types, and system timestamps.
[0048] After each step of the debug breakpoint, the system inserts a checkpoint marker in the circular buffer and simultaneously saves a complete, lossless snapshot of the execution context state in another independent memory area.
[0049] When the safety execution monitor detects an anomaly, the following automated analysis process is immediately triggered: Immediately freeze the current execution context and save a complete snapshot of the state at the time of the exception.
[0050] Extract all execution trajectory records within a time window prior to the occurrence of the exception from the circular buffer.
[0051] The system automatically loads the most recent normal checkpoint snapshot before the anomaly occurred as the baseline. By comparing the anomaly snapshot with the baseline snapshot, the difference in all state variables is calculated. Simultaneously, the trajectory records within the backtracking window are analyzed to identify the moment when the first abnormal sign appeared before the anomaly occurred, and which specific script code blocks and motion instructions were executed before and after that moment.
[0052] To quantify state changes and correlate them with suspicious codes, a state difference index and a code association confidence score are defined:
[0053] In the formula, This is the state difference index, a scalar output; the larger the value, the more significant the state difference between the two systems. and For configurable harmonic coefficients, satisfying This is used to balance the contribution weights of data state differences and execution flow differences in the total differences; The total number of key state variables participating in the comparison; For variables The difference calculation function is as follows: The output values are normalized to the interval [0,1], where, It is a very small constant, so division by zero should be avoided; To measure the execution flow difference, the edit distance between the function call stack sequences of the two states is calculated. and These represent the lengths of the function call stack sequences corresponding to the two states.
[0054] The system combines the results of state difference analysis and trajectory correlation analysis to generate a structured diagnostic report. The system also highlights relevant lines of script code.
[0055] To objectively evaluate the performance of the mechanism, a test case set containing 50 typical motion control anomalies was constructed. This test case set covers three common anomaly patterns: 30 cases of nondeterministic timing anomalies, including motion axis preemption caused by multiple script concurrency, trajectory deviation caused by interruption delays, and misjudgment of conditions triggered by sensor noise; 10 cases of logical programming errors, such as missing boundary conditions, loop count overflow, and uninitialized variables; and 10 cases of kinematic conflicts, such as axis overruns, sudden velocity changes, and multi-axis interpolation conflicts. Anomaly injection methods included directly modifying the script source code, dynamically modifying motion parameters at runtime, and simulating external event interference.
[0056] The traditional debugging method in contrast refers to the conventional debugging process where engineers rely solely on breakpoint settings, single-step execution, variable monitoring, and log output when the system does not integrate the aforementioned intelligent execution trajectory analysis function. During testing, the system configuration parameters were uniformly set: the circular buffer capacity was 10,000 records, the recording frequency was once every 50 atomic units executed for critical states, and the backtracking analysis window covered the 500 execution records prior to the anomaly.
[0057] For complex, nondeterministic motion control anomalies, this mechanism can reduce the average time required for engineers to locate the root cause from hours or even days using traditional methods to minutes. In test scripts injected with known faults, the system can automatically and accurately backtrack and locate the source code line or function module that triggered the anomaly in over 95% of cases, while traditional debugging methods typically have an initial location accuracy of less than 30% for such problems. This transforms debugging from passive breakpoint checking to proactive intelligent diagnosis, significantly improving system maintenance efficiency and reliability. Results show that, faced with nondeterministic, sporadic, or concurrent timing-related motion control anomalies, the system can automatically and accurately backtrack and pinpoint the initial code location and related variable change chain that caused the abnormal state deviation. This effectively solves the problem of low efficiency in reproducing and diagnosing such deep logic errors using traditional debugging methods, transforming the debugging process from passive observation to proactive causal reasoning, and significantly improving observability and problem-solving efficiency during system development, testing, and maintenance phases.
[0058] Example 4: In scenarios where multiple motion control scripts execute concurrently, conventional time-division multiplexing or simple round-robin scheduling strategies cannot effectively handle competition requests for shared motion axes between scripts, easily leading to motion conflicts, sudden stops, or deadlocks. Building upon the aforementioned embodiments, this embodiment proposes a two-layer scheduling arbitration mechanism. The upper layer is a dynamic priority scheduler, which dynamically calculates and adjusts the scheduling weights based not only on the static priority of the scripts but also on the urgency of the scripts' progress and the intensity of their resource demands in real time. The lower layer is a kinematic conflict pre-arbitrator. Before the scheduler decides to switch or execute scripts in parallel, this arbitrator performs virtual, forward-looking kinematic simulation calculations based on the motion commands that each script is about to issue. It checks whether the motion trajectories planned by different scripts will interfere in physical space within a short future time window, or whether they have issued speed / position commands for the same motion axis that cannot be simultaneously satisfied. If a potential conflict is detected, the arbitrator does not simply block it, but attempts to resolve it automatically by fine-tuning the timestamps of each script instruction, negotiating the switching order, or triggering safe zone restrictions. The arbitration result is then fed back to the scheduler to jointly determine the optimal execution order and timing, thereby achieving global optimization of concurrent execution efficiency and security.
[0059] Each script must register its resource requirements with the system when loaded or during runtime, including: a list of required motion axes, estimated runtime, latest allowed completion time, motion mode, and criticality level.
[0060] The scheduler maintains a dynamic priority score for each running script. This score is calculated and updated in real-time using a weighted formula, taking into account factors such as base static priority, schedule urgency factor, and resource consumption factor.
[0061] Each execution context maintains a prefetch queue of motion commands that will be issued in the next few milliseconds to tens of milliseconds. These commands have been generated by script interpretation but have not yet been sent to the motion controller.
[0062] The conflict pre-arbitrator is triggered periodically or before the upper-level scheduler prepares to perform script switching / concurrency authorization. It collects motion instructions for the next time window from all active script prefetch queues.
[0063] The arbitrator executes the kinematic models corresponding to these instructions rapidly on a virtual timeline, calculating the position and velocity of each motion axis and end effector at every moment in the virtual future. Utilizing axis spatial position boundaries, or by establishing a simple geometric bounding box model, it quickly detects whether spatial interference will occur between motion components controlled by different scripts, and whether conflicting setpoints are assigned to the same axis.
[0064] If there is no conflict, the arbitrator returns a safety signal, and the scheduler proceeds according to the original plan.
[0065] When a conflict is detected, the arbitrator attempts to resolve it using strategies such as: inserting a small delay for the prefetch instructions of a script with low dynamic priority; suggesting that the scheduler temporarily suspend a script to allow another script's urgent movement through the conflict area first; or triggering a pre-defined, safer shared trajectory. These strategies are encapsulated as scheduling recommendations.
[0066] For serious conflicts that cannot be resolved through fine-tuning, the arbitrator immediately issues the highest level warning to the scheduler and security monitor, recommends that the system enter a secure hold state, and notifies the user.
[0067] The scheduler combines dynamic priorities and suggestions from the conflict pre-arbitrator to make the final scheduling decision. The context state of delayed scripts is properly preserved to ensure logical correctness during recovery.
[0068] To quantitatively evaluate the performance improvement of the mechanism, a systematic comparative test was conducted in a simulated motion control experimental environment. The experimental environment consisted of an industrial PC with an integrated four-axis motion control card, supporting simulation software, and a virtual motion platform, simulating the dynamic characteristics and communication latency of a real motion table.
[0069] The test task scripts are designed for three typical industrial scenarios: Material handling tasks (3 scripts): each script controls an independent end effector to perform pick-and-place operations within a shared workspace, with paths intersecting in the central area; Collaborative assembly tasks (2 scripts): one script handles positioning, and the other handles assembly, requiring them to alternate using the same set of motion axes; Inspection and scanning tasks (2 scripts): two independent scanning paths may interfere with each other within the workspace. Each task script contains 50-100 motion instructions, with a runtime between 30-180 seconds.
[0070] In this test, motion conflict refers to the risk of physical interference between moving parts controlled by different scripts on their spatial trajectories, or the issuance of control commands that cannot be satisfied simultaneously on the same motion axis at the same time, thus triggering an emergency stop by the system's safety mechanism.
[0071] Conventional multi-task motion control systems refer to scheduling schemes that employ fixed-priority preemptive scheduling without conflict pre-detection. This scheme only triggers an emergency stop when an actual conflict is detected, and resumes operation only after manual intervention.
[0072] During the test, each task combination was run 30 times, and the number of conflict stop events and the overall task completion time from the start of all tasks to the completion of the last task were recorded.
[0073] Compared to conventional multi-task motion control systems that employ fixed priority or simple round-robin scheduling without conflict pre-detection, this mechanism can reduce motion conflict and emergency stop events caused by resource contention by over 90% when running multiple motion scripts with potential resource contention. Through proactive arbitration and intelligent scheduling, the system can shorten the overall task completion time of concurrent multi-script execution by 15%-40% without sacrificing safety. For example, in simulation tests, three transport tasks with partially overlapping areas typically took 120 seconds due to collision avoidance emergency stops with conventional scheduling. However, after adopting this mechanism and optimizing interleaved execution, the total time was reduced to 85 seconds. This allows the motion table to be upgraded from simple multi-task execution to an intelligent execution platform with preliminary collaboration and self-optimization capabilities, significantly improving the overall utilization rate of the equipment. The results show that this mechanism can proactively predict and resolve competition requests for critical resources such as motion axes between different script tasks, thereby reducing the occurrence rate of runtime failures such as emergency stops, deadlocks, or trajectory interference caused by resource conflicts to an extremely low level. Meanwhile, by dynamically balancing task urgency and resource consumption, the system achieves global optimization scheduling of the execution order of multiple concurrent tasks. This significantly shortens the overall average task completion time and improves the overall throughput capacity of the equipment while ensuring the safe completion of all tasks.
Claims
1. A motion table script execution system supporting online programming and debugging, characterized in that, include: An integrated script execution engine integrates an interpreter based on a subset of C language syntax and a motion control function library in a single execution environment, which is used to directly parse script text that conforms to a preset subset of C language syntax and convert it into control instructions for the motion table. The dynamic performance optimization module is used to automatically identify and mark key code paths whose execution frequency or computational complexity exceeds a preset standard as hot paths during script execution based on a preset hotspot weight factor model, and submit the intermediate representation sequence of the hotspot path to the just-in-time compiler to generate and cache optimized local machine code. The concurrent execution and isolation management unit is used to create and maintain an independent execution context with a complete lifecycle for each user script, and to schedule multiple execution contexts to run in isolation and concurrently in the script execution engine; An online interactive debugging interface is used to receive external debugging commands during script execution and control the script execution engine to switch between full-speed running mode and interactive debugging mode; In the interactive debugging mode, the engine pauses in response to single-step or breakpoint commands and provides real-time running status feedback through the interface.
2. The system according to claim 1, characterized in that: When parsing scripts, the interpreter based on a subset of C language syntax identifies semicolon-separated statements in the standard C language syntax structure as the smallest atomic execution unit, and performs priority syntax compliance checks and resource pre-allocation on atomic units containing motion control function calls.
3. The system according to claim 1, characterized in that: The motion control function library encapsulates the basic motion and interpolation motion instructions of the motion table in the form of function interfaces. The input parameters and return value types of each function interface follow the C language data type specifications, which enables the script to dynamically construct and modify motion parameters through variable passing, arithmetic operations and logical judgments.
4. The system according to claim 1, characterized in that: The execution context includes a dedicated data storage area and an instruction execution pointer; the concurrent execution and isolation management unit schedules the execution of each context through polling or event-driven mechanisms, and ensures that the data storage areas of each context do not interfere with each other.
5. The system according to claim 1, characterized in that: The concurrent execution and isolation management unit also integrates resource conflict prediction and arbitrator; The arbitrator is used to perform forward-looking kinematic simulation calculations on a virtual timeline based on the future motion instructions prefetched from the queues of each execution context before scheduling multiple execution contexts to execute concurrently. This is to detect and attempt to resolve kinematic conflicts or hardware resource competition that may be caused by different execution contexts in the future time window, and to dynamically adjust the execution timing of each context or propose instruction modification suggestions based on the prediction results.
6. The system according to claim 1, characterized in that: The online interactive debugging interface has a runtime status snapshot function in interactive debugging mode, which can capture and report the current execution pointer position, variable memory snapshot, and the queue of motion control functions to be executed.
7. The system according to claim 1, characterized in that: The script execution engine also includes a safety execution monitor, which monitors in real time the abnormal states that may be caused by motion control function calls during script execution, and when an abnormality is detected, it forcibly interrupts the current script execution, saves the error context, and notifies the online interactive debugging interface.
8. The system according to claim 7, characterized in that: The safety execution monitor performs real-time compliance checks on the motion instruction sequences in the script based on preset kinematic constraint rules and system resource thresholds.
9. The system according to claim 1, characterized in that: The online interactive debugging interface works in conjunction with the secure execution monitor and has intelligent execution trajectory analysis capabilities. This function continuously records the key state sequence and instruction flow during script execution, and automatically triggers backtracking analysis based on the records when an abnormality is detected. By comparing the abnormal state with the historical normal state, it locates and reports the root cause code location and related variable evolution chain that caused the abnormality.
10. A method for executing motion table scripts that supports online programming and debugging, characterized in that: The method is implemented based on the system described in any one of claims 1-9: The method includes: It provides an integrated script execution environment with an embedded C language interpreter and motion control function library; Receive script text submitted by the user that conforms to a preset subset of C language syntax, and create an execution context for the script with independent storage space and execution pointer; Perform lexical and syntactic analysis on the script to transform its content into a sequence of atomic execution units; Responding to user commands, it switches between full-speed execution and interactive debugging modes; In full-speed execution mode, each atomic unit is executed sequentially, and the corresponding motion control function is called to drive the motion table; In interactive debugging mode, based on the received single-step or breakpoint instructions, it executes one or a group of atomic units and then pauses, and provides a snapshot of the execution status. During execution, motion control commands are monitored and anomalies are handled in real time for safety. The scheduler manages the execution contexts of multiple scripts, enabling them to run concurrently and in isolation within the execution environment.