Soft PLC programming debugging system

Abstract

The invention provides a soft PLC programming debugging system which comprises an application interaction foreground which is deployed on a user browser in a back-end separation mode and used for providing program editing, equipment debugging and visualization functions; the server-side background is connected with the application interaction foreground and comprises a compiling module used for translating the soft PLC program through a structured text and compiling the soft PLC program into a native code; the equipment control module is used for receiving an equipment debugging instruction from the application interaction foreground through the remote procedure call framework and issuing the equipment debugging instruction to the motion controller; and the state monitoring module is used for collecting operation data of the motion controller, feeding back the operation data to the application interaction foreground in real time through a streaming push protocol, monitoring a communication connection state through a detection and reconnection mechanism, and triggering reconnection when the communication connection state is abnormal. The technical problems that an existing single desktop architecture is inconvenient in cross-platform deployment and maintenance, low in interpretive execution scheme performance, high in single-axis debugging communication delay and insufficient in remote state monitoring real-time performance and reliability are solved.

Description

Technical Field

[0001] This invention relates to the technical field of programming and debugging software, and more particularly to a soft PLC programming and debugging system. Background Technology

[0002] As industrial automation transforms towards flexibility and intelligence, soft PLC technology, as a solution breaking free from the constraints of traditional hardware PLCs, has been widely applied in scenarios such as production line control, robot maintenance, and smart factory construction. Its core is to implement PLC control logic in software on a general-purpose computing platform, offering advantages such as openness and scalability. It must also comply with the IEC61131-3 standard and support multiple programming languages, including ladder diagrams and structured text (ST). Currently, several soft PLC products exist internationally, and domestic research and development is also underway based on embedded architectures or cross-platform concepts, aiming to meet the core needs of program editing, equipment control, and data monitoring in industrial scenarios.

[0003] However, existing soft PLC technology still has many shortcomings that urgently need to be addressed: First, at the architecture level, it mostly adopts a monolithic desktop deployment mode, which is deeply bound to a specific operating system, requiring cumbersome local installation and configuration, resulting in poor cross-platform compatibility and high maintenance costs for large-scale deployment; Second, program execution mostly adopts an interpreted running mode, executing intermediate instructions through a virtual machine, which has performance bottlenecks such as low running efficiency and high resource consumption, making it difficult to meet the stringent real-time requirements of industrial scenarios; Third, single-axis debugging relies on a custom TCP / IP protocol, which has high overhead in protocol parsing and data processing, and significant delays in remote control command response, affecting control accuracy; Fourth, remote status monitoring adopts an inefficient polling mode, which has problems such as high data latency, easy loss of brief signal changes, and lack of a reliable connection status management mechanism, which can easily lead to "false online" when the network is interrupted, misleading operators.

[0004] These technical shortcomings directly restrict the application of soft PLCs in high-end manufacturing, making it difficult for existing products to meet user needs in terms of real-time response speed, cross-platform deployment flexibility, and remote control reliability. With the increasing demands of the Industrial Internet for IT / OT convergence, enterprises urgently need a soft PLC programming and debugging system with cross-platform deployment capabilities, high-performance compilation and execution efficiency, low-latency communication links, and highly reliable monitoring mechanisms to address the pain points of existing technologies and support the digital and flexible upgrading of industrial production. Summary of the Invention

[0005] The purpose of this invention is to provide a software PLC programming and debugging system that solves the technical problems of existing software PLC technology, such as inconvenient cross-platform deployment and maintenance of single-desktop architecture, low performance of interpretive execution schemes, high communication latency in single-axis debugging, and insufficient real-time performance and reliability of remote status monitoring.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: This invention provides a soft PLC programming and debugging system, comprising: The application's interactive front-end is built on Web technology and deployed in a back-end-separated manner on the user's browser. It provides functions such as soft PLC program editing, remote device access, parameter configuration, and visualization of device motion status. The soft PLC program editing includes ladder diagram drawing. The server-side backend, which communicates with the application's frontend, adopts a modular design and includes: The compilation module is used to translate and compile user-edited, standards-compliant soft PLC programs into executable native code for the target platform via structured text ST. The device control module is used to receive device debugging instructions from the application interaction front end through a remote procedure call framework and send them to the motion controller; The status monitoring module is used to collect the operating data of the motion controller, feed it back to the application interaction front end in real time through a streaming push protocol, and monitor the communication connection status through a detection and reconnection mechanism and trigger reconnection when abnormal.

[0007] Furthermore, the trapezoidal graph drawing includes primitive snapping and primitive rendering. Primitive snapping calculates the Euclidean distance between the cursor coordinates and the primitive feature points, and triggers automatic alignment when the distance is less than a preset snapping threshold. Primitive rendering is based on the scene graph architecture of the Konva framework, which encapsulates geometric lines and text labels into a unified entity and dynamically maps them to the Canvas view.

[0008] Furthermore, the ladder diagram drawing also includes primitive drawing and primitive transformation, wherein: each primitive object has an input port and an output port, and the port maintains a dynamic connection array, which is used to record the reference relationship between primitives when the user establishes a connection, thereby transforming the ladder diagram logic into a directed graph structure that can be parsed by the server backend.

[0009] Furthermore, the compilation module executes a compiled execution scheme, the workflow of which includes: Translate the ladder diagram program into an ST program; The ST program is subjected to syntax analysis to generate an abstract syntax tree. A domain model is constructed based on the abstract syntax tree, and semantic analysis is performed on the domain model. Generate functionally equivalent C++ source code based on the aforementioned domain model; The C++ source code is compiled into a native dynamic link library.

[0010] Furthermore, the translation of the ladder diagram program into an ST program includes: The ladder diagram program is parsed into a directed graph structure with nodes and edges, where nodes represent ladder diagram primitives and edges are established based on the logical connection relationships between primitives; Traverse the directed graph structure according to the ladder diagram scanning order specified in the standard to generate the corresponding ST statement sequence.

[0011] Furthermore, the syntax analysis is implemented using the ANTLR4 tool, with lexical and syntactic rules written based on standards. Lexical rule identifiers begin with uppercase letters, and syntactic rule identifiers begin with lowercase letters. Nested syntax is described using direct left recursive rules. The semantic analysis includes strong type constraint verification, symbol uniqueness verification, and variable type matching verification. Implicit type conversion is prohibited, and variable names are ensured to be unique within the same scope, and variable assignments are consistent with data types.

