IEC 61131-3 Method and apparatus for integrating G-codes into programming systems

Abstract

This application provides a method and apparatus for integrating G-code into an IEC 61131-3 programming system. The method includes: writing a hybrid program containing both G-code and IEC 61131-3 standard language code in an extended IEC 61131-3 programming environment; standardizing the G-code to generate a structured G-code abstract syntax tree; mapping the G-code abstract syntax tree into function block calls and logical statements conforming to the IEC 61131-3 standard; merging the converted content with the IEC 61131-3 standard language code to generate executable code; executing the executable code according to preset task scheduling rules and collecting hardware execution data in real time as feedback information; and jointly debugging the G-code and IEC 61131-3 standard language code based on the feedback information to obtain a hybrid control program suitable for industrial control scenarios.

Description

Technical Field

[0001] This application relates to the field of industrial control programming technology, and in particular to a method and apparatus for integrating G-codes into IEC 61131-3 programming systems. Background Technology

[0002] With the deep integration of industrial automation and intelligent manufacturing, CNC machine tools, as core processing equipment, rely on their dedicated instruction language, G-code, to accurately describe processing trajectories and equipment movements. Meanwhile, programmable logic controllers (PLCs) conforming to the IEC 61131-3 standard, with their standardized structured programming system and the PLCopen motion control function blocks already implemented in some systems (supporting point-to-point motion, linear / circular interpolation, etc.), have become the core hub of industrial automation control. As the demand for integrated "control-processing" grows, it is necessary to integrate G-code into the PLC programming system.

[0003] Currently, the integration of G-code and PLC programming systems in the industry mainly relies on two methods: one is to manually write customized conversion interfaces, with technicians manually constructing the mapping logic between G-code and PLC function blocks; the other is to use dedicated middleware as a transition, first converting G-code into an intermediate format, and then importing it into the PLC system for integration with control logic. Both methods achieve integration through an "external connection" approach, failing to form a unified integrated programming environment and making it difficult to adapt to the high-efficiency and precision requirements of intelligent manufacturing. Firstly, compatibility is poor; G-codes from different manufacturers (such as Fanuc and Siemens) have dialect differences, requiring manual interfaces or dedicated middleware to be customized for different manufacturers, resulting in high adaptation costs and weak scalability. Secondly, real-time performance is insufficient; manual conversion is prone to instruction delays, and multi-step format conversions in middleware also increase response time, ultimately leading to a decrease in machining trajectory accuracy. Thirdly, development efficiency is low, requiring the simultaneous maintenance of two independent systems: G-code and PLC code, and lacking cross-language debugging tools, making fault location and problem troubleshooting difficult.

[0004] Therefore, there is an urgent need for a method to solve the problems of compatibility, real-time performance and development efficiency, and to achieve automatic and accurate conversion between the two languages, efficient collaborative execution and cross-language joint debugging. Summary of the Invention

[0005] In view of this, this application provides a method and apparatus for integrating G-code into an IEC 61131-3 programming system to solve problems related to compatibility, real-time performance and development efficiency, and to achieve automatic and accurate conversion between two languages, efficient collaborative execution and cross-language joint debugging.

[0006] Specifically, this application is implemented through the following technical solution:

[0007] The first aspect of this application provides a method for integrating G-codes in an IEC 61131-3 programming system, the method comprising:

[0008] Write mixed programs that include both G-code and IEC 61131-3 standard language code in the expanded IEC 61131-3 programming environment;

[0009] The G code in the hybrid program is standardized to generate a structured G code abstract syntax tree;

[0010] The G-code abstract syntax tree is mapped and converted into function block calls and logic statements conforming to the IEC 61131-3 standard;

[0011] The converted content is then integrated with the IEC 61131-3 standard language code and compiled to generate executable code.

[0012] The executable code is executed according to the preset task scheduling rules, and hardware execution data is collected in real time as feedback information;

[0013] Based on the feedback information, the G code and the IEC 61131-3 standard language code are jointly debugged to obtain a hybrid control program suitable for industrial control scenarios.

[0014] The second aspect of this application provides an IEC 61131-3 programming system integrated G-code device, the device comprising a writing module, a processing module, a fusion module, an execution module and a debugging module;

[0015] The writing module is used to write mixed programs that simultaneously contain G code and IEC 61131-3 standard language code in the extended IEC 61131-3 programming environment.

[0016] The processing module is used to standardize the G code in the hybrid program and generate a structured G code abstract syntax tree;

[0017] The processing module is also used to map the G-code abstract syntax tree into function block calls and logical statements conforming to the IEC 61131-3 standard;

[0018] The fusion module is used to merge the converted content with the IEC 61131-3 standard language code, and generate executable code after unified compilation;

[0019] The execution module is used to execute the executable code according to the preset task scheduling rules and collect hardware execution data in real time as feedback information;

[0020] The debugging module is used to jointly debug the G code and the IEC 61131-3 standard language code based on the feedback information to obtain a hybrid control program suitable for industrial control scenarios.

[0021] The IEC 61131-3 programming system integration method and apparatus provided in this application, through writing hybrid programs in an extended IEC 61131-3 programming environment, first standardizes the G-code to generate an abstract syntax tree, realizing the transformation of G-code from text form to structured data, laying a unified data foundation for subsequent integration with IEC 61131-3 code, and avoiding parsing confusion caused by G-code format differences; the abstract syntax tree is mapped to IEC standard function block calls and logical statements, and with the help of standardized function blocks and ST language logic, the motion control, auxiliary function, and other instructions of G-code are transformed into modular logic common to the industrial control field, solving the compatibility problem between the differences between G-code and IEC language syntax systems, ensuring that the two types of code can be executed collaboratively at the logical level; by merging the converted content with the original IEC code and uniformly compiling to generate executable code, code-level integration of "processing instructions - control logic" is achieved, avoiding cross-language issues. The efficiency loss during execution ensures the integrity and execution efficiency of the control program. Executable code is executed according to task scheduling rules, and feedback information is collected. By prioritizing real-time and non-real-time tasks and controlling trajectory errors, the real-time requirements of motion control in industrial scenarios are met. At the same time, real-time feedback provides accurate actual execution data for debugging. Joint debugging based on feedback information achieves precise positioning and optimization of the two types of code collaboration problems by comparing actual trajectories with theoretical trajectories and associating modal states and variable values ​​on the time axis. The resulting hybrid control program retains the accuracy of G-code in describing machining trajectories while leveraging the standardization and compatibility of the IEC 61131-3 standard in industrial logic control. This enables industrial equipment to accurately execute machining tasks and flexibly respond to complex control logic, meeting the integrated "machining-control" needs in industrial control scenarios and improving the system's integration, reliability, and debugging efficiency. Attached Figure Description

[0022] Figure 1 A flowchart of the IEC 61131-3 programming system integration G-code method provided in Embodiment 1 of this application;

