PLC development system and method for realizing low PLC code programming and PLC controller

Abstract

The invention provides a PLC (programmable logic controller) development system for realizing low PLC code programming, which comprises a PLC IDE (integrated development equipment) used for exporting PLC program symbol information containing I / O (input / output) variables, tasks or functional methods; the UI process low-code programming environment is used for receiving the PLC program symbol information and providing a graphical user interface based on the PLC program symbol information, so that a user can directly quote the I / O variables, tasks or functional methods in the process of visual arrangement of the process logic to construct the process logic and generate a corresponding process formula file; the PLC is used for generating a program code according to the process formula file and compiling the program code into a machine code; and loading the machine code into the PLC RUNTIME environment to operate. The invention further provides a corresponding controller and a development method. According to the invention, the PLC architecture supporting low-code programming can be provided, so that the development efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of industrial automation control technology, and in particular to a PLC development system, method and PLC controller for implementing low-level PLC code programming. Background Technology

[0002] In industrial automation control, especially in scenarios such as smart manufacturing and IoT device control, most PLC programming still relies on the IEC 61131-3 standard language, which requires professional engineers to write the underlying code. This not only results in a long development cycle but also places high demands on the professional background of process engineers, making it difficult to meet the actual needs of modern manufacturing systems for rapid process reconfiguration, visual debugging, and real-time updates.

[0003] In existing low-code PLC development solutions, on the one hand, users often need to define a large amount of PLC program symbol information, including I / O variables, tasks, function blocks, etc., which is not conducive to improving development efficiency. On the other hand, existing PLC development solutions directly generate program code. Since the program code is generally targeted at the target PLC, the reusability of the program code is poor, which is also not conducive to improving development efficiency.

[0004] Therefore, in this context, how to provide a PLC controller architecture that supports low-code programming to improve development efficiency is a technical problem that needs to be solved. Summary of the Invention

[0005] In view of the above-mentioned problems of the prior art, this application provides a PLC development system, method and PLC controller for realizing low PLC code programming, so as to improve development efficiency.

[0006] To achieve the above objectives, the first aspect of this application provides a PLC development system for implementing low-level PLC code programming, comprising:

[0007] PLC IDE is used to export PLC program symbol information containing I / O variables, tasks, or function methods;

[0008] The UI process low-code programming environment is used to receive the PLC program symbol information and provide a graphical user interface based on the PLC program symbol information, so that users can directly reference the I / O variables, tasks or function methods during the process of visually arranging the process logic to construct the process logic and generate the corresponding process recipe file.

[0009] The PLC controller is used to generate program code based on the process recipe file and compile it into machine code; and to load the machine code into the PLC runtime environment for execution.

[0010] Therefore, this application can export PLC program symbol information containing I / O variables, tasks, or functional methods from the PLC IDE and provide it to the UI low-code programming environment, eliminating the need for users to define PLC program symbol information and improving development efficiency. Furthermore, this application does not directly generate program code; instead, it first generates a recipe file and then generates program code based on the recipe file, decoupling the user writing process from the program code generation process. This allows the recipe file, as a process file, to be reused in other PLC code development processes, or to achieve partial updates rather than full updates during program code updates, all of which improve development efficiency.

[0011] As one possible implementation of the first aspect, the PLC controller operates a non-real-time system and a real-time system, which exchange data including the machine code through shared memory;

[0012] The non-real-time system runs a code generation engine, which generates program code based on the process recipe file and compiles it into machine code.

[0013] The real-time system runs the PLC RUNTIME environment, which is used to load the machine code into the PLC RUNTIME environment for execution.

[0014] Therefore, by using a coexistence of non-real-time and real-time systems, resource-intensive and time-consuming code generation and compilation tasks are handled by the non-real-time system, while the real-time system is responsible for loading machine code for task execution. Data is transferred via shared memory, avoiding latency caused by network protocols or hard drive read / write operations, thus meeting the rapid response requirements of industrial environments.

[0015] As one possible implementation of the first aspect, the non-real-time system also includes standard library symbol information, which the code generation engine links during compilation to complete the compilation of the program code.

[0016] In summary, by enabling the code generation engine to link standard library symbol information from non-real-time systems during compilation, it is ensured that the program code generated based on the process recipe can call existing industry standard functions.

[0017] As one possible implementation of the first aspect, the provision allowing users to directly reference the I / O variables, tasks, or functional methods during the visual orchestration of process logic includes:

[0018] The I / O variables, tasks, or functional methods in the PLC program symbol information are encapsulated as functional components and provided to the graphical user interface so that users can directly call the functional components to reference the corresponding I / O variables, tasks, or functional methods during the visualization and arrangement of process logic.

[0019] As described above, by encapsulating PLC program symbol information into functional components, the programming logic of the PLC IDE is transformed into reusable general modules, reducing the amount of repetitive development work and thus enabling rapid construction and modification of control logic.

[0020] As one possible implementation of the first aspect, the functional component includes functional blocks and migration conditions, and supports user customization in the graphical user interface;

[0021] The custom configuration includes setting the variables referenced by the function block, the actions to be performed, and / or the jump logic on which the migration conditions are based.

[0022] As described above, the custom configuration mechanism enables users to flexibly adjust the execution behavior and jump rules of the control logic according to specific process requirements, thereby achieving dynamic reconstruction and optimization of the automated process without modifying the underlying PLC code.

[0023] As one possible implementation of the first aspect, the visual orchestration includes at least one of the following operation methods:

[0024] Configure variables in function blocks and / or migration conditions;

[0025] Arrange function blocks and / or migration conditions in the graphical user interface by dragging and dropping;

[0026] Add connectors to define the execution order or data flow between function blocks, between function blocks and migration conditions, or between migration conditions.

[0027] As described above, the visual programming operation method transforms traditional PLC code programming into a graphical and interactive logic construction process, which significantly improves the intuitiveness, flexibility and engineering efficiency of process logic design.