[0012] Furthermore, the domain model is constructed based on standard program organization units, abstracting the ST statement base class. Assignment statements, IF statements, and FOR statements inherit from this base class as subclasses. The transformation from abstract syntax tree to domain model is achieved through a strategy combining the visitor pattern and the factory pattern.

[0013] Furthermore, the remote procedure call framework is the gRPC framework, based on the HTTP / 2 protocol and Protocol Buffers binary serialization protocol, which enables efficient communication, fast data processing and simplified control logic, and supports cross-language calls. The server backend and motion controller achieve low-latency transmission of control commands through this framework and protocol.

[0014] Furthermore, the device control module is used to receive control commands issued by the application interaction front end, and to issue the commands to the motion controller through a gRPC-based remote procedure call framework to perform single-axis debugging, axis group motion control and IO control; The axis group motion control supports the creation of multiple axis groups and provides various motion modes, including absolute position movement, relative position movement, circular interpolation, and continuous interpolation. Users can drive the axis group to run by configuring motion parameters and target positions or offsets for the axis group.

[0015] Furthermore, the streaming push protocol is the WebSocket protocol, and the detection and reconnection mechanism sends probe packets at intervals through the main heartbeat timer. After the response times out, the service confirmation timer is started, the probe packets are resent, and after several consecutive failed retries, the connection is determined to be abnormal and a disconnection reconnection is triggered.

[0016] Compared with the prior art, the present invention has at least the following beneficial effects: (1) Cross-platform deployment and maintenance are more convenient. This application adopts a web-based front-end and back-end separation architecture. Users can access the full functionality through a standard browser without local installation and configuration, thus getting rid of the dependence on a specific operating system. At the same time, software updates and maintenance are concentrated on the server side, which greatly reduces the cost and difficulty of large-scale applications and adapts to the modern multi-platform and lightweight development needs.

[0017] (2) The program's running performance and real-time performance are significantly improved. Through the compiled running scheme, the ladder diagram and other PLC programs are converted into C++ code and compiled into native dynamic link libraries, which completely avoids the performance overhead and resource occupation problems of virtual machine interpretation execution, so that the program runs with near-native code efficiency and meets the microsecond-level response requirements of multi-axis motion control scenarios such as industrial robots.

[0018] (3) The remote single-axis debugging accuracy is higher. With the help of the gRPC remote procedure call framework and Protocol Buffers binary serialization protocol, efficient cross-language communication is realized, which greatly reduces the transmission delay of single-axis debugging commands, allowing users to obtain a remote real-time control experience close to local operation, and improving debugging efficiency and control accuracy.

[0019] (4) Remote status monitoring is more real-time and reliable. Based on the WebSocket protocol, the device operation data is actively pushed in a streaming manner, avoiding the delay and data loss problems of the traditional polling mode. At the same time, through the disconnection reconnection mechanism combining the main heartbeat timer and the service confirmation timer, the network connection status can be sensed in real time and reconnection can be triggered quickly, effectively avoiding the "false online" situation and ensuring the high fidelity and high reliability of monitoring data in industrial sites. Attached Figure Description

[0020] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 The overall architecture design diagram of the soft PLC programming and debugging system provided for this implementation; Figure 2 The program diagram for the primitive drawing and primitive transformation functions provided in this implementation; Figure 3 A flowchart of the software PLC compiler provided for this implementation; Figure 4 Ladder diagram provided for this implementation; Figure 5The directed graph provided for this implementation, parsed by the server backend; Figure 6 The execution order diagram of each element in the ladder diagram sample program provided for this implementation, based on traversal logic; Figure 7 The direct left recursive rule description nested syntax graph provided for this implementation; Figure 8 The gRPC framework schematic provided for this implementation; Figure 9 The heartbeat detection flowchart provided for this implementation; Figure 10 The interface diagram of the PLC programming and debugging software system provided for this implementation; Figure 11 The full-process management project diagram of the header file drop-down menu provided for this implementation; Figure 12 The pre-edited ladder diagram program provided for this implementation; Figure 13 This implementation provides a drop-down menu for clicking "Run" on a pre-edited ladder diagram program; Figure 14 The functional test drop-down menu diagram in the left-hand project tree provided for this implementation; Figure 15 The single-axis debugging parameter setting diagram provided for this implementation; Figures 16a-16b The shaft group creation operation diagram provided for this implementation (including) Figure 16a Enter axis number, Figure 16b Create axis group); Figure 17 The speed curve parameter setting operation diagram provided for this implementation; Figures 18a-18c The parameter setting diagram for selecting instructions based on requirements provided for this implementation (including...) Figure 18a Absolute / relative constant length motion commands Figure 18b Circular interpolation (absolute / relative) commands Figure 18c (Continuous interpolation I / O output instructions) Figure 19 The IO control interface provided for functional testing in this implementation; Figure 20 The IO monitoring interface for the device used in the functional testing provided for this implementation; Figure 21 The monitoring interface for all plug-in I / O pins on the corresponding coupler provided for this implementation; Figure 22 The status monitoring interface for each axis provided in this implementation; Figure 23 The speed-time relationship curves for each axis in the axis status monitoring provided for this implementation; Figure 24 The position-time relationship curves of each axis in the axis status monitoring provided for this implementation. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] This invention provides a soft PLC programming and debugging system. The system adopts a B / S architecture, consisting of an "application interaction front-end" developed using Web technology and accessed via a browser, and a "server back-end" with a modular design. The front-end handles human-computer interaction functions such as ladder diagram program editing, remote device access, and status visualization. The back-end contains three core modules: 1) A compilation module: responsible for translating user-written PLC programs (such as ladder diagrams) conforming to the IEC 61131-3 standard into structured text (ST), then compiling them into a native dynamic link library (DLL) that can run efficiently on the target motion controller through syntax analysis, semantic analysis, and code generation, unlike the interpreted virtual machine solution; 2) A device control module: acting as an instruction channel, receiving debugging commands from the front-end and efficiently and with low latency sending them to the underlying motion controller via a Remote Procedure Call (RPC) framework to execute single-axis, axis group, and IO control; 3) A status monitoring module: acting as a data channel, actively collecting real-time operating data from the motion controller and continuously pushing it to the front-end for visualization via a full-duplex streaming push protocol, while also incorporating a heartbeat detection and disconnection reconnection mechanism to maintain the reliability of the communication link.