[0023] Figure 2 This is a schematic diagram of the structure of the IEC 61131-3 programming system integrated G-code device provided in Embodiment 2 of this application. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

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

[0026] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0027] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0028] Figure 1 The flowchart illustrates the IEC 61131-3 programming system integration G-code method provided in Embodiment 1 of this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0029] S101. In the extended IEC 61131-3 programming environment, write a mixed program that includes both G code and IEC 61131-3 standard language code.

[0030] Specifically, the extended IEC 61131-3 programming environment is an integrated development platform formed by enhancing the functionality of the original PLC programming environment that conforms to the IEC 61131-3 standard. Its core extensions include: adding syntax support for G-code, enabling separate writing of G-code and IEC 61131-3 standard language codes through preset embedding tags (such as {GCODE} and {END_GCODE}); integrating tools for G-code dialect adaptation, syntax parsing, and type conversion, supporting direct editing, verification, and processing of mixed programs; and providing a cross-language debugging interface that can simultaneously display the execution status of G-code and the variable values ​​of IEC 61131-3 code, enabling joint debugging of the two types of code.

[0031] Furthermore, G-code is a dedicated instruction language for CNC machine tools, primarily used to describe machining trajectories, motion patterns, and equipment action parameters; it is the "operation instruction set" for CNC machining. The IEC 61131-3 standard language code is a PLC programming language conforming to the International Electrotechnical Commission (IEC) 61131-3 standard; it is the "logic control language" for industrial automation control.

[0032] In specific implementation, within the extended IEC 61131-3 programming environment, embedded tags are used to divide code regions. In the code editing area, G code fragments are embedded between start and end tags. The embedded G code fragments support the continuous writing of multiple program segments. In the area outside the embedded tags, IEC 61131-3 standard language code is written, which uses ST structured text language. The two types of code are differentiated and displayed through a syntax highlighting module, and the integrity of the embedded tags is verified in real time to obtain a hybrid program.

[0033] Specifically, the extended IEC 61131-3 programming environment is pre-configured with a dedicated editing interface, including a code input area, and incorporates a syntax highlighting module and a marker recognition module. The marker recognition module pre-sets start markers (e.g., {GCODE}) and end markers (e.g., {END_GCODE}) to distinguish code types. In the code editing area, developers first input the start marker, then continuously write multiple G-code program segments (e.g., machining trajectory description code containing instructions such as G00 and G01) after the start marker. After writing, they input the end marker, ensuring the G-code segment is completely enclosed between the two markers. In the code editing area, code is written using ST structured text language in the area before the start marker and after the end marker, including variable declarations (e.g., defining axis reference variables and velocity parameter variables) and logical execution statements (e.g., motion control condition judgments and function block call instructions). The syntax highlighting module monitors the code editing area in real time, displaying G-code segments between the start and end markers in one color and ST language code outside the markers in another color, visually distinguishing the two types of code through color differences. The marker recognition module scans the code editing area in real time to check the matching of start and end markers. If there are unpaired markers (such as only a start marker and no end marker, or vice versa), an error is immediately prompted. If the markers are paired and the nesting relationship is correct, the mixed program structure is confirmed to be legal, and the writing of the mixed program is completed.

[0034] S102. Standardize the G code in the hybrid program to generate a structured G code abstract syntax tree.

[0035] Specifically, the G-code abstract syntax tree is a structured tree-like data model used to intuitively express the syntactic structure and logical relationships of G-code. Its core features include: organizing G-code information in a hierarchical node format: the root node represents the entire G-code program, the next level is the program segment node (corresponding to a single G-code instruction), and the program segment node contains instruction identifier sub-nodes (such as G01, M03) and parameter list sub-nodes. The parameter list sub-nodes are further subdivided into multiple "parameter identifier-parameter value" sub-nodes (such as X-axis coordinate, feed rate F, etc.). Each node carries complete attribute information: including instruction function category (such as motion control, auxiliary function), parameter value and unit (such as millimeters, revolutions per minute), modal state (such as current interpolation mode, coordinate system), etc., comprehensively reflecting the semantic information of the G-code. It reflects the logical relationship between instructions: through the parent-child relationship and sequential arrangement of nodes, it expresses the execution order of program segments, the continuity of modal instructions (such as inheriting the previous value when the subsequent program segment does not specify the feed rate in G01 mode), and other logical relationships, providing a structured data foundation for the subsequent conversion to the IEC 61131-3 standard function block calls and logical statements.

[0036] In specific implementation, the standardization process of the G code in the hybrid program to generate a structured G code abstract syntax tree includes:

[0037] (1) Dialect conversion is performed on the G code in the hybrid program. Through the built-in multi-vendor G code rule library, the special G code instructions of different vendors are converted into a general G code format that conforms to the ISO 6983 standard by using a regular expression matching algorithm.

[0038] Specifically, the multi-vendor G-code rule base is a pre-built structured dataset dedicated to storing and managing the dialect features and conversion rules of G-codes from different vendors (such as Fanuc, Siemens, etc.). Its core components include: a vendor-specific instruction mapping table: recording the correspondence between vendor-specific G-code instructions (such as Siemens' G110 coordinate system setting instructions and Fanuc's G10 parameter compensation instructions) and ISO 6983 standard general instructions; syntax difference rules: defining specific rules for different vendors in terms of parameter format (such as coordinate representation and unit labeling), modal instruction behavior (such as default feed rate and interpolation mode switching logic); and regular expression matching templates: regular expression templates designed for the character structure of vendor-specific instructions (such as instruction prefixes and parameter combination forms) to quickly identify dialect instructions to be converted.

[0039] In practice, G-code snippets wrapped in embedded tags are extracted from the hybrid program and used as the processing objects for dialect conversion. The built-in multi-vendor G-code rule library is invoked, loading the stored vendor-specific instruction mapping tables, syntax difference rules, and corresponding regular expression matching templates. A regular expression matching algorithm scans the extracted G-code snippets line by line, identifying vendor-specific G-code instructions (such as Fanuc's specific modal instructions and Siemens' G110 coordinate system instructions) using the regular expression matching templates in the rule library. Based on the mapping relationship between vendor-specific instructions and ISO 6983 standard general instructions in the rule library, and combined with syntax difference rules, the identified special instructions are converted into the corresponding general G-code format, including unified parameter format, unit annotation, and modal instruction behavior. After conversion, general G-code conforming to the ISO 6983 standard is output as input for subsequent standardization processing. The specific implementation process of the regular expression matching algorithm can be found in the descriptions in related technologies and will not be elaborated here.

[0040] For example, in one embodiment, the Siemens-specific instruction G110 (workpiece coordinate system offset) is converted into the general G52 instruction format.

[0041] (2) Parse the standardized general G code, perform lexical scanning on the G code according to the preset syntax rules, extract instruction identifiers, parameter values ​​and unit information, and then construct a preliminary syntax structure through recursive descent analysis, and parse each G code instruction into a syntax node containing instruction type, parameter set and modal state.