[0028] As one possible implementation of the first aspect, generating the corresponding process formula file includes:

[0029] The visualized process logic is converted into a process recipe file described by a multi-layered structure, which includes a variable definition layer, a step execution layer, a process transition layer, and a process orchestration layer; wherein...

[0030] The variable definition layer is used to define the variables that need to be used in the process. The variables are generated based on the variables configured by the user in the function block and / or migration conditions.

[0031] The step execution layer is used to define each of the functional blocks in the process, and each functional block includes one or more control actions;

[0032] The process jump layer is used to define the transfer logic between steps in the process. The transfer logic originates from the jump conditions set by the user in the migration conditions.

[0033] The process orchestration layer is used to define the process formed by the various steps, which is determined based on the execution order or data flow established by the user in the graphical user interface through connection lines.

[0034] As described above, by converting the process logic into a formula file with a specific multi-layered structure (variable definition layer, step execution layer, process jump layer, and process orchestration layer), a structured and standardized description of the process logic is achieved. This improves the maintainability and reusability of the process formula file.

[0035] As one possible implementation of the first aspect, the step of generating program code based on the process formula file and compiling it into machine code includes:

[0036] Generate program code for each layer based on the process formula file described in the multi-layer structure;

[0037] The program code for each corresponding layer is compiled into machine code encapsulated in the form of multiple dynamic libraries for each corresponding layer.

[0038] As described above, by generating multiple corresponding dynamic libraries through a multi-layered structure based on the recipe file, the "on-demand compilation" of dynamic libraries becomes possible, thereby reducing the computational burden and improving control efficiency.

[0039] A second aspect of this application provides a PLC controller that operates a non-real-time system and a real-time system, wherein the non-real-time system and the real-time system exchange data via shared memory.

[0040] The non-real-time system runs a code generation engine, which generates program code based on the received process recipe file and compiles it into machine code.

[0041] The real-time system runs a PLC RUNTIME environment, which is used to obtain the machine code through the shared memory and load the machine code into the PLC RUNTIME environment for execution.

[0042] As one possible implementation of the second aspect, the code generation engine is specifically used to generate program code for each layer of the process recipe file described by the multi-layer structure, and to compile the program code for each layer into machine code encapsulated in the form of multiple dynamic libraries for each layer.

[0043] The third aspect of this application provides a PLC development method for implementing low-level PLC code programming, including:

[0044] Export PLC program symbol information containing I / O variables, tasks, or function methods from the PLC IDE;

[0045] The system receives the PLC program symbol information through the UI process low-code programming environment and provides a graphical user interface based on the PLC program symbol information. This allows users to directly reference the I / O variables, tasks, or functional methods during the visualization and arrangement of process logic to construct process logic and generate corresponding process recipe files.

[0046] The code generation engine running on the non-real-time system of the PLC controller generates program code based on the process recipe file and compiles it into machine code.

[0047] The machine code is loaded into the PLC RUNTIME environment running in the real-time system on the PLC controller.

[0048] A fourth aspect of this application provides a computing device, including: a processor and a memory storing program instructions thereon, the program instructions, when executed by the processor, causing the processor to execute the PLC code of any one of the first aspects of the development system.

[0049] The fifth aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a computer, cause the computer to execute the development system of the PLC code described in any of the first aspects.

[0050] The sixth aspect of this application provides a computer program product comprising program instructions that, when executed by a computer, cause the computer to execute the PLC code development system described in any of the first aspects. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of the architecture of the PLC code development system provided in the first embodiment of this application;

[0052] Figure 2a This is an architecture diagram of the PLC code development system provided in the second embodiment of this application;

[0053] Figure 2bThis is a schematic diagram of the UI low-code programming environment provided in the second embodiment of this application;

[0054] Figure 3a This is a flowchart of the PLC code development method provided in the third embodiment of this application;

[0055] Figure 3b This is a schematic diagram of the method for implementing functions in the PLC IDE provided in the third embodiment of this application;

[0056] Figure 3c This is a schematic diagram of configuring process tasks in the PLC IDE provided in the third embodiment of this application;

[0057] Figure 3d This is a schematic diagram of the UI technology low-code programming environment provided in the third embodiment of this application;

[0058] Figure 4 This is a schematic diagram of the PLC controller provided in the fourth embodiment of this application;

[0059] Figure 5 This is a schematic structural diagram of a computing device provided in an embodiment of this application.

[0060] It should be understood that the dimensions and shapes of the blocks in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of the present invention. The relative positions and inclusion relationships between the blocks presented in the structural diagrams are only schematic representations of the structural relationships between the blocks, and are not intended to limit the physical connection methods of the embodiments of the present invention. Detailed Implementation

[0061] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that the technical solutions provided in this application are equally applicable to similar technical problems as system architectures evolve and new business scenarios emerge.

[0062] It should be understood that the PLC code development solutions provided in the embodiments of this application include development systems, methods, computing devices, computer-readable storage media, and computer program products. Since these technical solutions solve problems based on the same or similar principles, some repetitive details may not be repeated in the following descriptions of specific embodiments. However, it should be considered that these specific embodiments have mutual references and can be combined with each other.

[0063] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application. To accurately describe the technical content of this application and to accurately understand the invention, the following explanations or definitions of the terms used in this specification are provided before describing specific embodiments:

[0064] 1) Low-code programming: A software development methodology that allows users to create applications through a graphical user interface and configuration, significantly reducing the amount of manual coding required compared to traditional hand-written code.

[0065] 2) PLC IDE: refers to Integrated Development Environment, which is used for the development, debugging and export of symbolic information (such as I / O variables, tasks and function blocks) of traditional PLC programs.

[0066] 3) Non-Real-Time System (Non-RTOS): refers to a general-purpose operating system (such as Linux) running on the controller, used to handle tasks that do not require strict timing guarantees, such as code generation, compilation, and communication.

[0067] 4) Real-Time System (RTOS): refers to the real-time operating system running on the controller, used to execute control tasks with strict time requirements and ensure deterministic response of the task.