[0024] This solution systematically integrates four core improvements: web-based cross-platform development, compiled high-performance execution, high real-time command control, and high-reliability status monitoring. It addresses the difficulties in deployment and maintenance, and poor cross-platform compatibility of traditional desktop software through a front-end / back-end separated web architecture; it completely avoids the performance bottlenecks and resource consumption issues of interpreted virtual machines by using a compilation-to-native-code execution scheme, meeting the microsecond-level real-time requirements of scenarios such as industrial robots; it optimizes the transmission latency of control commands through a dedicated RPC framework; and it solves the problems of high data latency and unpredictable network interruptions inherent in traditional polling monitoring through streaming push and keep-alive mechanisms.

[0025] Furthermore, regarding the steps of "translating the ladder diagram program into an ST program": the visual elements and connections of the ladder diagram are parsed into a directed graph data model consisting of nodes and edges, where nodes represent primitives and edges represent (directed) connections.

[0026] Specifically, this soft PLC programming and debugging system is implemented through the following core technical solutions, which include: 1. System architecture design, 2. Ladder diagram drawing function, 3. PLC program compilation and execution scheme, 4. Equipment control and status monitoring, and 5. Specific implementation methods, as follows: 1. System Architecture Design Against the backdrop of the current trend in digital and intelligent manufacturing towards scalable, modular, and service-oriented industrial manufacturing systems, traditional local monolithic soft PLC programming and debugging systems have gradually exposed numerous problems during development, deployment, and subsequent maintenance. These problems include high deployment costs, high coupling between functional modules making expansion difficult, and complex IT management processes. There is an urgent need to transform towards lower-cost, loosely coupled, and highly compatible industrial manufacturing systems to overcome the high costs of daily operations and the high performance requirements of local computers. Web-based software application development offers a solution to these problems. This invention designs an overall architecture for a web-based soft PLC programming and debugging system, such as... Figure 1 As shown, the entire software system is divided into an application interaction front-end and a server back-end.

[0027] (1) Application interaction front end The application interaction front-end primarily provides users with functions such as PLC program editing (ladder diagrams), remote equipment access and testing, parameter configuration, and visualization of equipment motion status information. The front-end is designed and implemented using mainstream web development technologies, employing a browser as the client for user interaction and real-time digital monitoring. It utilizes computer network technology to request services from the system server, compile and run the written PLC program, and remotely control multi-axis machines, acquiring real-time operating data and generating visualized data displays. This web-based application interaction platform provides users with convenient interactive services, eliminating the complex processes and installation constraints of traditional local software deployment and addressing device compatibility issues. Users can access and use system functions through any terminal and operating system's browser, resolving the dependence of local software on local high-performance computers at the software deployment level, effectively reducing system hardware investment and maintenance costs.

[0028] (2) Server backend To achieve high cohesion and low coupling of functions, the server-side backend adopts a modular decomposition strategy based on business capabilities. For example, user information management and the storage and configuration of mechanical / motion parameters are classified as basic configuration services, while real-time acquisition, status monitoring, and digital presentation of equipment operation data are classified as real-time monitoring services. The server-side backend retrieves various production element information from the underlying devices, such as IO status, shaft group position and speed information, and equipment alarm status, and performs IO drive control, shaft group drive control, and PLC program flow processing on the devices. It also provides data services to the application interaction frontend of the software system and manages key data throughout the system, such as user permissions, motion parameters, and mechanical parameters. Furthermore, by introducing a unified fault monitoring and logging mechanism, the fault tolerance and fault recovery efficiency of the backend services are effectively improved.

[0029] 2. Ladder Diagram (LD) Drawing Function (1) Interactive drawing function: The interactive drawing function of trapezoidal diagram drawing mainly includes primitive capture and primitive rendering functions.

[0030] Primitive snapping technology aims to assist users in achieving precise drawing through an automatic alignment mechanism. When the cursor approaches a key geometric feature point of a primitive, the system automatically prompts and locks onto that position. In its implementation, this invention constructs a dedicated mouse interaction class (Mouse Class) and instantiates it during the initialization phase. The system uses the Web standard addEventListener() interface to register listeners, capturing mouse displacement signals in real time and mapping them to the instance's Moved method. During interaction, this method searches for all drawn primitives in the scene using a traversal algorithm, calculating the Euclidean distance between the current cursor coordinates (pos1) and the primitive feature point (pos2) in real time. Once this distance is less than the system's preset snapping threshold, the snapping is considered successful, and the system immediately corrects the mouse pattern and triggers visual feedback, thus achieving the interactive effect of the mouse automatically snapping to the target point.

[0031] For primitive rendering, this invention adopts the Scene Graph architecture and preserved-mode drawing mechanism provided by the Konva framework. The system abandons the imperative drawing of the underlying Canvas API and adopts an object-oriented approach. It constructs logical containers for primitives by instantiating the Konva.Group class, and uses the composition pattern to encapsulate basic graphic nodes such as geometric lines and text labels into unified entities with hierarchical relationships. This containerized encapsulation not only achieves modular aggregation of complex LD primitives but also supports unified coordinate transformation and event listening on an object-by-object basis. All primitive objects are ultimately drawn on independent Layer layers, and through the Konva framework's built-in rendering algorithm, dynamic mapping and real-time updates from the data model to the visual Canvas view are achieved.

[0032] (2) Functions for drawing and transforming primitives.

[0033] like Figure 2 As shown, this invention adopts an object-oriented design approach to design the drawing functions and transformation functions of various primitives. It defines two base classes: a primitive class and a primitive transformation class. Then, it defines two different primitive classes and primitive transformation classes to inherit from and extend the two base classes.