[0042] Specifically, the preliminary syntactic structure is a hierarchical data structure formed after parsing the standardized general G-code. It is used to initially express the syntactic composition and relationships of the G-code, specifically as follows: A hierarchy is constructed using program segments as basic units: each program segment corresponds to a G-code instruction, serving as a first-level node; each first-level node contains three types of sub-elements: instruction identifiers (e.g., G01, M03), parameter sets (a set of key-value pairs consisting of parameter identifiers and parameter values, such as {X:100.5, F:200}), and modal states (e.g., current interpolation mode, coordinate system type); each element is associated according to syntactic rules: the instruction identifier determines the function type of the program segment (e.g., motion control, auxiliary function), the parameter set provides specific execution parameters for the function, and the modal state marks the inherited or modified operating mode of the current program segment; the overall structure presents a linearly arranged sequence of nodes: according to the order of the G-code instructions in the original program, an ordered set of nodes is formed, reflecting the execution logical order of the program segments.

[0043] For example, the key elements of the preliminary grammar structure extraction mainly include: instruction type (such as G01 linear interpolation, M03 spindle start), parameter set (X, Y, Z coordinates, F feed rate, S spindle speed), and modal state (current interpolation mode, unit system, coordinate system).

[0044] In practice, the general G-code is scanned sequentially according to the character sequence. Instruction units are identified and segmented according to preset lexical rules. Sequences beginning with letters are identified as instruction identifiers. In combinations of letters and numbers following the instruction identifier, the letter portion is identified as a parameter identifier, and the number or numerical sequence with a decimal point is identified as a parameter value. The unit information associated with the parameter value is extracted. A lexical symbol table is established, storing the extracted instruction identifiers, parameter identifiers, parameter values, and unit information in the order of appearance. Instruction identifiers are associated with corresponding function categories, and parameter identifiers are associated with corresponding axis identifiers or functional attributes. Based on recursive descent parsing, using the lexical symbol table as input, the program segment-level syntax structure is first identified, dividing a single G-code line into program segment units consisting of instruction identifiers and parameter lists. The parameter list is a set of multiple parameter identifiers and parameter values. Then, the parameter-level syntax structure is parsed to determine the binding relationship between each parameter identifier and parameter value in the parameter list. A hierarchical syntax tree is constructed with program segment units as parent nodes and instruction identifiers and parameter lists as child nodes, forming a preliminary syntax structure.

[0045] Specifically, the general G-code is scanned character by character in sequence. When a continuous sequence of characters starting with a letter (such as G or M) is scanned, it is identified as an instruction identifier (e.g., scanning G01 is identified as a linear interpolation instruction identifier). For the content following the instruction identifier, if a combination of letters (such as X or F) and numbers is encountered, the letter part is identified as a parameter identifier (e.g., X is identified as an X-axis parameter identifier), and the subsequent numbers or numerical sequences with decimal points (e.g., 100.5) are identified as the corresponding parameter values. The unit information (e.g., millimeters, revolutions per minute) of the parameter value is extracted based on the G-code context. An empty lexical symbol table is created, and the instruction identifier, parameter identifier, parameter value, and unit information are stored sequentially in the recognition order. For example, for G01X100.5F200, the symbol table records: the instruction identifier G01 is associated with the motion function category, the parameter identifier X is associated with the X-axis coordinate attribute, the corresponding parameter value 100.5, and the unit millimeters, and the parameter identifier F is associated with the feed rate attribute, the corresponding parameter value 200, and the unit millimeters per minute. Furthermore, based on recursive descent analysis, using the lexical symbol table as input, starting from the beginning of the symbol table, the instruction identifier of the first G-code (e.g., G01) is located first. Then, all subsequent associated parameter identifier-parameter value pairs (e.g., X:100.5, F:200) are integrated into a parameter list, forming a program segment unit (e.g., G01+{X:100.5, F:200}), completing the program segment-level partitioning of a single G-code. For the parameter list of each program segment unit, the correspondence between parameter identifiers and parameter values ​​is matched one by one. For example, in the parameter list {X:100.5, F:200}, it is determined that X is bound to 100.5 and F is bound to 200. Using a program segment unit as the parent node, the instruction identifier (such as G01) and parameter list (such as {X:100.5, F:200}) in that unit are used as child nodes; under the parameter list child node, each parameter identifier-parameter value pair (such as X-100.5, F-200) is used as a secondary child node, forming a hierarchical syntax tree containing three levels of nodes, which is the preliminary syntax structure.

[0046] (3) Optimize the preliminary syntax structure by eliminating redundant instruction nodes that are repeated continuously, verifying the matching of coordinate values ​​in the parameter set with the device axis travel, expanding the cyclic instruction nodes into a sequence of multiple continuous motion instruction nodes, and generating a structured G-code abstract syntax tree.

[0047] In practical implementation, the program segment node sequence in the initial syntax structure is traversed, and nodes with consecutively appearing identical instruction identifiers and completely identical parameter sets (such as two consecutive G01X100F200) are detected. The first node is retained and subsequent duplicate nodes are removed. The travel parameters of each axis stored in the device configuration file (such as the effective range of the X-axis -500~500mm) are called, and the coordinate parameter values ​​(such as X, Y, and Z axis values) in all parameter sets in the syntax tree are checked one by one. If there are values ​​that exceed the travel range of the corresponding axis, they are marked as abnormal parameters and a verification error is prompted. Loop instruction nodes in the initial syntax structure (such as G-code instructions containing repeated execution logic) are identified, and according to parameters such as the number of loops and step size, they are split into multiple consecutive motion instruction node sequences (such as expanding the G91G01X10K5 loop instruction into 5 consecutive G91G01X10 instruction nodes). By integrating the syntax nodes after redundancy removal, parameter validation (after correcting abnormal parameters), and loop unrolling, the hierarchical structure is reconstructed according to the original execution order to form a structured G-code abstract syntax tree containing complete instruction logic, parameter information, and modal states.

[0048] S103. The G-code abstract syntax tree is mapped and converted into function block calls and logic statements conforming to the IEC 61131-3 standard.

[0049] Specifically, function block invocation refers to the instantiation and invocation of predefined or user-defined function blocks in the IEC 61131-3 standard language to implement specific control functions. A function block is a modular unit that encapsulates specific logic (such as motion control or signal processing), containing input parameters, output parameters, and internal states (such as the MC_MoveLinear linear motion function block in the PLCopen standard). Logic statements are sequences of instructions in the IEC 61131-3 standard language used to describe control logic relationships and implement functions such as conditional judgments and timing control.

[0050] In specific implementation, the mapping of the G-code abstract syntax tree into function block calls and logical statements conforming to the IEC 61131-3 standard includes:

[0051] (1) Extract multiple instruction node information from the G-code abstract syntax tree; each instruction node is associated with a corresponding parameter subset and modal state attribute.