[0068] 5) PLC RUNTIME (PLC Runtime Environment): refers to the software environment that runs in a real-time system and is used to execute the compiled control logic (machine code). It is responsible for core control functions such as scheduling tasks and managing I / O.

[0069] 6) Machine Code: refers to the sequence of instructions generated by compiling source code that can be directly executed by the CPU. Machine code exists in binary form.

[0070] 7) Shared Memory: An inter-process communication (IPC) mechanism that allows multiple processes (such as processes on a non-real-time system and processes on a real-time system) to access the same physical memory area for efficient data exchange.

[0071] 8) PLC Program Symbolic Information: This refers to identifiers in the PLC program that have readable names and represent actual hardware or logical functions. These identifiers can exist in the form of variable tables. For example, identifiers representing actual hardware may include I / O information, and identifiers representing logical functions may include task information and / or FB (function block) information.

[0072] 9) Dynamic Link Library: refers to a file that encapsulates a piece of machine code and can be called through dynamic loading or linking.

[0073] 10) Structured data: refers to data with a defined fixed format, uniform structure, and clear relationships. It can be stored in the form of tables, databases, or text.

[0074] For example, each row represents a record, and each column represents a field (such as name, age, or phone number), thus constituting structured data. Examples in this application may include: The attribute fields of a variable object include variable name, type, scope, and initial value; these fields constitute the structured data of the variable object. The attribute fields of a step object include step name, mode, calling method, input parameters, and output parameters; these fields constitute the structured data of the step object. The attribute fields of a jump object include source step, jump condition, and target location; these fields constitute the structured data of the jump object. The attribute fields of a process object include a list of step objects, execution order, and branching relationship; these fields constitute the structured data of the process jump object.

[0075] Below is an example of structured data described in JSON format. In this example, the fields of the variable object's properties include variable name, type, and scope:

[0076] {

[0077] "variableObjects": [

[0078] {

[0079] "Variable Name": "username",

[0080] Type: "string"

[0081] Scope: global

[0082] } ]

[0084] }

[0085] The PLC code development scheme provided in this application includes: a PLC IDE for exporting PLC program symbol information containing I / O variables, tasks, or functional methods; a UI low-code programming environment for receiving the PLC program symbol information and providing a graphical user interface based on the PLC program symbol information, allowing users to directly reference the I / O variables, tasks, or functional methods during the visual arrangement of process logic to construct process logic and generate corresponding process recipe files; a PLC controller for generating program code according to the process recipe file and compiling it into machine code; and loading the machine code into the PLC RUNTIME environment for execution. This system provides a PLC controller architecture that supports low-code programming to improve development efficiency. This application can be applied to various industrial, intelligent manufacturing, IoT devices, and research applications of programmable logic controllers (PLCs), such as process unit control, process control, equipment status monitoring and maintenance, intelligent warehousing, logistics systems, and equipment automation. The embodiments of this application are described in detail below with reference to the accompanying drawings.

[0086] The first embodiment of this application provides a PLC development system for implementing low-level PLC code programming. The following will be combined with... Figure 1 The implementation of each component of the system will be described in detail.

[0087] The development system for the PLC code in this application includes:

[0088] PLC IDE is used to export PLC program symbol information containing I / O variables, tasks, or function methods;

[0089] The UI process low-code programming environment is used to receive the PLC program symbol information and provide a graphical user interface based on the PLC program symbol information, so that users can directly reference the I / O variables, tasks or function methods during the process of visually arranging the process logic to construct the process logic and generate the corresponding process recipe file.

[0090] The PLC controller is used to generate program code based on the process recipe file and compile it into machine code; and to load the machine code into the PLC runtime environment for execution.

[0091] The PLC IDE provides configuration information for I / O variables, tasks, or functional methods (i.e., PLC program symbol information, or configuration information). This information can be exported in the form of a variable table and provided to the UI process low-code programming environment so that users can reference the I / O variables, tasks, and functional methods in the variable table during the process of visually arranging process logic.

[0092] In some embodiments, the PLC controller operates a non-real-time system and a real-time system, which exchange data including the machine code through shared memory;

[0093] The non-real-time system runs a code generation engine, which generates program code based on the process recipe file and compiles it into machine code.

[0094] The real-time system runs the PLC RUNTIME environment, which is used to load the machine code into the PLC RUNTIME environment for execution.

[0095] The non-real-time system also has a database, which provides the local variables and management variables required by the real-time system to the shared memory for the real-time system to call.

[0096] Among them, the non-real-time system can also be used to obtain machine code-related running information loaded into the PLC RUNTIME environment of the real-time system through shared memory, and provide it to the UI process low-code programming environment for display to the user.

[0097] The non-real-time system can use operating systems such as Linux; the real-time system can use systems such as FreeRTOS.

[0098] In some embodiments, the I / O variables, tasks, or functional methods in the PLC program symbol information are encapsulated as functional components and provided to the graphical user interface so that users can directly call the functional components to reference the corresponding I / O variables, tasks, or functional methods during the visualization and arrangement of process logic.

[0099] Among them, the UI process low-code programming environment can provide process libraries related to a certain type of industrial production control business, such as process libraries related to semiconductor manufacturing process flow, and encapsulate them into multiple functional blocks.

[0100] In some embodiments, the non-real-time system further includes standard library symbol information, which the code generation engine links during compilation to complete the compilation of the program code.

[0101] The standard library symbol information includes at least one of the following: C standard library symbols and IEC 61131 library symbols.

[0102] In some embodiments, the real-time system is also used to perform 61131 tasks, namely, scheduling and running control programs developed by the PLC IDE that conform to the IEC 61131-3 standard. Specifically, 61131 tasks are performed by calling functions (such as function blocks FB) and PLC variables in the IEC 61131 library.

[0103] In some embodiments, the functional component includes a functional block and migration conditions, and supports user customization in the graphical user interface;