[0034] For primitive drawing objects, they can be divided into basic primitive classes and function block classes according to their uses. The basic primitive class includes primitives such as buses, lines, normally open / normally closed contacts, and coils, while the function block class includes primitives such as motion control function blocks, homing function blocks, and interpolation function blocks. The data structure of each sub-primitive class is defined in conjunction with the interactive drawing function, and function functions such as primitive rendering, primitive snapping, and inverse operations (undo, redo functions) are also defined for each sub-primitive class.

[0035] Specifically, the primitive drawing class mainly includes four types of attributes: first, identity attributes, including global ID (localId) and primitive type (type); second, geometric attributes, including coordinate position, size, etc.; third, business attributes, including variable name and primitive status; and fourth, interaction attributes, including whether it is selected and whether it is draggable.

[0036] However, fixed static attributes alone are insufficient to constitute an executable ladder diagram program; complete control logic relies on the ordered connection relationships between primitives. This invention designs a port-based reference list mechanism to store the topology. Each primitive object internally instantiates two port objects: an input (ConnectionPointIn) and an output (ConnectionPointOut). These ports not only define the coordinates of the connections but also maintain a dynamic connection array. When a user establishes a connection, not only is the line drawn, but the localId of the target primitive is also written into the connection array of the source primitive, forming a logical bidirectional index. This data organization method transforms the connection state into the underlying graph structure, enabling the server-side backend to parse the directed graph structure of the ladder diagram by traversing the port reference chain, laying the foundation for subsequent ladder diagram translation.

[0037] The specific primitive design, function block design, and dynamically generated function block or function block design are shown in Tables 1, 2, and 3 below: Table 1. Graphic Design

[0038] Table 2 Functional Block Design

[0039] Table 3 Design of Dynamically Generated Function Blocks

[0040] The primitive transformation class defines the create, delete, and update operations for primitives, including copy, move, and delete operations. For copy and move transformation operations, simply perform x and y coordinate addition and subtraction operations on the extracted contour key points of the primitive to obtain the new position or copy of the transformed primitive. The primitive deletion operation deletes the instance primitive object stored in the global primitive container array, and then calls the Konva's clear() function interface to complete the redrawing of the entire interface primitive.

[0041] 3. PLC program compilation and execution scheme To address the problems of low operating efficiency, high resource consumption, and high technical difficulty associated with interpretive PLC solutions, this invention adopts a compiled execution solution. In the compiled solution, the PLCopen standard defines several standard programming languages, such as ST (Structured Text), LD (Ladder Diagram), and IL (Instruction List). The core language of these languages ​​is ST; other languages ​​can be converted to ST to run programs. A compiled intermediate language is needed to interpret the ST language and complete the program execution. Since the motion controller in this invention is developed in C++ and includes a dedicated dynamic link library (DLL), and the laboratory testing environment also has the corresponding runtime environment, C++ was chosen as the intermediate language. The workflow of the soft PLC compiler for the correct execution of the soft PLC program is as follows: Figure 3 As shown.

[0042] 3.1 Trapezoid Diagram Translation For graphical languages ​​like ladder diagrams, they need to be translated into ST language first, and then translated into C++. For example... Figure 4 The ladder diagram program shown is edited and saved as an XML file on the application's front-end, and then parsed by the server back-end. Figure 5 The graph is a directed graph where large circles represent LD primitives and small circles represent the input and output ports of the primitives. Node S is the starting node, representing the left power line in the LD graph; node T is the ending node, representing the right power line in the LD graph.

[0043] According to the IEC 61131-3 standard, ladder diagrams must follow a defined and fixed scanning order. Program execution begins with the first rung at the top and proceeds line by line from top to bottom. When processing each rung, the calculation order of its internal elements follows the direction from the left busbar (power rail) to the right busbar. When a rung contains branches, the topmost branch is processed first, followed by solving the remaining parallel branches downwards, also following the left-to-right principle. Only after all parallel branches have been calculated and merged will execution continue to the logic element to the right of the merge point.

[0044] When applying execution logic to a directed graph, the following traversal rules can be followed: perform a depth-first search starting from the source node. For any node with multiple inputs, the node itself can only be processed after all its predecessor nodes (input paths) have been visited. Following the above traversal logic, the execution order of the elements in the ladder diagram sample program is as follows: Figure 6 As shown.

[0045] Once the order of the child elements in the directed graph is determined, the parent element's LD function topic can be translated into an ST program. An ST function topic consists of ST statements, and ST statements consist of various expressions. Therefore, ST statements are the building blocks of each element in the LD graph. During language conversion, the soft PLC system iteratively processes each LD element according to its predetermined execution order. When an LD element needs to be converted into a complete ST statement, the program first obtains the element's input and output parameters. These parameters are then integrated into an expression and embedded into the ST statement being generated. The iteration process only moves to the next LD element after the conversion of that statement is complete. Since the translation rules differ for each element, they will not be elaborated further here. Figure 4 The translation result of the trapezoidal diagram example is as follows:

[0046] 3.2 PLC Program Syntax Analysis The first step in program compilation is to perform syntax analysis on the written or translated ST program. Syntax analysis verifies whether the user follows the syntax rules defined in the IEC 61131-3 standard. It does not judge the program's logic, but rather confirms whether the arrangement of characters and symbols matches the syntax rules. If the input text conforms to the established syntax, a complete syntax tree is built.

[0047] In this invention, syntax analysis is implemented using ANTLR4 (Another Tool for Language Recognition v4). ANTLR4 is a powerful open-source syntax analysis tool that consists of two parts: one part generates a corresponding lexer and parser based on the user-written syntax file, and the other part uses the parser and parser in the application to analyze the text and generate a corresponding syntax tree.

[0048] Therefore, the implementation of syntax analysis in the project was transformed into writing the syntax rule file of the IEC 61131-3 standard. Text-based programming language rules typically consist of two parts: lexical and syntactic. Lexical rules determine how characters in text are grouped into words, and syntactic rules determine how words are combined into sentences.