[0052] Specifically, instruction node information is a complete data set corresponding to a single G-code instruction extracted from the G-code abstract syntax tree. It contains the instruction's core identifier and functional characteristics, including: instruction identifier (e.g., G01, M03), the instruction's functional category (e.g., motion control, auxiliary function), the instruction's execution order number in the program, and the index information of the parameter subset and modal state attributes associated with the instruction. The parameter subset is a set of key-value pairs associated with a specific instruction node, used to define the specific execution parameters of that instruction; it is a subset of the parameter list in the G-code abstract syntax tree. For example, the parameter subset of the G01 (linear interpolation) instruction node might contain {X:100.5, Y:50.0, F:200}, where X and Y are coordinate parameters, and F is the feed rate parameter, serving only the execution of this linear interpolation instruction. Modal state attributes are state information carried by instruction nodes that reflect the current program's operating mode and may affect the execution of subsequent instructions. These include: the current interpolation mode (e.g., linear interpolation, circular interpolation), coordinate system type (e.g., G54 workpiece coordinate system), unit mode (e.g., millimeters / inch), and feed rate mode (e.g., G98 feed per minute). These attributes are continuous; if subsequent instructions do not explicitly change them, they will automatically inherit the modal state of the preceding instructions.

[0053] In practical implementation, the root node of the G-code abstract syntax tree is traversed, and all program segment-level child nodes are located sequentially. For each instruction node, its core information is extracted: instruction identifier (e.g., G01, M03), function category label (e.g., motion control, assistive function), and execution order number. From the parameter list child node of this instruction node, all combinations of parameter identifier-parameter value-unit are extracted to form a parameter subset bound to the current instruction (e.g., {X:100, Y:50, F:200} corresponding to instruction G01). The modal state child node associated with this instruction node is read, and state information such as interpolation mode, coordinate system type, and unit mode is extracted as the modal state attributes of the current instruction. An association mapping is established, binding the extracted instruction node information with its corresponding parameter subset and modal state attributes to form a complete instruction node data unit, which is stored as a node list according to the execution order.

[0054] (2) Based on different instruction node information, convert them into corresponding function block calls or logical statements.

[0055] The instruction node information includes motion instruction nodes, auxiliary instruction nodes, coordinate system instruction nodes, and process control instruction nodes.

[0056] Specifically, motion command nodes are nodes in the G-code abstract syntax tree that correspond to motion control commands. They are used to describe the motion trajectory and mode of the tool or axis. The core includes: command identifiers, such as G00 (rapid traverse), G01 (linear interpolation), G02 / G03 (circular interpolation), etc.; parameter subsets, including axis coordinates (X, Y, Z, etc.), feed rate (F), radius of arc (R), and other motion parameters; and modal state attributes, which are associated with the current interpolation mode and feed mode (such as G98 / G99).

[0057] Auxiliary instruction nodes are nodes corresponding to auxiliary function instructions, used to control the switching or operation of machine tool auxiliary equipment. The core includes: instruction identifiers: such as M03 (spindle forward rotation), M05 (spindle stop), M08 (cooling on), M30 (program end), etc.; parameter subsets: including spindle speed (S), auxiliary equipment working parameters, etc.; modal state attributes: associated with auxiliary equipment operating modes such as spindle state, cooling system state, etc.

[0058] The coordinate system instruction node corresponds to coordinate system setting and switching instructions. It is used to define the machining reference coordinate system. The core includes: instruction identifier: such as G54 (workpiece coordinate system 1), G59 (workpiece coordinate system 6), G90 (absolute coordinates), G91 (relative coordinates), etc.; parameter subset: including coordinate system offset (such as the offset parameter set by G10), etc.; modal state attributes: associated with the currently active coordinate system type, coordinate representation method (absolute / relative), etc.

[0059] Flow control instruction nodes are nodes that correspond to program execution flow control instructions, used to control the execution order of G-code programs. The core includes: instruction identifiers: such as G04 (pause), M98 (call subroutine), M99 (subroutine end), G70-G89 (fixed loop), etc.; parameter subsets: including pause time (P), subroutine number (L), loop count (K), etc.; modal state attributes: associated with flow control states such as loop execution state and subroutine call level.

[0060] In specific implementation, the conversion of different instruction node information into corresponding function block calls or logical statements includes: for motion instruction nodes, conversion into PLCopen motion control function block calls, wherein the PLCopen motion control function block calls contain input parameters corresponding to a subset of node parameters; for auxiliary instruction nodes and coordinate system instruction nodes, conversion into custom function block calls or axis parameter configuration function calls; wherein the switch parameters of auxiliary instruction nodes are mapped to the enable input of the function block, and the offset parameters of coordinate system instruction nodes are mapped to the parameter list of the configuration function; for flow control instruction nodes, conversion into ST language logical statements.

[0061] Specifically, the identifier of the motion command node (such as G01, G02) is identified, and the corresponding PLCopen motion control function block is matched (such as G01 corresponding to MC_MoveLinear, G02 corresponding to MC_MoveCircular); the axis coordinates (X, Y, etc.) and feed rate (F) are extracted from the parameter subset of the node and mapped to the input parameters of the function block (such as Position, Velocity); the function block call statement is generated in the format of "function block name (axis identifier:=corresponding axis, parameter 1:=parameter value 1, parameter 2:=parameter value 2...)" (such as MC_MoveLinear(Axis:=AxisX, Position:=100.0, Velocity:=50.0)). Identify the identifiers of auxiliary command nodes (e.g., M03, M08), and match them with the corresponding custom function blocks (e.g., M03 corresponds to SpindleForward, M08 corresponds to CoolantOn); extract switch parameters (e.g., spindle speed S) from the parameter subset and map them to the enable input parameters of the function blocks (e.g., Enable, Speed); generate custom function block call statements (e.g., SpindleForward(Enable:=TRUE, Speed:=3000)). Identify the identifiers of coordinate system command nodes (e.g., G54, G90), and match them with the corresponding axis parameter configuration functions (e.g., G54 corresponds to SetWorkCoordinate, G90 corresponds to SetAbsoluteMode); extract parameters such as coordinate system offset from the parameter subset and organize them into a parameter list for the configuration function; generate configuration function call statements (e.g., SetWorkCoordinate(OffsetX:=10.0, OffsetY:=5.0)). Identify the identifiers of flow control instruction nodes (such as G04, M98) and convert them into corresponding ST language logic statements; for G04 (pause) instructions, generate delay statements (such as "TIMER(IN:=TRUE, PT:=T#1S)"); for M98 / M99 (subroutine call / end) instructions, generate subroutine call and return statements (such as "CALLSubProgram1;" and "RETURN;"); for fixed loop instructions, generate FOR / DO loop statements containing loop conditions and motion instructions (such as "FORi:=1TO5DO...END_FOR").