[0104] The custom configuration includes setting the variables referenced by the function block, the actions to be performed, and / or the jump logic on which the migration conditions are based.

[0105] In some embodiments, the visual arrangement includes at least one of the following operation modes:

[0106] Configure variables in function blocks and / or migration conditions;

[0107] Arrange function blocks and / or migration conditions in the graphical user interface by dragging and dropping;

[0108] Add connectors to define the execution order or data flow between function blocks, between function blocks and migration conditions, or between migration conditions.

[0109] Among them, the graphical user interface is a type of human-computer interface (HMI).

[0110] For functional components in the graphical user interface, this includes user-defined components generated using high-level languages ​​such as Python, enabling users to define complex business rules. It may also include functional components (FB / FU, function blocks / functional units) provided by the IEC 61131 library or integrated C / C++ library interfaces. Users can also add check methods and conditions for functional blocks.

[0111] In some embodiments, generating the corresponding process formula file includes:

[0112] The visualized process logic is converted into a process recipe file described by a multi-layered structure, which includes a variable definition layer, a step execution layer, a process transition layer, and a process orchestration layer; wherein...

[0113] The variable definition layer is used to define the variables that need to be used in the process. The variables are generated based on the variables configured by the user in the function block and / or migration conditions.

[0114] The step execution layer is used to define each of the functional blocks in the process, and each functional block includes one or more control actions;

[0115] The process jump layer is used to define the transfer logic between steps in the process. The transfer logic originates from the jump conditions set by the user in the migration conditions.

[0116] The process orchestration layer is used to define the process formed by the various steps, which is determined based on the execution order or data flow established by the user in the graphical user interface through connection lines.

[0117] The step execution layer further includes a monitoring and inspection module, which includes abnormal conditions and handling steps. This module performs unified monitoring and inspection of the execution status of all steps. The data being inspected can be metadata parameters defined in the step execution layer.

[0118] The execution modes of the steps in the step execution layer may include timed execution, steady-state control, conditional interruption, etc.

[0119] The step execution layer or the process jump layer embeds Python expressions, which are used for real-time parameter calculation or runtime condition judgment. The Python expression is an expression that can calculate a parameter (such as a target value, threshold, execution time, jump condition, etc.) in real time based on real-time data (such as sensor readings, historical data, time, external commands, etc.).

[0120] In this process flow transition layer, the jump conditions are implemented through flow control labels and the `goto` statement. Specifically, a flow control label is placed at a specific location within the flow, providing a unique, referential name for that location. When the `goto` statement is executed, the program's execution flow immediately jumps to the location marked by the associated label and continues execution from there.

[0121] Furthermore, jump conditions can also be implemented using conditional expressions. Specifically, conditional expressions define the action to be performed when a condition is met, such as jumping to a specific location in the flow.

[0122] The execution order of the steps in the process orchestration layer includes the number of loops, i.e., how many times the execution order needs to be executed. The branch structure includes a parent (execution order). For example, if deposition_cycle is the parent of gas_injection, then gas_injection needs to be executed whenever deposition_cycle is executed. gas_injection is executed once each time (number of loops), including the steps gas_step1 and gas_step2.

[0123] The variable includes at least one of the following: variable name, variable type, variable scope, and / or initial value.

[0124] The definition of a function block includes at least one of the following: function block name, function block execution mode, and function block calling method; a function block can directly reference a function block encapsulated from program symbol information exported from the PLC IDE, which includes one or more control actions.

[0125] The jump conditions include at least one of the following: jump conditions, target jump location.

[0126] The process includes at least one of the following: the execution order of steps and / or a branching structure. A step can be one or more functional blocks, each functional block being an atomic step, and a sub-process formed by multiple functional blocks can be an orchestrated step.

[0127] In some embodiments, the generated process recipe file can be described using languages ​​such as JSON and YAML.

[0128] In some embodiments, generating program code based on the process recipe file and compiling it into machine code includes:

[0129] Generate program code for each layer based on the process formula file described in the multi-layer structure;

[0130] The program code for each corresponding layer is compiled into machine code encapsulated in the form of multiple dynamic libraries for each corresponding layer.

[0131] Specifically, the program code corresponding to the variable definition layer, step execution layer, process jump layer, and process orchestration layer is compiled into vars dynamic library, steps dynamic library, transitions dynamic library, and flows dynamic library, respectively.

[0132] The dynamic library can be compiled as needed; when the program code of a certain layer changes, only the program code of that layer needs to be compiled. For example, for process A, when only the sequence of process steps is adjusted, this modification only affects the program code of the process orchestration layer. Therefore, only the program code of the process orchestration layer needs to be recompiled to generate the flow dynamic library, thus saving compilation time.

[0133] In some embodiments, generating program code based on the process recipe file may include: extracting data from each layer of the process recipe file to generate general structured data, then obtaining a target PLC template, and filling the structured data into the corresponding position of the target PLC template to generate target program code.

[0134] The generation of general structured data includes at least one of the following:

[0135] The data of variables in the variable definition layer of the process formula document are used to generate structured data of variable objects. The attributes of the variable objects include at least one of the following: variable name, type, scope, or initial value.

[0136] The data of the functional blocks in the step execution layer of the process formula file are used to generate structured data of step objects. The attributes of the step objects include at least one of the following: step name, mode, calling method, or input / output parameters.

[0137] The transfer logic data in the process jump layer of the process formula file is used to generate structured data of jump objects. The attributes of the jump objects include at least one of the following: source step, jump condition, or target location.

[0138] The process data in the process arrangement layer of the process recipe document is used to generate structured data of process objects. The attributes of the process objects include at least one of the following: a list of step objects and their execution order, or branching relationships.

[0139] Specifically, based on the format used in the process formula document, the corresponding parsing engine, such as YAML / JSON / XML, is used to convert the specific data into in-memory data structures, such as dictionaries and lists, forming the aforementioned general structured data.