[0049] Complex syntax requires multiple lexical and syntactic rules for description. To avoid confusion caused by multiple rules, ANTLR employs a complete matching logic. First, a lexical scan is performed, where the system iterates through all defined lexical rules, selecting the rule that matches the longest string as the result. If different rules match strings of the same length, the system prioritizes the rule defined earlier. Next comes syntactic parsing, which no longer involves a full traversal but instead attempts to match based on a predefined entry rule. During parsing, if nested rules are involved, the system expands them layer by layer; if multiple branches are available, the system prioritizes the first feasible sub-rule for deep matching, following the order in which the code is written, until the entire parse tree is constructed. When writing syntax rules using the ANTLR meta-language, the following rules must be followed: (1) Distinction between lexical and syntactic rules: The identifier of lexical rules must begin with an uppercase letter, and lexical symbols should be defined at the character level. In contrast, the identifier of syntactic rules must be developed with lowercase letters.

[0050] (2) Priority sorting rule: When the input symbol sequence may match multiple candidate expressions, ANTLR4 adopts the principle of matching the first one in order. In both lexical and syntactic rules, when faced with multiple selections separated by |, the parser will prioritize the one that is defined first in the lexical or grammatical file.

[0051] (3) Using direct left recursion rules to describe nested syntax: ANTLR4 natively supports left recursion rules, but requires direct left recursion rules to describe nested syntax, such as Figure 7 As shown. This form of syntax rule has a clear structure, with the earlier rules having higher priority. Recursive syntax rules can incorporate directions to adapt to different matching needs.

[0052] (4) One syntax rule can describe multiple sub-syntax rules: multiple sub-rules can be directly embedded into one rule, which is beneficial to improve the readability and cleanliness of the syntax rule file.

[0053] After the parser file is written, lexical and syntactic analysis is performed using the analyzer. If both lexical and syntactic analysis pass, it means that the ST program has no syntax errors, and the abstract syntax tree of the corresponding program is obtained. Otherwise, the ANTLR4 matching report is used as the error message.

[0054] 3.3 Domain Model Design and Transformation 3.3.1 Domain Model Design Since the abstract syntax tree generated in Section 3.2 contains all the syntactic details, directly translating the tree into C++ code would be too complex. In order to make the logical structure of the processing algorithm clear and have good readability, flexibility and maintainability, it is necessary to first convert the PLC program into a domain model suitable for processing, and then translate the code through the domain model.

[0055] According to the IEC 61131-3 standard, the Program Organization Unit (POU) is the core container for building a PLC program, mainly composed of a variable declaration area and a program body. A POU is both a modular encapsulation unit of code, supporting independent compilation, and the basic unit for constructing a complete user program. Therefore, building a domain model for a PLC program is essentially modeling the POU and its internal structure. Taking a function-type POU as an example, it contains elements such as variables (variable names, data types, etc.) and the program body (composed of multiple ST statements, etc.). Since a PLC program consists of multiple POUs, and each POU constructs logic through nested sub-elements (such as statements and expressions), the overall PLC program modeling process is essentially a comprehensive mapping and abstraction of all defined elements in the IEC 61131-3 standard. The resulting PLC program domain model is a comprehensive model system containing multi-level nested sub-models.

[0056] Based on object-oriented design principles, domain modeling involves mapping specific code elements to classes and defining the logical relationships between classes through abstraction. Taking a Point-of-Use (POU) written in Structured Text (ST) as an example, its program body (ST Body) consists of various specific statements such as assignment statements, IF statements, and FOR statements. Directly defining the combination relationship between the ST Body and various specific statement models in the model would lead to an overly redundant model structure and excessive coupling. Therefore, the design abstracts the common characteristics of various statements, extracting the general concept of "ST Statement" as the base class. Based on generalization, specific statements such as assignment, IF, and FOR are defined as subclasses of "ST Statement," thus establishing an "is-a" logical relationship. In this way, the ST Body model only needs to maintain the aggregation / composition relationship with the "ST Statement" base class to cover all types of sub-statements. This design not only significantly simplifies the model structure but also accurately represents the logical essence of the ST Body being composed of multiple ST statements.

[0057] The code translation of the entire program can be viewed as a synthesis of the code translations of various elements within the PLC program domain model. Therefore, each domain model needs to implement code translation. This commonality is abstracted and concretized as a class. Other domain models generalize from this model, each implementing its own code translation method.

[0058] 3.3.2 Generation of Domain Models Structured text (ST) possesses high syntactic complexity, supporting multi-level nested logical structures and rich expression types. Faced with such complex syntactic rules, using traditional linear parsing methods to construct domain models not only results in obscure parsing logic but also easily leads to the loss of contextual semantics. This invention employs the ANTLR4 visitor application framework, which provides developers with proactive control over the node traversal process and can more flexibly handle context passing and visitor management in nested structures. In the specific implementation of the transformation from ST programs to domain models, this invention designs a composite construction strategy that integrates the visitor pattern and the factory pattern. The visitor is responsible for traversing each node of the syntax tree and parsing the specific syntactic structure; once a specific syntactic unit (such as an assignment statement or iteration statement) is identified, the corresponding factory class is called to complete the instantiation and attribute population of the domain model object. This design of "separating traversal logic from construction logic" ensures the accuracy of the mapping from the abstract syntax tree to the domain model, effectively reduces the coupling between modules, and improves the system's scalability and code maintainability.

[0059] 3.4 Semantic Analysis After completing syntax analysis and constructing an abstract syntax tree based on the domain model, although the syntax tree reflects the hierarchical structure of the source program, it does not include information such as type constraints and scope visibility. Therefore, semantic analysis is required. The core task of semantic analysis is to traverse the syntax tree, perform validity checks on each node of the domain model, construct a symbol table, and ensure that the source program strictly adheres to the data type and logic rules of the IEC 61131-3 standard, laying the foundation for subsequent code generation.

[0060] This invention designs a semantic analysis strategy based on the visitor pattern. Since the domain model is a heterogeneous tree structure composed of nodes of different types, the visitor pattern allows for the definition of new operational logic without modifying node definitions, reducing code coupling. The semantic analyzer acts as a visitor, traversing the entire syntax tree. Whenever it visits a node of a specific type, it triggers corresponding checking logic. For example, when visiting a variable declaration node, the analyzer registers its metadata in the symbol table; when visiting a binary operation node, the analyzer retrieves the data type of the operand by querying the symbol table and verifies the validity of the operation rules.