[0062] For example, in one embodiment, the motion instruction G01 is converted into the Plcopen motion control function block MCMoveLinear, the auxiliary instruction M03 is converted into the custom function block Spindle_Control(Enable=1), the coordinate system instruction G54 is converted into the axis parameter configuration function AxisSetWorkOffset0, and the flow control instruction GOTO is converted into the ST language branch JMPLABEL.

[0063] The method provided in this embodiment maps motion command nodes to PLCopen motion control function block calls, allowing direct reuse of mature motion control logic (such as interpolation algorithms and speed planning) from standardized function blocks. This ensures machining trajectory accuracy and equipment compatibility. Simultaneously, the correspondence between parameter subsets and function block input parameters enables precise transmission of G-code motion parameters to control logic. Converting auxiliary commands and coordinate system command nodes into custom function blocks or configuration function calls retains the flexibility of manufacturer-specific auxiliary functions (adapted through custom function blocks) while standardizing the expression of auxiliary logic and coordinate system settings through parameter mapping (switch quantities corresponding to enable inputs, offset parameters corresponding to configuration lists). Converting flow control command nodes into ST language logic statements utilizes the flow control capabilities of structured text (such as conditional branches and loops) to accurately replicate G-code execution logic. This layered mapping approach leverages the professionalism of G-code in trajectory description and utilizes IEC... The function blocks and logic statements of the 61131-3 standard realize the standardization and modularization of control logic, ultimately enabling hybrid control programs to combine the precision of CNC machining with the standardization of industrial control. This solves the coordination problem caused by the differences in syntax and execution logic between the two languages, improves the program's compatibility, maintainability, and execution efficiency, and meets the real-time and reliability requirements of the "control-machining" integration.

[0064] (3) Based on the modal state attributes of the G-code abstract syntax tree, a state machine model is used to maintain the state continuity of function block calls and logical statements. When a switch of modal instruction node in the G-code abstract syntax tree is detected, the modal parameters of the associated function block or the conditional expression of the logical statement are automatically updated. The parameter update process includes the data type converter to adapt the modal parameters to the type.

[0065] In practical implementation, the state machine model is initialized, and initial modal state attributes (such as initial interpolation mode and coordinate system type) from the G-code abstract syntax tree are loaded as the initial state baseline for function block calls and logical statements. The instruction nodes of the G-code abstract syntax tree are traversed in execution order, and changes in modal state attributes are obtained in real time: if the modal state attribute of the current instruction node is consistent with the previous node, the modal parameters of the associated function block and the conditional expressions of the logical statements remain unchanged; if a modal instruction node switch is detected (such as an interpolation mode switch from G01 to G02, or a coordinate system switch from G54 to G55), the state machine model update mechanism is triggered. For instruction nodes with modal switching, new modal parameters (such as circular interpolation direction and new coordinate system offset) are extracted, and a data type converter is called to perform type adaptation processing on the parameters (such as converting the string parameters of the G-code to numeric parameters supported by the function block). Based on the transformed modal parameters, the modal parameters of associated function blocks are automatically updated (e.g., updating the Direction parameter of the MC_MoveCircular function block from Linear to Clockwise), or the conditional expressions of logical statements are modified (e.g., updating the coordinate system judgment condition from CurrentCoord=G54 to CurrentCoord=G55). The state machine model records the updated modal state attributes as the state reference for subsequent instruction node transformations.

[0066] For example, in one embodiment, a state machine model is used to maintain G-code modal instructions (such as G01 interpolation mode being continuously valid). When a modal switch is detected, the parameters of the corresponding function block are automatically updated (e.g., switching the Mode parameter of MC_MoveLinear from "fast" to "straight"). A data type converter is used to adapt the G-code parameters to the types of IEC variables. For example, X100.5 (mm) in the G-code is converted to a REAL type variable Axis_X.Target := 100.5, and S1500 (rpm) is converted to an INT type variable Spindle_Speed ​​:= 1500.

[0067] S104. The converted content is integrated with the IEC 61131-3 standard language code, and then compiled to generate executable code.

[0068] Specifically, executable code refers to binary machine code or intermediate code that can be directly recognized and executed by a programmable logic controller (PLC) after being generated by uniformly compiling the converted function block calls, logic statements, and the original IEC 61131-3 standard language code. It integrates the control logic converted from G code (such as motion control function blocks, auxiliary function calls, and flow control statements) with the control logic written in the original IEC 61131-3 standard language (such as variable declarations and logic execution parts). It contains complete "machining trajectory - equipment action - logic control" coordinated execution instructions, which can directly drive the PLC and associated CNC machine tools and other equipment to run according to preset programs, realizing the integrated control of CNC machining and industrial automation.

[0069] In specific implementation, the structure of the IEC 61131-3 standard language code is parsed, distinguishing between the declaration part used to define variables and the execution part used to implement control logic. Interactive variables corresponding to the converted content are added to the declaration part, and the data type of these interactive variables is consistent with the converted type of the G-code parameters. The mapped and converted function block calls and logical statements are embedded into the execution part according to the original G-code positions in the hybrid program, forming fused code. A cross-domain variable association mechanism is established to bind the parameters of the converted content in the fused code to the logical variables of the IEC 61131-3 standard language code. The extended IEC 61131-3 compiler is called to compile the fused code, generating executable code.

[0070] Specifically, the IEC 61131-3 standard language code is scanned using a syntax analysis tool to identify and separate the variable declaration section (e.g., VARAXisX:AXIS_REF; FeedRate:REAL; END_VAR) from the control logic execution section (e.g., IFStartButtonTHEN...END_IF). Based on the parameter requirements of the converted function block calls and logic statements, corresponding interactive variables are added to the variable declaration section. For example, for the feed rate parameter converted from G-code, a new variable G_FeedRate:REAL is added, ensuring that its data type completely matches the type of the converted G-code parameter (e.g., floating-point, Boolean). Locate the start and end positions of the G-code segments in the original hybrid program, and embed the mapped and transformed function block calls (such as MC_MoveLinear(Axis:=AxisX, Position:=G_Xpos, Velocity:=G_FeedRate)) and logical statements (such as IFG_PauseTHENTIMER(IN:=TRUE, PT:=G_DwellTime); END_IF) into the corresponding positions in the execution part in the original order, forming fused code containing two types of logic. Through a variable binding mechanism, establish a mapping relationship between the parameters of the transformed content in the fused code (such as feed rate F) and the logical variables of the original IEC 61131-3 code (such as FeedRate_Set). Call the extended IEC 61131-3 compiler to perform syntax checking, intermediate code generation, and target code optimization on the fused code, and finally output binary machine code that can be directly executed by the PLC (or intermediate code that conforms to the PLC execution specification).

[0071] S105. Execute the executable code according to the preset task scheduling rules, and collect hardware execution data in real time as feedback information.