[0140] The parsing engine's functions may include: extracting variables from the variable definition layer of the process recipe file and generating variable declarations (i.e., variable objects); parsing the steps in the step execution layer of the process recipe file and generating the control logic of the step objects, i.e., how the steps specifically control the instances (such as the control of the heater in the heating stage); and also parsing the process-related transfer logic data and process data in the process jump layer and process orchestration layer of the process recipe file to generate the process structure, including jump objects and process objects.

[0141] The process of obtaining the target PLC template includes: determining the function corresponding to the process logic; obtaining the target PLC model; matching the target PLC template according to the target PLC model and the function corresponding to the process logic; the target PLC template includes multiple template files, each template file corresponding to different functional modules of the PLC code, and the functional modules include variable declaration modules, method call modules, and process control modules.

[0142] The template file may contain specific syntax, function calls, data type declarations, etc., required by the target PLC platform. A template engine can use the template and structured data to generate code with specific syntax and specifications for the target PLC. The template engine can use Jinja2 (Python), Freemarker (Java), Velocity, etc., to "populate" the general structured data parsed by the parsing engine into the corresponding positions of the target PLC template, generating the target program code used by the target PLC.

[0143] The filling process involves setting dynamic placeholders within the fixed structure of the template file; that is, the template engine replaces the corresponding dynamic placeholders with the structured data. Finally, a complete PLC source code file is output.

[0144] In some embodiments, loading the compiled machine code into the PLC Runtime environment for execution includes: loading the plurality of dynamic libraries into the PLC Runtime environment. The dynamic libraries support a plug-and-play framework, meaning that when a task requires them, one or more of the required dynamic libraries are loaded into the PLC Runtime environment in real time for execution.

[0145] In some embodiments, the real-time system executes a process formulation task comprised of the machine code (dynamic library). This task calls standard library symbol information, namely functions in the C standard library and the IEC 61131 library, through a dynamic linking mechanism, and accesses local and administrative variables of the process formulation through shared memory. Modifications to these variables during task execution are written back to the shared memory in real time. The shared memory provides these modification results to the non-real-time system for monitoring, recording, and display throughout the entire lifecycle.

[0146] The second embodiment of this application provides a PLC development method for implementing low-level PLC code programming. The following will be combined with... Figure 2a The architectural diagram shown is used for illustration.

[0147] The PLC code development system of this application includes: PLC IDE, which is used to export PLC program symbol information containing I / O variables, tasks or function methods (FB);

[0148] The UI process low-code programming environment is used to receive the PLC program symbol information and provide a graphical user interface, i.e., a human-machine interface (HMI), based on the PLC program symbol information. This allows users to directly reference the I / O variables, tasks, or functional methods during the visualization and arrangement of process logic to construct process logic and generate corresponding process recipe files.

[0149] The PLC controller is used to generate program code based on the process recipe file and compile it into machine code; and to load the machine code into the PLC runtime environment for execution.

[0150] Among them, such as Figure 2a As shown, the PLC IDE will export PLC program symbol information containing I / O variables, tasks, and function methods (FB) as plc_var.csv.

[0151] The I / O variables, tasks, or functional methods in the exported PLC program symbol information can be encapsulated as functional components and provided to the graphical user interface so that users can directly call the functional components to reference the corresponding I / O variables, tasks, or functional methods during the visualization and arrangement of process logic.

[0152] The I / O variables, tasks, or function methods in the exported PLC program symbol information can also be used as referenced variable table information in the construction of custom function blocks in the UI process low-code programming environment to ensure that the custom function blocks can correctly use the I / O variables, tasks, or function methods of the PLC program.

[0153] Among them, such as Figure 2b As shown, the UI technology low-code programming environment allows users to drag and drop custom function blocks or FB-encapsulated function blocks, such as functions A, B, C, D, E, F, and G, as well as migration conditions 1, 2, and 3.

[0154] This allows for the configuration of function blocks and migration conditions, such as process function B in... Figure 2b As shown in the functional definition, it can have multiple attributes, operations, and other parameters. The operations can be FB / FU provided by the IEC 61131 library, or integrated C / C++ program library interfaces; such as migration condition 1 in... Figure 2b As shown in the condition definition, a migration condition can have multiple conditions and actions. For example, one of the conditions in migration condition 1 is defined as stopping the function operation when vars_plc.temperature>120 and vars_cust.power>100. Users can also add check methods and conditions for the function block.

[0155] Users can view process execution steps, results, process variables, PLC variables, etc. in real time within the UI process low-code programming environment.

[0156] like Figure 2a and 2bAs shown, users can convert process logic into process recipe files described in a multi-layered structure, in JSON format, and support downloading them to the non-real-time system of the PLC controller.

[0157] The PLC controller runs two heterogeneous systems using virtualization technology: one is a non-real-time general-purpose OS (which can be Windows or Linux, e.g.) Figure 2a The embodiment shown in this application uses a Linux system as a non-real-time system. The other is an RTOS system running a PLC running environment. Efficient communication between Linux and the PLC running environment is achieved through shared memory.

[0158] After the process recipe file is downloaded to the Linux system, it is converted into C / C++ code by the process recipe code generation engine, as well as the conversion of the Python expressions contained therein to C / C++. Then, by linking the multi-level structure (such as vars, steps, transitions, and flows) in the process recipe file to the C library symbol table and the IEC 61131 library symbol table, it is compiled into multiple corresponding dynamic libraries (i.e., machine code encapsulated in the form of dynamic libraries).

[0159] Through the plug-and-play framework, the PLC RUNTIME environment loads machine code into the real-time system environment, runs the machine code according to the needs and scheduling of real-time tasks, and calls the C library, IEC 61131 library, and relevant variable data in shared memory.

[0160] The third embodiment of this application provides a PLC development method for implementing low-level PLC code programming. The specific implementation of the process recipe file generation and visualization arrangement method will be described below with reference to... Figure 3a The flowchart shown illustrates that the method provided in this second embodiment includes the following steps S300-S340.