[0061] The semantic analyzer also has a built-in type validation mechanism, and the system focuses on constraining the following scenarios: (1) Strong type constraint: The system prohibits implicit type conversion (such as using floating-point numbers directly for bit operations), and all operations with mismatched types will throw semantic errors during the compilation stage.

[0062] (2) Symbol uniqueness check: Use the scope stack to manage the symbol table to ensure that the variable names within the same scope are unique and to correctly handle the shadowing relationship between local variables and global variables.

[0063] (3) Variable type matching: When assigning a value to a variable, it should conform to the data type of the variable. For example, INT a:=0.1 will not be reported as an error in the syntax analysis, but 0.1 is not of type INT and will be reported as an error in the semantic analysis.

[0064] 3.5 Code Translation After completing syntax and semantic analysis, the system performs the final code translation stage, which involves generating a functionally equivalent C++ program based on the PLC user program. The code translation process primarily comprises two levels: "target code mapping specifications" and "code generation strategies." The former defines the mapping rules from IEC 61131-3 standard elements to C++ code (i.e., what kind of code to translate into), while the latter specifies the concrete algorithm for code conversion based on the domain model (i.e., how to translate).

[0065] The target code mapping specification is essentially a concrete implementation of each element in the IEC 61131-3 standard using the C++ language. Since the standard clearly defines the function and usage of each element, this article will not elaborate on the specific implementation details, but will focus on explaining the code generation strategy.

[0066] The code generation strategy is based on the domain model. Since the model presents a tree structure with nested sub-models, the translation methods can be categorized into two types based on how the parent element processes the child elements: (1) Independent Translation: The translation logic of this type of child element is independent and singular. The parent element does not need to interfere with the generation process of the child element, but only needs to concatenate the generated code fragments into its own translation template in sequence. For example, when translating the main function of ST language, it is only necessary to call the translation method of each ST statement and combine the results in sequence.

[0067] (2) Context-dependent translation: The translation of this type of child element depends on the specific scenario and does not have a unique translation form. The parent element needs to extract the attribute information of the child element and perform customized translation in combination with the context. For example, variable declarations in a function block need to be mapped to different areas of the C++ class definition template (such as public or private scope) according to the variable's type attribute (such as Input, Output, Internal) to achieve differentiated code generation.

[0068] After the code is completed, it is translated and compiled using a cross-compilation toolchain, the open-source g++ compiler, and the CMake build tool, organized as a script, executing a few commands to compile the C++ code.

[0069] 4. Equipment control and status monitoring 4.1 Equipment Control Module The equipment control module can not only receive PLC programs edited by the application interaction front end and perform logical motion control according to the set logic, but also receive various control commands issued by the interaction front end, such as single-axis motion, axis group motion and IO control, to realize single-axis and multi-axis debugging and IO control of the platform.

[0070] Specifically, for single-axis debugging, the control area includes servo enable, origin return, jog control, and emergency stop functions, and allows users to dynamically configure kinematic parameters such as speed, acceleration, and jerk. For multi-axis coordination, the control area provides functions for instantiating, activating, and resetting axis groups, supporting various motion modes such as point-to-point (PTP), linear interpolation, and circular interpolation. Users only need to specify the target position parameters to drive the axis group.

[0071] For I / O control, it consists of two parts: input ports and output ports. The input ports are used to view the input status of a specified I / O slave; users can only view but not modify them. The output port status not only allows viewing the output status of a specified I / O slave, but also allows users to click on the corresponding I / O point to modify the output status of the specified port.

[0072] When a user triggers the corresponding button, the browser sends a corresponding HTTP request carrying the relevant motion parameters. The service backend executes the corresponding routing function based on the registered request routing relationship mapping table. In the routing function, the corresponding motion control interface is called based on the parameter information of the user request, and the motion control system ultimately executes the specific control function.

[0073] The service backend and motion control system are common upper and lower level computer configurations. Common communication methods for these systems include HTTP and TCP / IP, with TCP / IP currently being the mainstream choice. This protocol is reliable, connection-oriented, and offers high transmission efficiency. Although TCP / IP has become the mainstream choice due to its connection-oriented reliability and high transmission efficiency, the development model based on native sockets has significant drawbacks: it requires independent development and maintenance of both client and server code, as well as handling complex message parsing, state synchronization, and exception handling logic at the application layer. Therefore, this system uses the gRPC framework to replace traditional TCP socket communication.

[0074] As a high-performance, general-purpose gRPC framework, its schematic diagram is as follows: Figure 8 As shown, gRPC not only supports automatic SDK generation in multiple language environments such as C, Java, and Go, but also has mature ecosystem support including Nginx. In terms of transmission efficiency, thanks to the Protocol Buffers binary serialization protocol, its data processing speed is 10 to 20 times faster than the traditional XML format. This invention chooses gRPC as the communication framework for two main reasons. Firstly, the service backend and the motion control system are written in Java and C++ respectively, representing cross-language calls. Secondly, it simplifies control logic; when using a remote interface to call functions of the control system as if calling a local interface, there is no need to concern oneself with the implementation of their respective underlying protocols.

[0075] The RPC framework's ability to perform remote calls, enabling clients to invoke server interfaces (as shown in the diagram) and call local functions, hinges on the server-side and client-side stubs. The client-side stub serializes method and parameter information into binary for network transmission, using TCP / IP sockets at the lower level. The server-side stub then deserializes and decodes this information. This invention only requires writing the corresponding proto files and generating the appropriate code for the supported single-axis, multi-axis, and IO monitoring APIs to achieve interaction between the server-side backend and the motion control system.

[0076] 4.2 Equipment Data Monitoring Module Given the extremely high real-time requirements of soft PLC systems for device monitoring data, the traditional HTTP protocol is ill-suited for this scenario. The HTTP protocol is limited by a passive "client request - server response" model, making it impossible for the server to proactively push data to the client. Furthermore, high-frequency request interactions lead to significant network overhead and latency.

[0077] To overcome this communication bottleneck, this invention introduces the WebSocket protocol. While based on HTTP during the handshake phase, this protocol subsequently upgrades to a persistent full-duplex connection. This mechanism not only significantly reduces communication latency but also empowers the server to proactively send data, thus providing an efficient and stable transmission channel for the system's high-frequency real-time monitoring.