[0072] Specifically, the feedback information consists of real-time hardware operation data collected through the hardware interface during the execution of the executable code according to the preset task scheduling rules. This data reflects the actual operating status of the equipment and the task execution status. Specifically, it includes: real-time motion parameters such as position, speed, and acceleration of each axis of the equipment; auxiliary equipment operation data such as spindle speed and cooling system on / off status; equipment status parameters such as load current and temperature during the machining process; and status indicators indicating whether the task execution is normal (e.g., whether overtravel or fault alarms have occurred).

[0073] In specific implementation, the instructions in the executable code are classified according to their functional types. Instructions involving axis motion control and interpolation calculation are classified as real-time instructions, while instructions involving auxiliary function switches and status queries are classified as non-real-time instructions. A first task queue is allocated to the real-time instructions, and a second task queue is allocated to the non-real-time instructions. The first task queue has a higher priority than the second task queue. The executable code is executed sequentially according to the queue priority. During the execution of real-time instructions, interpolation calculations are performed on continuous motion instructions in advance to generate an interpolation point sequence, and trajectory errors are controlled through a buffer. Data during the execution process is collected in real time through a hardware interface, and the collected raw data is converted into feedback information corresponding to the G-code format. The correlation between the feedback information and the corresponding instructions in the executable code is established.

[0074] Specifically, the instructions in the executable code are identified, and those involving axis motion control and interpolation calculations are marked as real-time instructions (such as MC_MoveLinear function block calls), while those involving auxiliary function switches and status queries are marked as non-real-time instructions (such as SpindleForward function block calls and status variable query statements). A first task queue and a second task queue are created. Real-time instructions are placed in the first task queue, and non-real-time instructions are placed in the second task queue, with the first task queue having a higher priority than the second. Real-time instructions in the first task queue are executed first, and non-real-time instructions in the second task queue are executed during the intervals between or after the execution of real-time instructions. During the execution of real-time instructions in the first task queue, interpolation calculations are performed on continuous motion instructions in advance to generate an interpolation point sequence. This sequence is stored in a buffer, and the output rhythm of the interpolation points is controlled to reduce trajectory errors. Raw data (such as actual axis position and spindle speed) during the device's execution process is collected in real-time through hardware interfaces (such as sensor and encoder interfaces), and the raw data is converted into feedback information corresponding to the G-code format (such as feedback information X=99.8, Y=49.9, F=200). Furthermore, the converted feedback information is bound to the corresponding instructions in the executable code, and the actual execution data of each instruction is recorded (such as the actual endpoint coordinates of the feedback corresponding to a certain G01 instruction).

[0075] S106. Based on the feedback information, the G code and the IEC 61131-3 standard language code are jointly debugged to obtain a hybrid control program suitable for industrial control scenarios.

[0076] Specifically, joint debugging refers to the process of collaboratively debugging a hybrid program composed of G-code and IEC61131-3 standard language code, using real-time acquired hardware execution feedback information. The hybrid control program is the final program form suitable for industrial control scenarios after joint debugging. It integrates the machining trajectory description function of G-code with the logic control function of IEC61131-3 standard language.

[0077] In specific implementation, associated breakpoints are set in the G-code segment and the IEC 61131-3 standard language code segment of the hybrid program. When the program executes to the associated breakpoint, the hardware execution data, G-code modal state, and real-time values ​​of IEC 61131-3 standard language variables in the feedback information are acquired synchronously. Based on the actual axis position data in the hardware execution data, the actual machining path is reconstructed in the virtual coordinate system and compared with the preset theoretical trajectory. The abnormal point of the motion control logic is located by calculating the trajectory error. The feedback information and program execution log are associated according to the time axis, and the execution time of the G-code instruction, the corresponding modal state change, the numerical jump of the IEC 61131-3 standard language variable, and the response of the hardware execution data are associated and bound. When the trajectory error exceeds the limit, the abnormal point between the two types of codes is located by comparing the modal state and the IEC variable value at the same time point. According to the abnormal point, the G-code parameters or the control logic of the IEC 61131-3 standard language are adjusted, the executable code is repeatedly executed, and new feedback information is collected for verification until the trajectory accuracy meets the requirements of the industrial control scenario, and the final hybrid control program is obtained.

[0078] Specifically, associated breakpoints are set at key instructions in the G-code segment of the mixed program (such as G01, G02) and at function block calls in the IEC 61131-3 code (such as MC_MoveLinear, SpindleForward) to ensure that the execution of both types of code is paused synchronously when the breakpoint is triggered. When the program executes to the associated breakpoint, it reads the hardware execution data (such as the real-time position of the axis encoder and the spindle speed sensor data), the current modal state of the G-code (such as the interpolation mode and coordinate system type), and the real-time values ​​of IEC 61131-3 variables (such as the axis enable signal and feed rate variables) from the feedback information through the debugging interface, and stores these data in association with timestamps. The actual position coordinates of each axis (e.g., X=100.2, Y=50.1) are extracted from the hardware execution data. These coordinate points are connected in chronological order in the virtual coordinate system to reconstruct the actual machining path. Simultaneously, the theoretical trajectory corresponding to the G-code segment (e.g., the CAD design path) is retrieved. By calculating the deviation between the actual and theoretical positions point by point (e.g., ΔX=0.2mm), abnormal points in the motion control logic (e.g., an error exceeding the standard in a certain circular interpolation segment) are located. Feedback information and program execution logs are aligned according to millisecond-level time axes to establish a multi-dimensional correlation table: recording the execution time of the G-code instruction (e.g., G01 is executed at T100ms), the corresponding modal state change (e.g., switching from G90 to G91), the numerical jump of IEC variables (e.g., FeedRate changes from 200 to 300), and the response of hardware data (e.g., the axis speed reaches 300mm / min at T102ms). When a trajectory error exceeding the limit is detected (e.g., ΔX > 0.5mm), the corresponding time point is located in the association table. The G-code modal state (e.g., whether it is in relative coordinate mode) and IEC variable values ​​(e.g., whether the position command is correctly transmitted) are extracted at this time. By comparing the matching of the two (e.g., when the modal state is G91, whether the IEC variable is calculated according to the relative value), it is determined whether the anomaly originates from an error in the G-code parameters or an IEC logic transmission problem. Based on the located anomaly point, the corresponding parts are adjusted: if it is a G-code problem, the parameters are modified (e.g., changing X100 to X99.8); if it is an IEC logic problem, the function block parameters or conditional statements are adjusted (e.g., correcting the Position input variable of MC_MoveLinear). The adjusted program is recompiled, the executable code is executed, and new feedback information is collected. The above comparison and adjustment process is repeated until all trajectory errors are controlled within the allowable range of industrial scenarios (e.g., ΔX ≤ 0.01mm), and finally a hybrid control program that meets the requirements is generated.