[0161] S300: Implements both heating and cooling FB methods in PLC IDE.

[0162] First, configure it in the PLC IDE, such as... Figure 3b As shown, two function blocks were developed using the IEC 61131 standard language: heating (Heating in the figure, to distinguish it from the heating process function block in step S330, the function block developed here using the IEC 61131 standard language, hereinafter referred to as FB_Heating) and cooling (Cooling in the figure, similar to the heating function block, hereinafter referred to as FB_Cooling).

[0163] S310: Export structured symbol information files for both heating and cooling FB methods from the PLC IDE and import them into the UI process low-code programming environment.

[0164] In some embodiments, PLC program symbol information containing I / O variables, tasks, and function methods can be exported from the PLC IDE.

[0165] Specifically, in this embodiment of the application, plc_api.json (a list of function blocks and their interface definitions) and plc_var.json (a list of global variables) are exported from the PLC IDE and imported into the UI process low-code programming environment.

[0166] In the traditional, standard PLC development process, the PLC IDE will generate a single executable file and download it to the real-time system of the PLC controller to run the process logic and the task configuration containing one or more process logics.

[0167] The embodiments of this application allow creating a new periodic task in the task configuration interface of the PLC IDE, including key attributes such as execution cycle and priority. Figure 3c As shown, the cycle time for executing a process task is set to 10ms. Within this cycle time, one or more process logic operations can be executed.

[0168] Since the programming design and download of the process logic are completed by the UI process low-code programming environment, the task configuration of the PLC IDE needs to be downloaded separately to the Linux system of the PLC controller as the task configuration (e.g. Figure 2a The recipe scheduling is loaded and used to schedule the process recipe file.

[0169] S320: Programming design in a UI technology low-code programming environment.

[0170] In some embodiments, the process logic visualized and arranged by the user through a UI process low-code programming environment is obtained, and the PLC program symbol information is received, so as to support the direct reference of the I / O variables, tasks and function methods in the visual arrangement, and the generation of process recipe files based on the process logic arranged by the user.

[0171] like Figure 3d As shown, this embodiment of the application creates a process logic that performs the heating-cooling step 1000 times in a loop and obtains a process recipe file (JSON format).

[0172] Specifically, the process logic includes two functional blocks: heating process and cooling process, as well as a migration condition 1.

[0173] The heating process function block and the cooling process function block respectively reference the two FB methods, namely FB_Heating and FB_Cooling, which are defined in the PLC IDE in step S300 and exported and encapsulated in step S310.

[0174] Taking the heating process function block as an example, this function block includes three inputs: target temperature, holding time, and step execution timeout; these can be set in the user interface.

[0175] Based on the input and the program symbol information encapsulated in FB_Heating (including the real-time temperature value acquired by the system), a process logic check is performed, including: checking whether the real-time temperature value (current_temp) is within the target temperature range; if so, further checking whether the time within the target temperature range (in_target_duration, from the system's internal counter) is greater than or equal to the holding time. If the condition is met, True is returned, meaning that the heating process is complete.

[0176] The cooling process is then carried out. The setting method and logic of the cooling process function block are similar and will not be repeated here.

[0177] After the heating and cooling processes are completed, the loop count is performed using migration condition 1. When the loop count is less than or equal to 1000, the process returns to the label position at the beginning of the process and restarts the heating and cooling cycle.

[0178] As described above, by dragging and connecting the above heating and cooling process function blocks and migration condition 1 in the graphical user interface, the process logic is arranged and the process formula file is obtained.

[0179] S330: Download it to the PLC system and execute it.

[0180] The aforementioned process recipe file is transferred to the Linux system of the PLC controller. The process recipe code generation engine in the non-real-time system reads the file and converts it into intermediate code such as C / C++.

[0181] Using the cross-compilation toolchain of the RTOS, the intermediate code is linked with C standard library symbols and IEC 61131 library symbols to compile and generate multiple corresponding dynamic libraries (such as the control flow library flow.so and the function step library steps.so).

[0182] The plug-and-play framework loads the compiled dynamic library into the PLC runtime environment of the real-time system (RTOS) via shared memory.

[0183] Finally, the PLC RUNTIME environment executes the loaded recipe logic according to the periodic task scheduler configured in the S320. During task execution, machine code in the dynamic library is called to drive low-level function blocks such as FB_Heating, thereby controlling the physical devices. Real-time variables can also be fed back to the non-real-time system for monitoring via shared memory.

[0184] To better understand the process by which a PLC controller generates program code from a multi-layered process recipe file, an example is provided below. In this example, the user first uses the graphical user interface provided by the UI process low-code programming environment to visually arrange the process logic through drag-and-drop, connection lines, and necessary input configurations. The UI process low-code programming environment then generates a process recipe file based on the user-arranged process logic and sends it to the PLC controller to generate program code. Some information recorded in each layer of the process recipe file in this example is listed below:

[0185] 1) Variable definition layer (var)

[0186] The following code is an example of variable data. The process formula file in this application embodiment is defined in YAML format:

[0187]

[0188] These include both PLC variables and local variables. Variable data can include the variable name (var_name), variable type (var_type), and initial value (var_init). For example, in the code above, the local variable target temperature (target_temp) is of floating-point type and its initial value is set to 80.0.

[0189] The dual-variable system design using PLC variables and local variables can effectively separate the two variable types, making it easier to adjust for different PLC templates and also easier to maintain.

[0190] 2) Step execution layer

[0191] The following code is an example of a function block (step):

[0192]

[0193] The steps include a step name (step_name) and a step execution mode (mode). For example, in the code above, the heating phase (heating_phase) uses a stable mode. The steps also include the methods called during the steps. For instance, the code above provides a PID heater control method using the heater instance heater1. The step execution mode in this embodiment supports parallel control of multiple devices and uses two modules, input and output, to achieve bidirectional data binding for each instance.