[0078] WebSocket connections are established and closed using the `open()` and `close()` interfaces. Data sending and receiving are handled by `send()` and `message()`, and the `error()` interface is used to handle exceptions that occur during data transmission. After a WebSocket connection is established between the two parties, the server can transmit real-time data collected from the device to the requesting server for data updates and view rendering.

[0079] While the WebSocket protocol effectively meets the need for real-time data transmission, complex industrial environments often exhibit uncontrollable fluctuations in network performance. If the communication link is abnormally interrupted due to physical failure or network fluctuations, and the standard `close()` handshake process is not triggered, both communicating parties will enter a "half-open" state. In this situation, the other end cannot perceive the connection failure, leading to a failure to trigger reconnection or alarms in a timely manner, thus increasing the risk of data loss. To address this vulnerability, this paper draws inspiration from the keep-alive principle of the TCP protocol and designs a heartbeat detection and reconnection mechanism at the application layer to ensure the reliability of the WebSocket connection throughout its entire lifecycle.

[0080] The heartbeat detection process designed in this invention is as follows: Figure 9As shown, after a successful WebSocket connection handshake, the system immediately starts a heartbeat timer, sending a probe packet to the peer every 30 seconds. If a correct response is received within the specified time limit, the link is considered healthy; if the response times out, the system does not immediately determine that the connection is broken to rule out false alarms caused by momentary network congestion. At this time, the system enters a secondary verification mode: pausing the main heartbeat timer, starting a service confirmation timer, and immediately resending the probe packet. If a response is received in time this time, the system returns to normal; if there is still no response, a high-frequency retry strategy is executed (retransmitting once every 5 seconds, up to a maximum of 3 times). If all 3 consecutive retries fail, the connection is ultimately determined to be abnormal, triggering an alarm and executing the WebSocket service restart or reconnection process. 5. Specific Implementation Examples 5.1 Example of a PLC Programming System This invention is a software for PLC programming and debugging. It has a complete interface function, supporting ladder diagram program drawing, editing, saving, downloading, equipment data monitoring, and equipment debugging. The system interface is as follows: Figure 10 As shown, the interface layout is clear. The top features a menu bar with file operations and help functions; the left side has a project tree for overall management of projects, program structure, and variable lists; the right side is equipped with an instruction toolbox, providing various basic and extended instruction elements for use; and the central area, which occupies the core position, is the main drawing and variable interaction area, where users can complete the editing and drawing of ladder diagrams and view and modify variable content.

[0082] like Figure 11 As shown, users can manage project files with the .project extension throughout the entire process through the file drop-down menu in the header: they can create new projects and specify the file name and save path, open existing files to read the ladder diagrams and variable information, or save the current editing state at any time to ensure data security for subsequent development or download.

[0083] Program development begins in the project tree on the left. Users must first locate and enter the Main_Program main program drawing interface; then, they use the command bar on the right to configure and generate the left and right buses, establishing the basic framework of the ladder diagram. Based on this, normally open / normally closed contacts, output coils, and various function blocks are flexibly laid out by dragging and dropping, and the line tool is used to quickly complete the logical connections between elements by capturing input and output endpoints. Finally, the names and parameter settings of each component are refined one by one to ensure the rigor and completeness of the control logic, thereby constructing an executable ladder diagram program.

[0084] like Figure 12-13As shown, after editing the ladder diagram program, you can click "Run" in the header, and then click "Send Data," "Compile Program," and "Download Program" in sequence. The server background will automatically convert it into C++ code and download the compiled dynamic library file to the motion controller for execution.

[0085] 5.2 Equipment Commissioning and Status Monitoring Single-axis debugging allows for individual motion tuning by inputting different motion parameters for each axis, primarily for debugging point-to-point motion functionality. Users can access the single-axis debugging interface by clicking on "Single-Axis Debugging" under "Function Test" in the project tree on the left. Figure 14 As shown.

[0086] like Figure 15 As shown, after entering the interface, users can set motion parameters such as start speed, end speed, acceleration, deceleration, and jerk to perform single-axis testing. The application's front-end sends an HTTP request to the server back-end through the browser, and the server back-end remotely calls the API provided by the motion controller via gRPC to realize the single-axis debugging function.

[0087] Similarly, users can perform axis group tests through the axis group interface in the functional test. (See Figure 16) Figure 16a , Figure 16b As shown in the image, clicking "Create Axis Group" will bring up a dialog box. Enter the axis number and click "OK" to create the group successfully. Multiple axis groups can be created simultaneously.

[0088] To ensure safe operation of the equipment, please ensure that all parameters are within the allowable range during operation. The axis group function covers the entire process from state control to motion execution: users can switch drive outputs via "Enable / Disable Axis Group" to control its entry or exit from the motion-ready state; for motion planning, acceleration / deceleration and curve shape must first be configured in the pop-up window using "Set Speed ​​Curve"; then, according to requirements, instructions such as "Absolute / Relative Constant Length Motion," "Circular Interpolation (Absolute / Relative)," or "Continuous Interpolation IO Output" can be selected, as shown in Figure 18. Figure 18a , Figure 18b and Figure 18c As shown in the image. When performing any of the above functions, the system will automatically pop up a parameter setting dialog box, as shown in the image. Figure 17 As shown, users only need to enter the corresponding values ​​and click confirm, and the axis group will perform the corresponding actions according to the set parameters.

[0089] This system can perform single-axis and multi-axis debugging, as well as IO control and IO monitoring. Clicking on IO monitoring in the functional test will take you to the IO control interface, such as... Figure 19As shown, the corresponding interface displays all I / O information. Clicking the name of the corresponding I / O device will take you to the corresponding I / O monitoring interface, where you can monitor and read / write the I / O. Clicking "Start Monitoring" will begin monitoring. For digital inputs and outputs, a red I / O indicates that it is disconnected, and a green I / O indicates that it is connected. Analog inputs and outputs are represented by specific numbers. Digital inputs can only be read, not written, while digital outputs can be written. Clicking on the corresponding digital output channel will toggle the status of that channel.

[0090] like Figure 20 As shown, analog inputs can only be read, not written, while analog outputs can be written. Click on the analog output channel, input the corresponding value, and click "write" to write the corresponding value.