[0079] The method provided in this embodiment, in its first aspect, breaks down the syntactic barriers between G-code and the IEC 61131-3 standard language by classifying and mapping different instruction nodes in the G-code abstract syntax tree. Motion instruction nodes correspond to PLCopen standardized motion control function block calls, auxiliary and coordinate system instruction nodes correspond to custom function block or configuration function calls, and flow control instruction nodes correspond to ST language logic statements. At the same time, it maintains the continuity of modal states by using a state machine model and adapts parameter types by using a data type converter. It not only reuses the mature control logic of standardized function blocks (such as interpolation algorithms) but also achieves accurate conversion from G-code semantics to industrial control logic. This solves the problems of poor compatibility and logical gaps in traditional manual conversion interfaces and innovatively constructs an automated mapping system of "G-code semantics - standardized function blocks - control logic".

[0080] Secondly, by building a multi-vendor G-code rule library, it stores the mapping relationship and syntax difference rules between different vendor-specific instructions and ISO 6983 standard general instructions. Combined with regular expression matching algorithms, it automatically identifies and converts vendor-specific G-code without the need to customize conversion interfaces for different vendors. Compared with the multi-step format conversion of traditional dedicated middleware, it significantly reduces the adaptation cost, improves the compatibility of multi-brand devices, and realizes the "one-click standardization" processing of multi-vendor G-code.

[0081] Thirdly, by classifying the instructions in the executable code involving axis motion control and interpolation calculation as real-time instructions and assigning them to the high-priority first task queue, and classifying auxiliary function switch and status query instructions as non-real-time instructions and assigning them to the low-priority second task queue, the real-time tasks are executed first, and interpolation calculations for continuous motion instructions are performed in advance. The trajectory error is controlled through the buffer, which avoids interference from the execution of auxiliary instructions on motion control. This meets the stringent real-time requirements of motion control in industrial scenarios, effectively ensures the accuracy of the machining trajectory, and solves the trajectory deviation problem caused by the disordered execution of instructions in traditional integration methods.

[0082] Fourthly, by setting associated breakpoints in the G-code segment and IEC 61131-3 code segment of the mixed program, hardware execution data, G-code modal states, and real-time values ​​of IEC variables are obtained synchronously. This not only supports comparing the actual and theoretical processing paths in the virtual coordinate system to locate motion logic anomalies, but also associates the execution logs, variable jumps, and hardware responses of the two types of codes along the time axis. This allows for precise location of cross-language parameter transmission errors (such as mismatch between modal states and IEC variables) or logic coordination problems. Compared with the traditional separate debugging method that cannot trace cross-language causal relationships, this significantly shortens the troubleshooting time and achieves closed-loop tracing of "processing trajectory anomalies - code logic problems".

[0083] Corresponding to the aforementioned embodiment of the IEC 61131-3 programming system integration G-code method, this application also provides an embodiment of the IEC 61131-3 programming system integration G-code device.

[0084] Figure 2 This is a schematic diagram of the structure of the IEC 61131-3 programming system integrated G-code device provided in Embodiment 2 of this application. Please refer to... Figure 2 The device provided in this embodiment includes a writing module 210, a processing module 220, a fusion module 230, an execution module 240, and a debugging module 250.

[0085] The writing module 210 is used to write mixed programs that simultaneously contain G code and IEC 61131-3 standard language code in the extended IEC 61131-3 programming environment.

[0086] The processing module 220 is used to standardize the G code in the hybrid program and generate a structured G code abstract syntax tree;

[0087] The processing module 220 is also used to map the G-code abstract syntax tree into function block calls and logic statements conforming to the IEC 61131-3 standard;

[0088] The fusion module 230 is used to fuse the converted content with the IEC 61131-3 standard language code, and generate executable code after unified compilation;

[0089] The execution module 240 is used to execute the executable code according to the preset task scheduling rules and collect hardware execution data in real time as feedback information;

[0090] The debugging module 250 is used to perform joint debugging of the G code and the IEC 61131-3 standard language code based on the feedback information to obtain a hybrid control program suitable for industrial control scenarios.

[0091] The apparatus of this embodiment can be used to perform... Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.

[0092] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0093] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0094] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An IEC 61131-3 programming system integrated G-code method, characterized by, The method comprises: In the extended IEC 61131-3 programming environment, a hybrid program containing both G code and IEC 61131-3 standard language code is written; The G code in the hybrid program is standardized to generate a structured G code abstract syntax tree; The G code in the hybrid program is dialect converted, through a built-in multi-vendor G code rule library, to convert the special G code instructions of different vendors into a universal G code format conforming to the ISO 6983 standard; the standardized universal G code is parsed, the G code is scanned according to the preset syntax rules, the instruction identifier, parameter value and unit information are extracted, and the recursive descent analysis method is used to build a preliminary syntax structure, so that each G code instruction is parsed into a syntax node containing instruction type, parameter set and modal state; the preliminary syntax structure is optimized to eliminate redundant instruction nodes that are continuously repeated, to check the matching of coordinate values in the parameter set and the device axis stroke, to expand the loop instruction node into a sequence of multiple continuous motion instruction nodes, and to generate a structured G code abstract syntax tree; The G code abstract syntax tree is mapped and converted into function block calls and logic statements conforming to the IEC 61131-3 standard; The converted content is fused with the IEC 61131-3 standard language code, and executable code is generated after unified compilation; The executable code is executed according to the preset task scheduling rules, and hardware execution data is collected in real time as feedback information; The instructions in the executable code are classified by function type, instructions related to axis motion control and interpolation calculation are classified as real-time instructions, and instructions related to auxiliary function switches and state queries are classified as non-real-time instructions; the real-time instructions are assigned to a first task queue, and the non-real-time instructions are assigned to a second task queue; the priority of the first task queue is higher than that of the second task queue; the executable code is executed in order of queue priority, interpolation calculation is performed on continuous motion instructions in advance during real-time instruction execution to generate an interpolation point sequence, and trajectory error is controlled through a buffer; data in the execution process is collected in real time through a hardware interface, the collected raw data is converted into feedback information corresponding to the G code format, and an association between the feedback information and the corresponding instructions in the executable code is established; Based on the feedback information, the G code and the IEC 61131-3 standard language code are jointly debugged to obtain a hybrid control program suitable for industrial control scenarios.

2. The method of claim 1, wherein, The G code abstract syntax tree is mapped and converted into function block calls and logic statements conforming to the IEC 61131-3 standard, comprising: Extracting multiple instruction node information from the G code abstract syntax tree; each instruction node is associated with a corresponding parameter subset and modal state attribute; Based on different instruction node information, corresponding function block calls or logic statements are converted; Based on the modal state attribute of the G-code abstract syntax tree, a state machine model is used to maintain the state continuity of function block calls and logical statements, and when a modal instruction node switching in the G-code abstract syntax tree is detected, the mode parameters of the associated function block or the conditional expression of the logical statement is automatically updated; wherein the parameter updating process includes type adaptation processing of the modal parameters by the data type converter.