[0194] The method call described above requires the target temperature (target) and maximum power (max_power) as input. The target temperature is obtained by retrieving the target temperature (target_temp) from the local variable (vars_local) set in the variable definition layer. The maximum power is dynamically calculated using a Python expression, which is obtained by multiplying the heating factor (heat_factor) in the local variable (vars_local) by 1000. The method outputs an actual temperature (actual_temp) and stores it as the temperature value (temperature) in the PLC variable (vars_plc).

[0195] The above steps also include some metadata such as stable_var, stable_up, stable_down, stable_time, etc., which can be used for unified inspection in the monitoring and inspection module.

[0196] The following code is an example of another function block (step):

[0197]

[0198] The code above defines another execution mode for the heating phase step, the time mode, and the corresponding metadata, process_time.

[0199] At the end of the step execution layer, there is also a monitoring and checking module (run_check), as follows:

[0200]

[0201] The aforementioned monitoring and inspection module uses a monitoring condition to handle abnormalities in the execution of steps. Specifically, when the temperature value in the PLC variable (vars_plc) is greater than 150, an emergency stop is initiated.

[0202] 3) Flow transition layer and flow orchestration layer

[0203] In the process recipe file of this application embodiment, the process transition layer and process orchestration layer are implemented in the flows module. The following is a sample code snippet:

[0204]

[0205] The code above defines two processes: a deposition cycle and a gas injection cycle. The deposition cycle runs three times, consisting of two steps: a heating phase and gas injection. Its parent is the main process (flow_main). The gas injection cycle runs once, consisting of two steps (gas_step1 and gas_step2), and its parent is the deposition cycle. That is, when the deposition cycle is executed, a gas injection is performed once.

[0206] The code above adds a jump label (restart_point) to the main flow (flow_main) using label_name. The jump logic for temperature check (temp_check) is also the parent of the main flow. When the temperature value (temperature) in the PLC variable (vars_plc) is reached, the goto statement will jump to the jump label position to continue.

[0207] The nested loop structure designed using parent / time, etc., can be used to achieve complex process cycle control, such as deposition-annealing cycle.

[0208] The following describes in detail the process by which a PLC controller generates program code based on a process recipe file, including the following steps:

[0209] 1) The PLC controller generates structured data based on the process recipe document.

[0210] PLC controllers can use a parsing engine to extract specific data (such as variable names, step parameters, jump conditions, etc.) from process recipe files and convert them into structured data (such as dictionaries and lists) that can be recognized by templates from various manufacturers.

[0211] The embodiments of this application can use a YAML parsing engine, such as the PyYAML library in Python, to extract structured data.

[0212] For example, the entire YAML file will be parsed into a dictionary. The keys of the dictionary include vas_plc, vars_local, steps, flows, transitions, etc. Each key stores the data, expressions, or structures defined in the process recipe file in a structure corresponding to the process recipe file.

[0213] 2) Fill the structured data into the corresponding position of the target PLC template to generate the target program code.

[0214] This application embodiment uses the Jinja2 template engine to generate target program code based on a predefined PLC template. The PLC template is divided according to functional modules, such as variable declaration module, step function module, and process control module. Variables in the variable declaration module are generated by extracting variable data from the variable definition layer in the process recipe file; the function block data in the step execution layer is parsed to generate control actions for instance control in the step function block; and the transfer logic data and execution order or data flow of the process jump layer and process orchestration layer are analyzed to generate the process structure required by the process control module.

[0215] The structured data obtained in the previous step is input into the Jinja2 template engine to generate PLC code. Specifically, first, a predefined PLC template is selected, and the target PLC template is matched according to the target PLC model and the corresponding function of the process logic. For example, if the target PLC model is XXXS7-1500, a pre-written Jinja2 template file containing the target PLC-specific syntax and placeholders is selected. Variable parts such as variable names and parameters are replaced with placeholders {{}}.

[0216] The dictionary obtained in the previous step is passed as context to the Jinja2 engine. This allows placeholders in the template to access and extract the corresponding data, which is then used to generate the variable declaration code, control logic code, and main program framework flow control code for the target Jinja2 template. After merging the variable declarations, control actions, and flow structure code snippets, a complete target program code is formed.

[0217] The fourth embodiment of this application provides a PLC controller that runs a non-real-time system and a real-time system. The non-real-time system and the real-time system exchange data through shared memory, which can be used to implement the PLC code development method in the above embodiments, such as... Figure 4 As shown, the PLC controller includes:

[0218] The non-real-time system runs a code generation engine, which generates program code based on the received process recipe file and compiles it into machine code.

[0219] The real-time system runs a PLC RUNTIME environment, which is used to obtain the machine code through the shared memory and load the machine code into the PLC RUNTIME environment for execution.

[0220] In some embodiments, the code generation engine is specifically used to generate program code for each layer of a process recipe file describing a multi-layer structure, and to compile the program code for each layer into machine code encapsulated in the form of multiple dynamic libraries for each layer.

[0221] In some embodiments, the non-real-time system is also used to obtain machine code-related runtime information loaded into the PLCRUNTIME environment of the real-time system via shared memory, so as to provide it to the UI process low-code programming environment and display it to the user.

[0222] Figure 5 This is a schematic structural diagram of a computing device 900 provided in an embodiment of this application. This computing device can execute various optional embodiments of the methods described above. The computing device can be a terminal, or a chip or chip system within the terminal. Figure 5 As shown, the computing device 900 includes: a processor 910, a memory 920, and a communication interface 930.

[0223] It should be understood that Figure 5 The communication interface 930 in the computing device 900 shown can be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0224] The processor 910 can be connected to the memory 920. The memory 920 can be used to store the program code and data. Therefore, the memory 920 can be a storage unit inside the processor 910, an external storage unit independent of the processor 910, or a component that includes both the storage unit inside the processor 910 and the external storage unit independent of the processor 910.

[0225] Optionally, the computing device 900 may also include a bus. The memory 920 and communication interface 930 can be connected to the processor 910 via the bus. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The symbol is represented by a line without an arrow, but this does not mean that there is only one bus or one type of bus.