[0091] like Figure 21 As shown, if the device supports both ordinary I / O and plug-in I / O, if it is ordinary I / O, there is only one I / O monitoring on the corresponding interface. If it is plug-in I / O, the corresponding monitoring interface will show all the plug-in I / O on the corresponding coupler. The order of the plug-in from top to bottom corresponds to the position of the plug-in on the coupler.

[0092] This PLC programming and debugging software can also perform axis status detection, speed curve detection, and position-time curve detection.

[0093] Click on "Axis Status Monitoring" in the functional tests to enter the axis status monitoring interface, such as... Figure 22 As shown in the image, this interface can monitor the current axis speed, the current axis command position, the current axis encoder feedback position, the current axis planned position, and the current axis motion completion status.

[0094] like Figure 23 As shown, this software can capture real-time speed-time data for each axis and plot the corresponding speed-time curves. The vertical axis represents speed, and the horizontal axis represents time. Clicking "Axis Display" allows you to select the axis whose speed-time curve you want to display on the interface. Speed-time curves for different axes can be displayed simultaneously. Different axes have different colored curves. Unchecking a corresponding axis will hide its curve.

[0095] like Figure 24 As shown, the software can also capture the position and time relationship data of each axis in real time and plot position-time curves. The vertical axis represents displacement, and the horizontal axis represents time. Clicking "Axis Display" allows you to select the position-time curve of the axis you want to display on the interface. Position-time curves of different axes can be displayed simultaneously. The curves corresponding to different axes have different colors. Unchecking the corresponding axis will cancel the display of the curve for that axis.

[0096] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A soft PLC programming and debugging system, characterized in that, include: The application's interactive front-end is built on Web technology and deployed in the user's browser in a back-end separation manner. It is used to provide functions such as soft PLC program editing, remote access to equipment, parameter configuration, and visualization of equipment motion status. The soft PLC program editing includes ladder diagram drawing; The server-side backend, which communicates with the application's frontend, adopts a modular design and includes: The compilation module is used to translate and compile user-edited, standards-compliant soft PLC programs into executable native code for the target platform via structured text ST. The device control module is used to receive device debugging instructions from the application interaction front end through a remote procedure call framework and send them to the motion controller; The status monitoring module is used to collect the operating data of the motion controller, feed it back to the application interaction front end in real time through a streaming push protocol, and monitor the communication connection status through a detection and reconnection mechanism and trigger reconnection when abnormal.

2. The soft PLC programming and debugging system according to claim 1, characterized in that, The trapezoidal graph drawing includes primitive snapping and primitive rendering. Primitive snapping calculates the Euclidean distance between the cursor coordinates and the primitive feature points, and triggers automatic alignment when the distance is less than a preset snapping threshold. Primitive rendering is based on the scene graph architecture of the Konva framework, which encapsulates geometric lines and text labels into a unified entity and dynamically maps them to the Canvas view.

3. The soft PLC programming and debugging system according to claim 1, characterized in that, The ladder diagram drawing also includes primitive drawing and primitive transformation, wherein: each primitive object has an input port and an output port, and the port maintains a dynamic connection array, which is used to record the reference relationship between primitives when the user establishes a connection, thereby transforming the ladder diagram logic into a directed graph structure that can be parsed by the server backend.

4. The soft PLC programming and debugging system according to claim 1, characterized in that, The compilation module executes a compiled runtime scheme, and its workflow includes: Translate the ladder diagram program into an ST program; The ST program is subjected to syntax analysis to generate an abstract syntax tree. A domain model is constructed based on the abstract syntax tree, and semantic analysis is performed on the domain model. Generate functionally equivalent C++ source code based on the aforementioned domain model; The C++ source code is compiled into a native dynamic link library.

5. The soft PLC programming and debugging system according to claim 4, characterized in that, The process of translating the ladder diagram program into an ST program includes: The ladder diagram program is parsed into a directed graph structure with nodes and edges, where nodes represent ladder diagram primitives and edges are established based on the logical connection relationships between primitives; Traverse the directed graph structure according to the ladder diagram scanning order specified in the standard to generate the corresponding ST statement sequence.

6. The soft PLC programming and debugging system according to claim 4, characterized in that, The parsing is performed using the ANTLR4 tool, with lexical and syntactic rules written based on standards. Lexical rule identifiers begin with an uppercase letter, and syntactic rule identifiers begin with a lowercase letter. Nested syntax is described using direct left recursive rules. The semantic analysis includes strong type constraint verification, symbol uniqueness verification, and variable type matching verification. Implicit type conversion is prohibited, and variable names are ensured to be unique within the same scope, and variable assignments are consistent with data types.

7. The soft PLC programming and debugging system according to claim 4, characterized in that, The domain model is constructed based on standard program organization units, abstracting the ST statement base class. Assignment statements, IF statements, and FOR statements inherit from this base class as subclasses. The transformation from abstract syntax tree to domain model is achieved through a strategy combining the visitor pattern and the factory pattern.

8. The soft PLC programming and debugging system according to claim 1, characterized in that, The remote procedure call framework is the gRPC framework, based on the HTTP / 2 protocol and Protocol Buffers binary serialization protocol, which enables efficient communication, fast data processing and simplified control logic, and supports cross-language calls. The server backend and motion controller achieve low-latency transmission of control commands through this framework and protocol.

9. The soft PLC programming and debugging system according to claim 1, characterized in that, The device control module is used to receive control commands issued by the application interaction front end, and to issue the commands to the motion controller through the gRPC-based remote procedure call framework to perform single-axis debugging, axis group motion control and IO control. The axis group motion control supports the creation of multiple axis groups and provides various motion modes, including absolute position movement, relative position movement, circular interpolation, and continuous interpolation. Users can drive the axis group to run by configuring motion parameters and target positions or offsets for the axis group.

10. The soft PLC programming and debugging system according to claim 1, characterized in that, The streaming push protocol is the WebSocket protocol. The detection and reconnection mechanism sends probe packets at intervals through the main heartbeat timer. After the response times out, the service confirmation timer is started and the probe packets are resent. After several consecutive failed retries, the connection is determined to be abnormal and a disconnection reconnection is triggered.

Images