3. The method of claim 2, wherein, The instruction node information includes motion instruction nodes, auxiliary instruction nodes, coordinate system instruction nodes, and flow control instruction nodes; and based on different instruction node information, corresponding function block calls or logical statements are converted, including: For motion instruction nodes, PLCopen motion control function block calls are converted, and the PLCopen motion control function block calls include input parameters corresponding to a subset of node parameters; For auxiliary instruction nodes and coordinate system instruction nodes, custom function block calls or axis parameter configuration function calls are converted; wherein the on-off quantity parameters of the auxiliary instruction nodes are mapped to the enable inputs of the function blocks, and the offset parameters of the coordinate system instruction nodes are mapped to the parameter list of the configuration function; For flow control instruction nodes, logical statements in ST language are converted.

4. The method of claim 1, wherein, The standardized universal G-code is parsed, the G-code is lexically scanned according to the preset syntax rules, the instruction identifiers, parameter values and unit information are extracted, and the initial syntax structure is constructed by using the recursive descent analysis method, including: The universal G-code is scanned in character sequence, and the instruction units are identified and segmented according to the preset lexical rules; wherein a sequence starting with a letter is identified as an instruction identifier, in a combination of letters and numbers following the instruction identifier, the letter part is identified as a parameter identifier, and the number or number sequence with a decimal point is identified as a parameter value, and the unit information associated with the parameter value is extracted; A lexical symbol table is established, and the extracted instruction identifiers, parameter identifiers, parameter values and unit information are stored in the lexical symbol table in the order of appearance; wherein the instruction identifiers are associated with corresponding function categories, and the parameter identifiers are associated with corresponding axis identifiers or function attributes; Based on the recursive descent analysis method, the lexical symbol table is taken as input, the program segment level syntax structure is first identified, a single G-code is divided into a program segment unit of an instruction identifier and a parameter list, the parameter list is a set composed of multiple parameter identifiers and parameter values, the parameter level syntax structure is then parsed, the binding relationship between each parameter identifier and parameter value in the parameter list is determined, a hierarchical syntax tree with the program segment unit as the parent node and the instruction identifier and the parameter list as the child nodes is constructed, and an initial syntax structure is formed.

5. The method of claim 1, wherein, The converted content is fused with the IEC 61131-3 standard language code, and after unified compilation, executable code is generated, including: The structure of the IEC 61131-3 standard language code is parsed, the declaration part for defining variables and the execution part for implementing control logic are distinguished, an interactive variable corresponding to the converted content is added in the declaration part, and the data type of the interactive variable is consistent with the type after conversion of the G-code parameters; The mapping converted function block call and logic statement are embedded into the execution part according to the position of the G code in the hybrid program, forming a fusion code; A cross-domain variable association mechanism is established to bind the parameters of the converted content in the fusion code with the logic variables of the IEC 61131-3 standard language code; An extended IEC 61131-3 compiler is called to compile the fusion code to generate executable code.

6. The method of claim 1, wherein, The joint debugging of the G code and the IEC 61131-3 standard language code based on the feedback information to obtain a hybrid control program suitable for an industrial control scenario includes: Setting associated breakpoints in the G code segment and the IEC 61131-3 standard language code segment of the hybrid program, synchronously acquiring the hardware execution data, the G code modal state, and the real-time value of the IEC 61131-3 standard language variable in the feedback information when the program executes to the associated breakpoint; Based on the actual position data of the shaft in the hardware execution data, the actual machining path is reconstructed in a virtual coordinate system and compared with the preset theoretical trajectory to locate the abnormal point of the motion control logic by calculating the trajectory error; The feedback information and the program execution log are associated according to the time axis, and the execution time of the G code instruction, the corresponding modal state change, the numerical jump of the IEC 61131-3 standard language variable, and the response of the hardware execution data are associated and bound, and when the trajectory error exceeds the limit, the modal state and the IEC variable value at the same time point are compared to locate the abnormal point between the two types of codes; According to the abnormal point, the G code parameters or the control logic of the IEC 61131-3 standard language are adjusted, the executable code is repeatedly executed, and new feedback information is collected for verification until the trajectory precision meets the requirements of the industrial control scenario, and the final hybrid control program is obtained.

7. The method of claim 1, wherein, The hybrid program containing G code and IEC 61131-3 standard language code is written in the extended IEC 61131-3 programming environment, including: In the extended IEC 61131-3 programming environment, the code area is divided by embedding markers, and in the code editing area, the G code segment is embedded between the start marker and the end marker, and the embedded G code segment supports continuous writing of multiple program segments; IEC 61131-3 standard language code is written in the area outside the embedding marker, and the IEC 61131-3 standard language code uses ST structured text language; The two types of codes are differentially displayed through a syntax highlighting module, and the integrity of the embedding marker is verified in real time to obtain a hybrid program.

8. An IEC 61131-3 programming system integrated G-code apparatus, characterized by, The device includes a writing module, a processing module, a fusion module, an execution module, and a debugging module; The writing module is configured to write a hybrid program containing G code and IEC 61131-3 standard language code in an extended IEC 61131-3 programming environment; The processing module is configured to standardize the G code in the hybrid program to generate a structured G code abstract syntax tree; The G code in the mixed program is dialect converted, different manufacturer-specific G code instructions are converted into general G code format conforming to the ISO 6983 standard by using a regular matching algorithm through a built-in multi-manufacturer G code rule library; the standardized general G code is parsed, G code is scanned according to a preset syntax rule, an instruction identifier, a parameter value and unit information are extracted, and a preliminary syntax structure is constructed by using a recursive descent analysis method, so that each G code instruction is parsed into a syntax node containing an instruction type, a parameter set and a modal state; the preliminary syntax structure is optimized, redundant instruction nodes that are continuously repeated are removed, the matching of coordinate values in a parameter set and equipment axis travel is checked, a loop instruction node is expanded into a sequence of multiple continuous motion instruction nodes, and a structured G code abstract syntax tree is generated; The processing module is further configured to map and convert the G code abstract syntax tree into function block calls and logic statements conforming to the IEC 61131-3 standard; The fusion module is configured to fuse the converted content with the IEC 61131-3 standard language code, and generate executable code after unified compilation; The execution module is configured to execute the executable code according to a preset task scheduling rule, and collect hardware execution data in real time as feedback information; The executable code is classified according to function types, instructions related to axis motion control and interpolation calculation are classified as real-time instructions, and instructions related to auxiliary function switches and state queries are classified as non-real-time instructions; the real-time instructions are assigned to a first task queue, and the non-real-time instructions are assigned to a second task queue; the priority of the first task queue is higher than that of the second task queue; executable code is executed according to queue priority, interpolation calculation is performed on continuous motion instructions in advance during real-time instruction execution, and an interpolation point sequence is generated to control trajectory error through a buffer; data in the execution process is collected in real time through a hardware interface, raw data collected is converted into feedback information corresponding to the G code format, and an association between the feedback information and corresponding instructions in the executable code is established; The debugging module is configured to jointly debug the G code and the IEC 61131-3 standard language code based on the feedback information, and obtain a mixed control program suitable for an industrial control scene.

Images