[0226] It should be understood that in the embodiments of this application, the processor 910 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 910 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0227] The memory 920 may include read-only memory and random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include non-volatile random access memory. For example, the processor 910 may also store device type information.

[0228] When the computing device 900 is running, the processor 910 executes computer execution instructions stored in the memory 920 to perform any of the operational steps of the above method and any of the optional embodiments thereof.

[0229] It should be understood that the computing device 900 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the above and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0230] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0231] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0232] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0233] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0234] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0235] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0236] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the above-described method, which includes at least one of the schemes described in the above embodiments.

[0237] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0238] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0239] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0240] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0241] Furthermore, the terms "first, second, third, etc." or similar terms such as module A, module B, and module C used in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that, where permissible, a specific order or sequence may be interchanged so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0242] In the above description, the labels of the steps involved, such as S110, S120, etc., do not mean that the steps will necessarily be executed. The order of the steps can be interchanged or executed simultaneously if permitted.

[0243] The term "comprising" as used in the specification and claims should not be construed as limiting itself to what follows; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the mentioned feature, integral, step, or component, but does not exclude the presence or addition of one or more other features, integrals, steps, or components, or groups thereof. Thus, the statement "device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0244] The terms "an embodiment" or "an embodiment" as used in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of this application. Therefore, the terms "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in one or more embodiments, the particular features, structures, or characteristics can be combined in any suitable manner, as will be apparent to those skilled in the art from this disclosure.

[0245] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, all of which fall within the scope of protection of this application.

Claims

1. A PLC development system for implementing low-code programming, characterized in that, include: PLC IDE is used to export PLC program symbol information containing I / O variables, tasks, or function methods; The UI process low-code programming environment is used to receive the PLC program symbol information and provide a graphical user interface based on the PLC program symbol information, so that users can directly reference the I / O variables, tasks or function methods during the process of visually arranging the process logic to construct the process logic and generate the corresponding process recipe file. The PLC controller is used to generate program code based on the process recipe file and compile it into machine code. And load the machine code into the PLC RUNTIME environment for execution.

2. The system according to claim 1, characterized in that, The PLC controller runs a non-real-time system and a real-time system, and the non-real-time system and the real-time system exchange data including the machine code through shared memory; The non-real-time system runs a code generation engine, which generates program code based on the process recipe file and compiles it into machine code. The real-time system runs the PLC RUNTIME environment, which is used to load the machine code into the PLC RUNTIME environment for execution.

3. The system according to claim 2, characterized in that, The non-real-time system also includes standard library symbol information. During compilation, the code generation engine links the standard library symbol information to complete the compilation of the program code.

4. The system according to claim 2, characterized in that, The provision allowing users to directly reference the I / O variables, tasks, or functional methods during the visualization and orchestration of process logic includes: The I / O variables, tasks, or functional methods in the PLC program symbol information are encapsulated as functional components and provided to the graphical user interface so that users can directly call the functional components to reference the corresponding I / O variables, tasks, or functional methods during the visualization and arrangement of process logic.

5. The system according to claim 4, characterized in that, The functional components include functional blocks and migration conditions, and support user customization in the graphical user interface; The custom configuration includes setting the variables referenced by the function block, the actions to be performed, and / or the jump logic on which the migration conditions are based.

6. The system according to claim 5, characterized in that, The visual arrangement includes at least one of the following operation methods: Configure variables in function blocks and / or migration conditions; Arrange function blocks and / or migration conditions in the graphical user interface by dragging and dropping; Add connectors to define the execution order or data flow between function blocks, between function blocks and migration conditions, or between migration conditions.

7. The system according to claim 6, characterized in that, The generation of the corresponding process formula file includes: The visualized process logic is converted into a process recipe file described by a multi-layered structure, which includes a variable definition layer, a step execution layer, a process transition layer, and a process orchestration layer; wherein... The variable definition layer is used to define the variables that need to be used in the process. The variables are generated based on the variables configured by the user in the function block and / or migration conditions. The step execution layer is used to define each of the functional blocks in the process, and each functional block includes one or more control actions; The process jump layer is used to define the transfer logic between steps in the process. The transfer logic originates from the jump conditions set by the user in the migration conditions. The process orchestration layer is used to define the process formed by the various steps, which is determined based on the execution order or data flow established by the user in the graphical user interface through connection lines.

8. The system according to claim 7, characterized in that, The step of generating program code based on the process formula file and compiling it into machine code includes: Generate program code for each layer based on the process formula file described in the multi-layer structure; The program code for each corresponding layer is compiled into machine code encapsulated in the form of multiple dynamic libraries for each corresponding layer.

9. A PLC controller, characterized in that, The system operates with both a non-real-time system and a real-time system, which exchange data via shared memory. The non-real-time system runs a code generation engine, which generates program code based on the received process recipe file and compiles it into machine code. The real-time system runs a PLC RUNTIME environment, which is used to obtain the machine code through the shared memory and load the machine code into the PLC RUNTIME environment for execution.

10. The PLC controller according to claim 9, characterized in that, The code generation engine is specifically used to generate program code for each layer of a multi-layered process recipe file, and to compile the program code for each layer into machine code encapsulated in the form of multiple dynamic libraries for each layer.

11. A PLC development method for implementing low-code programming, characterized in that, include: Export PLC program symbol information containing I / O variables, tasks, or function methods from the PLC IDE; The system receives the PLC program symbol information through the UI process low-code programming environment and provides a graphical user interface based on the PLC program symbol information. This allows users to directly reference the I / O variables, tasks, or functional methods during the visualization and arrangement of process logic to construct process logic and generate corresponding process recipe files. The code generation engine running on the non-real-time system of the PLC controller generates program code based on the process recipe file and compiles it into machine code. The machine code is loaded into the PLC RUNTIME environment running in the real-time system on the PLC controller.

Images