Graphical language generation method and device, equipment and storage medium

Abstract

The invention discloses a graphic language generation method and device, equipment and a storage medium, and relates to the technical field of programmable logic controllers, and the disclosed graphic language generation method comprises the steps of responding to a starting operation of an editor of a programmable logic controller, and displaying a dialogue window, the dialogue window comprises a first area, a second area and a first control; receiving task demand description information based on the first region; and in response to a trigger operation of the first control, displaying a graphic language generated based on the task demand description information in the second area. Through the scheme, the development efficiency of the graphic language of the PLC is improved, and the development period of the graphic language of the PLC is shortened.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of programmable logic controller, and particularly relates to a generation method and device of a graphic language, equipment and a storage medium. BACKGROUND

[0002] At present, an editor of a programmable logic controller (PLC) has become a core tool platform of modern project engineering development, and can support development of a text language program and development of a graphic language program, and provides a good development environment for developers. Then, development of a graphic language of a PLC mainly depends on manual work at present, so that a development cycle of the graphic language of the PLC is relatively long. SUMMARY

[0003] The main purpose of the present application is to provide a generation method and device of a graphic language, equipment and a storage medium, and aims to improve development efficiency of a graphic language of a programmable logic controller (PLC) and shorten a development cycle of the graphic language of the PLC.

[0004] To achieve the above purpose, the present application provides a generation method of a graphic language, comprising the following steps. In response to a starting operation of an editor of a programmable logic controller, a dialog window is displayed, wherein the dialog window comprises a first area, a second area and a first control; Task requirement description information is received based on the first area; In response to a triggering operation of the first control, a graphic language generated based on the task requirement description information is displayed in the second area.

[0005] In an embodiment, in response to the triggering operation of the first control, displaying the graphic language converted based on the task requirement description information in the second area comprises the following steps. In response to the triggering operation of the first control, a text language is generated based on an AI large model and the task requirement description information, and the text language is displayed in the second area; The graphic language is generated based on the text language, and the graphic language is displayed in the second display area.

[0006] In an embodiment, generating the graphic language based on the text language and displaying the graphic language in the second display area comprises the following steps. The text language is parsed to obtain a syntax tree; The syntax tree is converted into a graphic element data structure; The graphic language is generated according to the graphic element data structure, and the graphic language is displayed in the second area.

[0007] In one embodiment, the text language includes an instruction list language. In response to a triggering operation of the first control, generating the text language based on the AI ​​large model and task requirement description information includes: In response to the triggering operation of the first control, the AI ​​big model parses the task requirement description information and the system prompt information associated with the task requirement description information to obtain the intent recognition result; based on the preset instruction content that matches the intent recognition result, an instruction table language is generated, and the preset instruction content is stored in the preset instruction database.

[0008] In one embodiment, the text language includes an instruction list language, and parsing the text language to obtain a syntax tree includes: The lexical analysis of the instruction list language is performed by a parsing tool, and the syntax of the instruction list language is parsed to generate a syntax tree; the parsing tool is a functional component of the programmable logic controller's editor.

[0009] In one embodiment, the graphical element data structure includes a ladder diagram data structure, and converting the syntax tree into a graphical element data structure includes: The graphical element management tool traverses the nodes in the syntax tree; it searches for matching ladder diagram elements from the preset graphical element database based on the attributes of each node, and generates a ladder diagram data structure based on the connection relationships between nodes; the graphical element management tool is a functional component of the programmable logic controller's editor.

[0010] In one embodiment, the graphical element data structure includes a ladder diagram data structure, and the graphical language includes a ladder diagram language; generating the graphical language based on the graphical element data structure includes: Ladder diagram language is generated based on the ladder diagram data structure using a graphical editing tool; the graphical editing tool is a functional component of the editor for programmable logic controllers.

[0011] In one embodiment, the method for generating graphical language further includes: In response to the startup operation of the programmable logic controller's editor, the editor's development interface is displayed, which includes a graphical language display area; Obtain the graphical language of the second region and display the graphical language in the graphical language display area.

[0012] In one embodiment, acquiring the graphical language of the second region and displaying the graphical language in the graphical language display area includes: Retrieve the graphical language in response to the triggering operation of the control associated with the graphical language; In response to the triggering operation of the second control in the development interface, the graphical language is displayed in the graphical language display area.

[0013] In one embodiment, displaying graphical language in the graphical language display area includes: In response to the drag-and-drop operation of the graphical language, drag the graphical language of the second area; When the graphical language is dragged from the second area to the graphical language display area, the graphical language is displayed in the graphical language display area in response to the release operation corresponding to the drag operation.

[0014] Furthermore, to achieve the above objectives, this application also proposes a graphical language generation apparatus, comprising: The first display module is used to display a dialog window in response to the startup operation of the programmable logic controller's editor, wherein the dialog window includes a first area, a second area, and a first control; The receiving module is used to receive task requirement description information based on the first region; The second display module is used to respond to the triggering operation of the first control and display the graphical language generated based on the task requirement description information in the second area.

[0015] In addition, to achieve the above objectives, this application also proposes a graphical language generation device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the graphical language generation method described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the graphical language generation method described above.

[0017] This application provides a visual dialog window. Through the task requirement description information received in the first area of ​​this dialog window, and the triggering operation of the first control in the dialog window, a graphical language generated based on the task requirement description information can be automatically displayed in the second area of ​​the dialog window. Compared to the manual generation of PLC graphical language in related technologies, this application, because it can be operated on a visual dialog window, allows for simple input of task requirement description information, automatically and quickly generating the required PLC graphical language. This improves the development efficiency of PLC graphical language and shortens the development cycle. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating an embodiment of the graphical language generation method of this application; Figure 2 This is a schematic diagram of the dialog window for this application; Figure 3 This is a schematic diagram illustrating the split-screen display of the dialog window and editor in this application; Figure 4 This is an interactive diagram of the PLC editor and intelligent assistant in this application; Figure 5 This is a schematic diagram of the architecture of the PLC editor and intelligent assistant in this application; Figure 6 This is another interactive schematic diagram of the graphical language generation method of this application; Figure 7 This is a schematic diagram of the module structure of the graphical language generation device according to an embodiment of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] In the field of modern industrial automation control, PLCs (Programmable Logic Controllers) play a crucial role as core control devices. With their high reliability, powerful control functions, and flexible programming features, they are widely used in various industrial production scenarios, covering numerous industries such as machinery manufacturing, power, chemical engineering, and transportation, becoming a key element in ensuring the stable and efficient operation of industrial production.

[0025] With the continuous improvement of industrial automation, the requirements for PLC development tools are becoming increasingly stringent. As a core tool platform for modern project engineering development, the importance of PLC editors is becoming increasingly prominent. Today's PLC editors are increasingly powerful and diversified, supporting not only text-based programming languages, such as instruction list-based programming, allowing developers to implement complex control logic through concise instruction sequences, but also graphical programming language development capabilities, such as ladder diagrams (LAD) and function block diagrams (FBD). These graphical symbols and logical connections greatly reduce programming difficulty, making them particularly suitable for engineering technicians without extensive programming experience. These features create a favorable development environment for developers, effectively improving development efficiency and code quality.

[0026] However, a prominent problem remains to be solved in the current development of PLC graphical languages. Currently, PLC graphical language development relies primarily on manual labor. From drawing graphical elements and establishing logical relationships to debugging and optimizing the overall program, every step requires manual operation by developers. This approach not only demands high levels of technical skill and experience from developers but is also cumbersome and time-consuming. Due to the subjectivity and uncertainty inherent in manual operation, errors are prone to occur when handling complex control logic and large-scale graphical programs, leading to repeated modifications and debugging, further extending the development cycle. Therefore, improving the efficiency of PLC graphical language development and shortening the development cycle has become a pressing technical challenge in the field of industrial automation.

[0027] To address the aforementioned issues, this application proposes a method for generating graphical language. The main technical solution includes: displaying a dialog window in response to the startup operation of the programmable logic controller's editor, wherein the dialog window includes a first area, a second area, and a first control; receiving task requirement description information based on the first area; and displaying the graphical language generated based on the task requirement description information in the second area in response to the triggering operation of the first control.

[0028] This application provides a visual dialog window. Through the task requirement description information received in the first area of ​​this dialog window, and the triggering operation of the first control in the dialog window, a graphical language generated based on the task requirement description information can be automatically displayed in the second area of ​​the dialog window. Compared to the manual generation of PLC graphical language in related technologies, this application, because it can be operated on a visual dialog window, allows for simple input of task requirement description information, automatically and quickly generating the required PLC graphical language. This improves the development efficiency of PLC graphical language and shortens the development cycle.

[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or a graphical language generation device capable of performing the above functions. The following description uses a graphical language generation device as an example to illustrate this embodiment and the subsequent embodiments.

[0030] It should be noted that the device generating this graphical language is equipped with a PLC editor and a smart assistant. The following will provide a detailed introduction to the PLC editor and smart assistant: Among them, the intelligent assistant acts as an information transmission bridge, used to receive task requirement description information, call the AI ​​big model to generate text language based on the task requirement description information, and call the editor's functional components to convert the text language generated by the AI ​​big model into graphical language, etc.

[0031] The aforementioned intelligent assistant can be integrated into the PLC's editor as a plugin, or it can operate independently of the PLC's editor. The intelligent assistant's dialog window and the editor's development interface can be displayed on the graphical language generation device's screen.

[0032] The aforementioned intelligent assistant can specifically include a visual dialogue window and an intermediate controller. The dialogue window, acting as the front end, receives task requirement descriptions and displays text and graphical representations, primarily handling task reception and display. The intermediate controller, acting as the back end, communicates with various services via API (Application Programming Interface) for data transmission. The PLC's editor communicates with the intermediate controller via the MCP protocol. The intermediate controller receives task requirement descriptions, calls corresponding services to process these descriptions, and retrieves the text generated by these services based on the task requirement descriptions. It also calls the PLC's editor's functional components to convert the text into graphical representations.

[0033] The PLC editor is used for project development in industrial equipment-related fields. This PLC editor can expose the interfaces of its functional components, allowing intelligent assistants to call these interfaces to generate graphical interfaces.

[0034] Based on this, embodiments of this application provide a method for generating graphical language, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the graphical language generation method of this application.

[0035] In this embodiment, the method for generating graphical language includes steps S10 to S30: Step S10: In response to the startup operation of the programmable logic controller's editor, a dialog window is displayed, wherein the dialog window includes a first area, a second area, and a first control.

[0036] The dialog window is an interactive window that appears after the PLC editor is started. It provides a platform for information exchange and operation interaction between the user and the editor. Its core function is to receive task requirement description information and display text and graphical language.

[0037] Reference Figure 2 The dialog window is divided into a first area 02, a second area 01, and a first control 03. The first area refers to the user input field in the dialog window, where users can enter text or upload files to describe their task requirements. The first area may include an edit box and the aforementioned first control, or it may consist of only an edit box with the first control independent of it. The second area is used to display the output results, primarily for displaying textual and graphical representations. The first control is a trigger button in the dialog window, such as a generate / convert button, which, when clicked, triggers the process of requirement conversion and result display. The specific positions of the first area, second area, and first control within the dialog window are not limited; for example, the first area can be located at the bottom of the dialog window, and the second area can be located at the top.

[0038] Step S20: Based on the first region, receive task requirement description information.

[0039] The task requirement description information refers to the content entered by the user in the first area to express the development goals. This description is not limited to text; it can also be in the form of voice, images, video, etc. For example, when describing the task requirement information in text form, it could be "Use a graphical language to generate a program for axis reciprocating motion," and this text can be edited within the edit box in the first area. When describing the task requirement information in voice form, the first area may also include a voice input control, allowing the user to receive the voice description by long-pressing the control. When describing the task requirement information in image or video form, the first area may also include an insert control, which, when clicked, redirects the user to the storage location of the image or video containing the task requirement description information, allowing the user to select and upload the image or video.

[0040] Step S30: In response to the triggering operation of the first control, display the graphical language generated based on the task requirement description information in the second area.

[0041] Graphical language refers to the PLC program expression form presented in the form of graphical symbols and logical connections, such as ladder diagrams (LAD) and function block diagrams (FBD), which are further converted from textual language.

[0042] In one alternative approach, the first area can have an editing function, allowing users to edit task requirement descriptions and send them. After entering the task requirement description, the user clicks the first control to send it to the backend. Upon receiving the task requirement description from the frontend, the backend invokes a service to generate a graphical representation based on the description. Finally, the graphical representation is fed back to the second area of ​​the frontend's smart assistant for display.

[0043] In another alternative approach, besides using the method described above of editing task requirement descriptions in the first area to receive them, in other application scenarios, the dialog window can consist of only a first area and a second area. In the first area, the task requirement descriptions can be encapsulated and displayed as controls for user selection. In this case, these task requirement descriptions can be historical task requirement descriptions or preset task requirement description templates. Specifically, in response to a trigger operation of any task requirement description control in the first area of ​​the front-end intelligent assistant, the task requirement description information associated with that control can be sent, enabling the back-end to receive the task requirement description information. After receiving the task requirement description information sent by the front-end, the back-end calls the corresponding service to generate a graphical language based on the task requirement description information. Finally, the graphical language is fed back to the second area of ​​the front-end intelligent assistant for display. Thus, by encapsulating the task requirement description information as controls, users can select as needed without editing, providing convenience for user operation and improving the efficiency of graphical language generation.

[0044] It should be noted that after the user triggers the control, they are essentially sending a task requirement description to the intermediate controller. Upon receiving the task requirement description, the intermediate controller calls the corresponding services through the API interface. These services generate a graphical language based on the task requirement description and then feed the generated graphical language back to the intermediate controller. The intermediate controller then sends it to the second area of ​​the front-end dialog window for display. This completes the series of processes for receiving, processing, and displaying the task requirement description, thereby generating the graphical language information.

[0045] In this embodiment, by providing a visual dialog window, the task requirement description information received in the first area of ​​the dialog window, and the triggering operation of the first control in the dialog window, can automatically display the graphical language generated based on the task requirement description information in the second area of ​​the dialog window. Compared with the manual generation of PLC graphical language in related technologies, this application can operate on a visual dialog window. By simply inputting the task requirement description information in the dialog window, the required PLC graphical language can be automatically and quickly generated, thus improving the development efficiency of PLC graphical language and shortening the development cycle of PLC graphical language.

[0046] Based on the above, in one feasible implementation, step S30 may include steps S31 to S32: Step S31: In response to the triggering operation of the first control, generate text language based on the AI ​​big model and task requirement description information, and display the text language in the second area; The text language is a sequence of codes or instructions presented in text form, conforming to the rules of a specific programming language. It is obtained through analysis and reasoning of task requirement descriptions and is used to express the control logic of a PLC program. The text language is characterized by its simplicity and ease of understanding. These text languages ​​can be PLC-related instruction list languages, XML-formatted text languages, or other types of text languages; this application does not impose specific limitations.

[0047] The AI ​​large-scale model refers to an artificial intelligence model with natural language understanding and text language generation capabilities, such as GPT-4, used to generate intermediate text language based on task requirement description information. This AI large-scale model can be pre-trained using knowledge from the relevant domain of this application, or it can be a general-purpose AI large-scale model, or it can be obtained through fine-tuning. The AI ​​large-scale model can be trained using all relevant knowledge required in the PLC development field. For example, it can be trained using task requirement description information samples and their corresponding text language samples required in the PLC development process. It can also be trained using task requirement description information samples and their corresponding graphical language samples required in the PLC development process.

[0048] It should be noted that in practical applications, the rules for generating graphical languages ​​are complex, involving extensive logical reasoning and the combination of graphical elements, making the reasoning process cumbersome and time-consuming. In contrast, the rules for generating textual languages ​​are relatively simple. First, textual language is generated based on the task requirements, and then it is converted into graphical language. This allows for the rapid transformation of requirements into a more standardized and easily processed form of expression. Generating graphical language on this simple and standardized foundation simplifies the reasoning process, reduces reasoning time, and thus improves overall development efficiency.

[0049] Step S32: Generate a graphical language based on the text language and display the graphical language in the second display area.

[0050] In one alternative approach, the first area can have an editing function, allowing users to edit task requirement descriptions and send them. After entering the task requirement description, the user clicks the first control to send it to the backend. Upon receiving the task requirement description, the backend invokes an AI model to generate text and then converts it into graphical representations. Finally, the text and graphical representations are fed back to the second area of ​​the frontend's intelligent assistant, where they are displayed: the generated text and the converted graphical representations. This approach, using an AI model to generate both text and graphical representations, improves the efficiency of text generation.

[0051] In another alternative approach, besides using the method described above of editing task requirement descriptions in the first area to receive them, in other application scenarios, the dialog window can consist of only a first area and a second area. In the first area, the task requirement descriptions can be encapsulated and displayed as controls for user selection. In this case, these task requirement descriptions can be historical task requirement descriptions or preset task requirement description templates. Specifically, in response to a trigger operation of any task requirement description control in the first area of ​​the front-end intelligent assistant, the task requirement description information associated with that control can be sent, enabling the back-end to receive the task requirement description information. After receiving the task requirement description information sent by the front-end, the back-end calls the AI ​​large model to generate text language based on the task requirement description information, and converts the text language into graphical language. Finally, the text language and graphical language are fed back to the second area of ​​the front-end intelligent assistant to display the generated text language and the graphical language converted from the text language. Thus, by encapsulating the task requirement description information as controls, users can select as needed without editing, providing convenience for user operation and improving the efficiency of graphical language generation.

[0052] It should be noted that after the user triggers the control, they are essentially sending a task requirement description to the intermediate controller. Upon receiving this description, the intermediate controller calls the AI ​​model via an API interface. The AI ​​model generates text based on the task requirement description and then converts it into graphical language. Both the generated text and graphical language are then fed back to the intermediate controller, which in turn sends them to the second area of ​​the front-end dialog window for display. This completes the entire process of receiving, processing, and displaying the task requirement description, thereby generating the graphical language information.

[0053] In one alternative approach, the intermediate controller, responding to a triggering operation by the first control, forwards the task requirement description information to the AI ​​large-scale model service. The AI ​​large-scale model receives the task requirement description information, processes it, and generates text language. This text language is then returned to the intermediate controller, enabling it to access the text language generated by the AI ​​large-scale model based on the task requirement description information. The intermediate controller then feeds the text language back to the front end, displaying it in the second area of ​​the front end's dialog window. In this way, text language generation is achieved through the AI ​​large-scale model, improving the efficiency of text language generation.

[0054] The intermediate controller mentioned above responds to the triggering operation of the first control by forwarding the task requirement description information to the AI ​​large model. This service can be any of the following examples: Example 1: The intermediate controller can call the API provided by the AI ​​large-scale model, passing the task requirement description as an input parameter. During the call, the input data is formatted and encapsulated according to the API requirements, such as converting the task requirement description into JSON format, and then the request is sent to the AI ​​large-scale model server. After processing the request, the server returns the generated text language in a specified format, such as JSON, and the intermediate controller then parses the returned data to extract the text language. Utilizing the API interface ensures stable communication with the AI ​​large-scale model and accurate acquisition of the generated text language. Furthermore, formatting and encapsulating data according to specifications improves the accuracy and efficiency of data transmission, reduces errors caused by data format issues, and ensures that the acquired text language completely and accurately reflects the task requirements.

[0055] Example 2: The middle controller can construct HTTP requests to interact directly with the AI ​​model. It includes the task requirement description as part of the request body, sets appropriate request headers, and sends a POST request to the AI ​​model. After the AI ​​model returns a response, the middle controller parses the response content, such as parsing JSON data, to obtain the generated text. This simple and easy-to-use interface simplifies the process of writing network requests and reduces development difficulty. By flexibly setting request parameters and headers, it can adapt to the interface requirements of different AI models, improving code versatility and portability, and quickly obtaining the required text.

[0056] In this embodiment, by providing a visual dialog window, the task requirement description information received in the first area of ​​the dialog window, and the triggering operation of the first control in the dialog window, can generate text language based on the AI ​​big model and the task requirement description information, and display the text language in the second area. After generating the text language, a graphical language can be generated based on the text language and displayed in the second display area. Compared with the related technologies that manually generate the graphical language of PLCs, this application can operate on a visual dialog window. By simply inputting the task requirement description information in the dialog window, the AI ​​big model's service capabilities first generate an easy-to-process text language based on the task requirement description information, and then convert the text language into a graphical language. This can quickly transform the requirement into a more standardized and easy-to-process expression form. The generation of graphical language on the basis of a simple and standardized expression form simplifies the reasoning process, reduces reasoning time, and thus improves overall development efficiency.

[0057] Based on the above, in one feasible implementation, the text language includes an instruction list language. In step S31, responding to the triggering operation of the first control, generating the text language based on the AI ​​large model and task requirement description information includes: In step S311, in response to the triggering operation of the first control, the AI ​​big model parses the task requirement description information and the system prompt information associated with the task requirement description information to obtain the intent recognition result; based on the preset instruction content that matches the intent recognition result, an instruction table language is generated, and the preset instruction content is stored in the preset instruction database.

[0058] The above step S311 may specifically include: (1) In response to the triggering operation of the first control, the intermediate controller obtains the system prompt information associated with the task requirement description information.

[0059] The system prompts can be pre-set text content designed to guide the AI ​​model in more accurately understanding the task requirements, or to provide the AI ​​model with auxiliary information such as specific processing rules and contextual information. This helps the model better grasp the direction and focus of the task, reducing comprehension biases.

[0060] In one alternative approach, a series of system prompt templates potentially related to different types of task requirements can be predefined. These templates are stored as variables or strings in the program's configuration file or constant class. When the first control is triggered, based on key features of the task requirement description, such as keywords and task type, the most suitable system prompt is selected from the predefined templates using conditional judgment or matching algorithms. By predefining templates and selecting based on task characteristics, associated system prompts can be obtained quickly and accurately, improving the efficiency and accuracy of information retrieval. Furthermore, the template-based design facilitates maintenance and expansion; when a new task type appears, only the corresponding template needs to be added.

[0061] In another alternative approach, a system prompt information knowledge graph can be established, linking and storing various task requirement descriptions with their corresponding system prompts in a graph format. When the first control is triggered, natural language processing techniques are used to extract features and perform semantic analysis on the task requirement descriptions. Then, the knowledge graph is searched and matched to find the most relevant system prompts. The knowledge graph can more comprehensively represent the relationship between task requirements and system prompts. Through semantic analysis and graph search, more accurate association information can be obtained, especially when dealing with complex or ambiguous task requirement descriptions, providing more precise system prompts and improving the AI ​​model's ability to understand tasks.

[0062] (2) The intermediate controller sends the system prompt information and task requirement description information to the AI ​​big model. The AI ​​big model is used to parse the system prompt information and task requirement description information to obtain the intent recognition result; retrieve the preset instruction content that matches the intent recognition result from the preset instruction database; and generate the instruction table language according to the preset instruction content.

[0063] The intent recognition result is the category or specific description of the user's true need intent identified by the AI ​​model after analyzing and processing the system prompts and task descriptions. For example, if the user inputs a task requirement of "use graphical language to generate a program that reciprocates along an axis," the intent recognition result might be "use graphical language to generate a program that reciprocates along an axis."

[0064] The preset instruction database is a pre-built database that stores preset instruction content corresponding to various intentions. This instruction content is written according to specific rules and formats to guide the generation of the final instruction table language. The content in the database can be expanded and modified according to actual needs.

[0065] Instruction list language is a specific language form used to describe control logic or operation instructions. It is typically characterized by its conciseness, standardization, and ease of computer recognition and execution. It can be a text-based form similar to an instruction list, used to guide devices such as PLCs to perform corresponding operations.

[0066] In one alternative approach, an HTTP request can be constructed, encapsulating the system prompts and task descriptions in a format required by the AI ​​model, such as JSON, as the request body. A POST request is then sent to the AI ​​model's server by calling a network request library and setting appropriate request headers. Upon receiving the request, the AI ​​model server parses and processes the data. Internally, natural language processing algorithms are used to identify the intent of the system prompts and task descriptions, yielding the intent recognition result. Then, a database query retrieves pre-defined instructions matching the intent recognition result from a pre-defined instruction database, finally generating an instruction list language based on the pre-defined instructions. Stable and efficient communication with the AI ​​model is achieved through standard HTTP requests and JSON data format. The use of a mature network request library simplifies the development process and ensures accurate data delivery to the model server. The model's internal natural language processing algorithms and database query operations accurately identify intents and retrieve matching instructions, ultimately generating a compliant instruction list language, ensuring accurate textual language information is obtained subsequently.

[0067] In another alternative approach, a message queue such as RabbitMQ can be used to interact with the AI ​​large-scale model. System prompts and task descriptions are encapsulated into messages and sent to a designated message queue. The AI ​​large-scale model server, acting as a consumer, retrieves messages from the message queue, parses them, and performs intent recognition. Internally, an in-memory database such as Redis is used to store a pre-defined instruction database. Redis query commands quickly retrieve the pre-defined instructions that match the intent recognition results and generate an instruction list language. Because message queues offer decoupling, asynchronous processing, and peak shaving capabilities, they improve system stability and response speed. Even under high concurrency, reliable message transmission and processing are guaranteed. Using an in-memory database significantly increases data query speed, reduces model processing time, and thus generates the instruction list language faster, improving overall system performance.

[0068] In the process of generating an instruction list language based on preset instruction content, the aforementioned AI model may encounter multiple matched preset instruction contents. These matched preset instruction contents can be processed to generate the final instruction list language. This processing could involve merging, deleting, or sorting the matched duplicate preset instruction contents to improve the readability of the generated instruction list language.

[0069] (3) The intermediate controller obtains the instruction list language returned by the AI ​​large model.

[0070] In one alternative approach, a callback function or listening mechanism is set when sending a request to the AI ​​large-scale model server. When the AI ​​large-scale model processes the data and returns a response, the callback function is triggered to parse the response data. Based on the format of the response data, the instruction list language contained within is extracted to obtain the instruction list language returned by the AI ​​large-scale model. By setting a callback function or listening mechanism, the results returned by the AI ​​large-scale model can be obtained in a timely manner, avoiding program blocking due to waiting for a response. Accurately parsing the response data and extracting the instruction list language ensures that the obtained textual language information is complete and accurate, providing reliable data support for subsequent use and processing.

[0071] In another alternative approach, the intermediate controller can periodically send query requests to the AI ​​large model server using a polling method to check for processing results. When a result is detected, the returned data is parsed to extract the instruction table language. An appropriate polling interval can be set according to actual needs to balance system performance and response timeliness. Because the polling method is relatively simple to implement, it can guarantee timely acquisition of results to a certain extent. By reasonably setting the polling interval, a balance can be found between system performance and response speed, avoiding excessive server pressure from frequent queries while ensuring timely acquisition of the instruction table language generated by the AI ​​large model.

[0072] In this embodiment, system prompts associated with task description information are obtained; the system prompts and task requirement descriptions are sent to the AI ​​big model, and the instruction list language is generated by using the reasoning ability of the AI ​​big model, thereby improving the generation efficiency of the instruction list language.

[0073] Based on the above, in one feasible implementation, step S32 may include steps S321 to S323: Step S321: Parse the text language to obtain a syntax tree.

[0074] A syntax tree, also known as an abstract syntax tree, is a tree-like representation of the abstract syntactic structure of text language generated by a large AI model. Each node in the tree represents a structure in the source code, such as an expression, statement, or declaration. This tree structure clearly displays the syntactic hierarchy and logical relationships of the text language, facilitating subsequent analysis, processing, and conversion.

[0075] In one alternative approach, the intermediate controller can invoke a corresponding service to parse the text language and obtain a syntax tree. Specifically, a syntax file can be defined first, describing the lexical and grammatical rules of the language. Then, the intermediate controller invokes a dedicated server, which generates corresponding lexical and parsing code based on the defined lexical and grammatical rules. The acquired text language is then input into the generated parser, which constructs a syntax tree according to the grammatical rules. This accurately converts the text language into a syntax tree. By defining detailed grammatical rules, it is ensured that the generated syntax tree accurately reflects the grammatical structure of the text code, providing a reliable foundation for subsequent graphical code processing and conversion, and improving the accuracy of graphical code analysis and processing.

[0076] Step S322: Convert the syntax tree into a graphical element data structure.

[0077] The graphical element data structure is a specific data structure used to store and organize information related to graphics. It defines various basic elements of graphics, such as horizontal lines, vertical lines, normally open contacts, normally closed contacts, coils, and their interrelationships. This provides the data foundation for generating graphical languages, enabling computers to accurately draw the corresponding graphics based on this data. The graphical element data structure here can be a ladder diagram data structure, a function block diagram data structure, or other types of graphical element data structures; no specific limitation is made here.

[0078] In one alternative approach, the intermediate controller can invoke a corresponding service to convert the syntax tree into a graphical element data structure. Specifically, the service performs the following operations: A set of classes or structs for graphical element data structures can be predefined. The nodes of the syntax tree are traversed, and corresponding graphical element objects are created based on the node's type and attributes, populating the object's attributes with the relevant information from the node. Simultaneously, parent-child or reference relationships are established between graphical elements to reflect the hierarchical structure in the syntax tree. By defining well-defined data structure classes, the information of graphical elements can be clearly organized and managed. The process of converting syntax tree nodes into graphical element objects achieves the initial conversion from syntax structure to graphical representation, laying the foundation for subsequent generation of accurate graphical language and ensuring the data integrity and logical correctness of the graphical elements.

[0079] In another alternative approach, the service can use data mapping to create a mapping table that maps node types and attributes in the syntax tree to corresponding fields in the graphical element data structure. When traversing the syntax tree, the mapping table is searched based on the node type to obtain the corresponding graphical element data structure template. Then, the node attribute values ​​are populated into the template to generate the specific graphical element data. Simultaneously, the relationships within the graphical element data structure are adjusted according to the hierarchical relationships in the syntax tree. This data mapping approach is concise, clear, and easy to maintain and extend. When syntax rules or graphical element data structures change, only the mapping table needs modification, reducing the amount of code modification. It can quickly and accurately convert the syntax tree into a graphical element data structure, improving conversion efficiency and code maintainability.

[0080] Step S323: Generate a graphical language based on the graphical element data structure, and display the graphical language in the second area.

[0081] The graphical language used here can be ladder diagram language, function block diagram language, or other types of graphical language, without any specific limitations.

[0082] In one alternative approach, a mapping relationship between different graphical element data structures and their corresponding graphical languages ​​can be pre-established. In practical applications, the intermediate controller can invoke the corresponding service, which can look up the mapping relationship based on the graphical element data structure, obtain the matching graphical language, and feed the matched graphical language back to the intermediate controller. The intermediate controller then returns the graphical language to the second area of ​​the front-end dialog window for display.

[0083] In this embodiment, by first parsing the text language to obtain a syntax tree, then converting the syntax tree into a graphical element data structure, and finally generating graphical language based on the graphical element data structure, a process for converting text language into graphical language can be provided to meet the needs of graphical language generation.

[0084] In one feasible implementation, the text language includes an instruction list language, and step S321 includes: Step S3211: The lexical analysis of the instruction list language is performed by a parsing tool, and the syntax of the instruction list language is parsed to generate a syntax tree; the parsing tool is a functional component of the programmable logic controller's editor.

[0085] The above step S3211 may specifically include: (1) The intermediate controller sends the instruction list language to the parsing tool, which is a functional component of the programmable logic controller's editor. The parsing tool is used to verify the lexical structure of the instruction list language and perform syntax parsing on the instruction list language to generate a syntax tree.

[0086] The parsing tool is a functional component of the programmable logic controller's (PLC) editor. It possesses the capability to perform lexical verification and syntax parsing for specific languages, such as instruction list languages. Lexical verification primarily checks whether words and symbols in the instruction list language conform to the language's lexical rules, such as identifier naming conventions and operator usage. Syntax parsing, based on the language's grammatical rules, converts the instruction list language into a tree-like data structure—a syntax tree—that clearly represents its grammatical structure, facilitating further analysis, processing, and conversion of the instruction list language. This parsing tool communicates with the intermediate controller via an API interface. The intermediate controller can call the parsing tool's API to perform lexical verification and language parsing of the instruction list language, obtaining the syntax tree.

[0087] In one alternative approach, the API interface provided by the PLC editor can be utilized. Specifically, in the development environment, relevant API library files can be imported, and the instruction list language can be encapsulated into a specific data format according to the API documentation specifications. Then, the function in the API used to send the instruction list language to the parsing tool is called to send the data. After receiving the data, the parsing tool processes the instruction list language according to its internal preset lexical check rules and syntax parsing algorithms. Using the API interface ensures compatibility and stability with the PLC editor and its parsing tool, reducing problems caused by interface incompatibility. Through standardized encapsulation and calling, the instruction list language can be accurately passed to the parsing tool, ensuring smooth lexical check and syntax parsing, and improving the accuracy and reliability of data transmission.

[0088] In another alternative approach, a message queue can be set up to send the instruction list language (IL) as message content to a designated queue. The parsing tool, acting as a message consumer, retrieves messages from the queue. When sending a message, the IIL can be encapsulated according to a specific format, including necessary metadata. Upon receiving the message, the parsing tool first parses the message format to extract the IIL, and then performs lexical verification and syntax parsing. Because message queues offer decoupling, asynchronous processing, and peak shaving capabilities, sending IIL via a message queue allows the intermediate controller and parsing tool to operate independently, reducing system coupling. Asynchronous processing improves system response speed and throughput, especially when processing large volumes of IIL, preventing the intermediate controller from being blocked while waiting for parsing results and improving overall system performance.

[0089] The aforementioned parsing tool performs lexical verification on the instruction list language by scanning the instruction list language text character by character and matching the scanned character sequences against predefined regular expressions. If a character sequence matches a regular expression, it is considered to conform to the corresponding lexical rules; otherwise, it is judged as a lexical error.

[0090] The parsing tool described above performs syntax parsing on instruction list languages ​​in the following ways: The parsing tool can use recursive descent parsing to generate a syntax tree. The principle is to start from the top of the syntax tree, i.e., the start symbol, and gradually deduce downwards, attempting to construct a syntax tree that matches the input instruction list language. Recursive descent parsing is a common implementation of top-down parsing; it defines a recursive function for each non-terminal symbol and completes syntax parsing by recursively calling these functions. Specifically, the parsing tool starts execution from the recursive function corresponding to the start symbol, attempting to match the input instruction list language according to the grammar rules within the function. If a match is successful, it continues to call other relevant recursive functions for further derivation; if a match fails, it backtracks to the previous step and tries other matching methods.

[0091] (2) The intermediate controller obtains the syntax tree returned by the parsing tool.

[0092] In one alternative approach, a callback function is set when the parsing tool's API is invoked to send the instruction list language. The parsing tool triggers the callback function after completing lexical verification and syntax parsing and generating a syntax tree. Within the callback function, the returned syntax tree data is parsed and extracted according to the format specified by the parsing tool. For example, if the syntax tree is returned in XML or JSON format, the corresponding parsing library can be used to parse the returned data and obtain the syntax tree's structure and node information. By setting a callback function, the syntax tree returned by the parsing tool can be obtained promptly, avoiding wasted resources due to the program actively polling and waiting for results. The callback function can perform appropriate subsequent processing based on the returned syntax tree results, improving program execution efficiency and response speed. Furthermore, using a dedicated parsing library to parse the returned data ensures accurate extraction of syntax tree information, guaranteeing data integrity and accuracy.

[0093] In another alternative approach, the intermediate controller can periodically send query requests to the parsing tool using a polling method. After sending the instruction list language to the parsing tool, a timer is started, sending query requests at regular intervals, such as every 100 milliseconds, to inquire whether parsing has been completed and a syntax tree has been generated. Upon receiving the query request, the parsing tool, if parsing has been completed, returns the syntax tree data. The receiver then parses and processes the returned data to obtain the syntax tree. The polling method is relatively simple to implement and can, to a certain extent, ensure the timely acquisition of the syntax tree returned by the parsing tool. By reasonably setting the polling interval, a balance can be found between system performance and response timeliness. If the interval is set too short, it will increase the system load; if the interval is set too long, it may lead to untimely results. By continuously adjusting and optimizing the polling interval, the overall system performance and response speed can be improved.

[0094] In this embodiment, the intermediate controller calls the functional components of the programmable logic controller's editor to perform lexical verification and syntax parsing of the instruction list language, generating a syntax tree. This converts the instruction list language into a tree-like data structure that clearly represents its syntactic structure, facilitating further analysis, processing, and conversion of the instruction list language.

[0095] In one feasible implementation, the graphical element data structure includes a ladder diagram data structure, and step S322 includes: Step S3221: Traverse the nodes in the syntax tree using the graphical element management tool; search for matching ladder diagram elements from the preset graphical element database according to the attributes of each node, and generate a ladder diagram data structure based on the connection relationship between the nodes; the graphical element management tool is a functional component of the programmable logic controller's editor.

[0096] The above step S3221 may specifically include: (1) The intermediate controller sends the syntax tree to the graphical element management tool, which is a functional component of the programmable logic controller editor. The graphical element management tool is used to traverse the nodes in the syntax tree; search for matching ladder diagram elements from the preset graphical element database according to the attributes of each node, and generate a ladder diagram data structure according to the connection relationship between the nodes.

[0097] The graphical element management tool is a functional component of the programmable logic controller editor. It is mainly responsible for traversing the syntax tree, searching for the corresponding ladder diagram elements from the preset graphical element database based on the attributes of the syntax tree nodes, and constructing the ladder diagram data structure based on the connection relationship between the nodes, thereby realizing the conversion from the syntax tree to the ladder diagram data structure.

[0098] The preset graphical element database is a database that stores various ladder diagram elements, including but not limited to contacts such as normally open and normally closed contacts, coils such as output coils, set coils, and reset coils, and function instruction boxes such as timer and counter instruction boxes. Each element has its specific attributes, such as function identifiers, which are used to match with syntax tree nodes.

[0099] Ladder diagram elements are the basic units that make up a ladder diagram. In PLC programming, ladder diagrams are a commonly used programming language that mimics the form of relay control circuits. Ladder diagram elements can express various logical control relationships through different combinations and connections. For example, series connection of contacts represents a logical AND relationship, and parallel connection of contacts represents a logical OR relationship.

[0100] In one alternative approach, a message queue can be established to encapsulate the syntax tree data into messages according to a specific message format and then send them to the message queue. The graphical element management tool, acting as a message consumer, retrieves syntax tree messages from the message queue. Internally, the graphical element management tool uses a depth-first search (DFS) or breadth-first search (BFS) algorithm to traverse the nodes of the syntax tree. For each node, its attribute information, such as node type and identifier, is extracted. Then, based on this attribute information, a query is performed in a pre-defined graphical element database to find matching ladder graph elements. Finally, the ladder graph data structure is constructed based on the connections between nodes. Because the message queue decouples the syntax tree's intermediate controller and the graphical element management tool, they become independent of each other, reducing system coupling. Simultaneously, the asynchronous processing mechanism of the message queue improves system response speed and throughput, especially when processing large amounts of syntax tree data, preventing the intermediate controller from being blocked while waiting for the graphical element management tool's processing results. Using a DFS or BFS algorithm efficiently traverses the nodes of the syntax tree, ensuring no node information is missed, thereby accurately finding matching ladder graph elements and constructing the ladder graph data structure.

[0101] In another alternative approach, a remote service interface can be defined. The intermediate controller can call this interface provided by the graphical element management tool, passing the syntax tree as a parameter. Upon receiving the syntax tree, the graphical element management tool traverses its nodes using a recursive algorithm. During this recursion, for each node, a fuzzy match is performed in a pre-defined graphical element database based on its attribute information. For example, regular expressions are used to match node identifiers to find the most suitable ladder diagram element. Then, based on the parent-child and sibling relationships between nodes, the ladder diagram data structure is constructed. The recursive algorithm is a natural and efficient method for traversing tree structures, clearly handling hierarchical relationships between nodes. Fuzzy matching improves the flexibility of the search, adapting to situations where attribute information is not entirely certain, thus more accurately constructing the ladder diagram data structure.

[0102] (2) The intermediate controller obtains the ladder diagram data structure returned by the graphics element management tool, wherein the graphics element data structure includes the ladder diagram data structure.

[0103] The ladder diagram data structure is an internal data organization format used to represent ladder diagrams. It records information such as the position, type, and connection relationships of each element in the ladder diagram. This data structure allows ladder diagrams to be stored, processed, and displayed in computer memory, facilitating programming for users.

[0104] In one alternative approach, a callback function can be set in the intermediate controller when invoking the service of the graphical element management tool. After constructing the ladder diagram data structure, the graphical element management tool calls the callback function with the result as a parameter, returning the ladder diagram data structure to the intermediate controller. The intermediate controller parses and verifies the returned ladder diagram data structure within the callback function to ensure its integrity and correctness. By setting a callback function, the intermediate controller can promptly obtain the processing results from the graphical element management tool, avoiding the waste of system resources caused by actively polling and waiting for results. The callback function can perform subsequent processing immediately after obtaining the results, improving system execution efficiency. Simultaneously, parsing and verifying the returned ladder diagram data structure ensures data accuracy, providing a reliable foundation for subsequent programming, debugging, and monitoring.

[0105] In another alternative approach, after invoking the service of the graphical element management tool, the intermediate controller starts a timer to periodically send query requests to the tool, inquiring whether the ladder diagram data structure has been constructed. Upon receiving the query request, if the construction is complete, the graphical element management tool returns the ladder diagram data structure to the intermediate controller. The intermediate controller then processes the returned data accordingly. This periodic status query method is relatively simple to implement and can ensure timely acquisition of the ladder diagram data structure to a certain extent. By appropriately setting the timer interval, a balance can be found between system performance and responsiveness. Setting the interval too short will increase the system load; setting it too long may lead to untimely results. Continuously adjusting and optimizing the timer interval can improve the overall system performance and response speed.

[0106] In this embodiment, the intermediate controller calls the graphical element management tool in the editor of the programmable logic controller to traverse the syntax tree. Based on the attributes of the syntax tree nodes, it searches for the corresponding ladder diagram elements in the preset graphical element database and constructs a ladder diagram data structure based on the connection relationship between the nodes. This realizes the conversion from syntax tree to ladder diagram data structure and provides a foundation for the subsequent generation of ladder diagram language.

[0107] In one feasible implementation, the graphical element data structure includes a ladder diagram data structure, and the graphical language includes a ladder diagram language; step S323 includes: Step S3231: Generate ladder diagram language based on ladder diagram data structure using a graphical editing tool; the graphical editing tool is a functional component of the programmable logic controller's editor.

[0108] The above step S3231 may specifically include: (1) The intermediate controller sends the ladder diagram data structure to the graphical editing tool, whereby the graphical editing tool is a functional component of the editor of the programmable logic controller. The graphical editing tool is used to generate ladder diagram language based on the ladder diagram data structure.

[0109] The graphical editing tool is a functional component in the editor of the programmable logic controller. It receives ladder diagram data structure as input and, based on the ladder diagram element information recorded in the data structure, such as element type, position, and connection relationship, presents these ladder diagram elements in an intuitive graphical form. Finally, it generates graphical content in ladder diagram language form that users can view, edit, and save, facilitating the writing and debugging of PLC programs.

[0110] In one alternative approach, the graphical editing tool can be developed as a service providing an API interface. When sending the ladder diagram data structure, the intermediate controller encapsulates the ladder diagram data structure into a request body in JSON or XML format according to the interface specification and sends it to the specified API endpoint of the graphical editing tool via the HTTP protocol. After receiving the request, the graphical editing tool parses the ladder diagram data structure in the request body and generates ladder diagram language based on the ladder diagram data structure.

[0111] In another alternative approach, the intermediate controller sends the ladder diagram data structure as a message to a designated queue in the message queue. The graphical editing tool, acting as a message consumer, retrieves the message from the queue, parses the ladder diagram data structure within it, and then generates ladder diagram language based on the data structure. This asynchronous communication method eliminates the need for real-time synchronization between the intermediate controller and the graphical editing tool. The intermediate controller can continue performing other tasks after sending a message, while the graphical editing tool can process the message at an appropriate time.

[0112] The above-mentioned generation of ladder diagram language based on ladder diagram data structure can be achieved by: pre-establishing a mapping relationship between different ladder diagram data structures and their corresponding ladder diagram languages. In practical applications, the mapping relationship is found according to the ladder diagram data structure to obtain the matching ladder diagram language.

[0113] (2) The intermediate controller obtains the ladder diagram language returned by the graphics editing tool.

[0114] Ladder diagram language is a graphical programming language used in PLC programming. It mimics the form of relay control circuits, using ladder diagram elements such as contacts, coils, and function instruction blocks to represent different control logic. Ladder diagram language is intuitive and easy to understand.

[0115] In one alternative approach, the intermediate controller sets a callback function when sending the ladder diagram data structure to the graphical editing tool. After generating the ladder diagram language, the graphical editing tool calls this callback function, passing the generated ladder diagram language as a parameter to the intermediate controller. The intermediate controller then performs further processing on the returned ladder diagram language within the callback function, such as displaying it in the second area of ​​the dialog window. The callback function provides an asynchronous way to obtain results; the intermediate controller does not need to actively poll the graphical editing tool to see if the generation task is complete, but instead waits for the graphical editing tool to notify it, thus improving system efficiency.

[0116] In another alternative approach, after sending the ladder diagram data structure to the graphical editing tool, the intermediate controller starts a timer to periodically send query requests to the tool, inquiring whether the ladder diagram language generation has been completed. Upon receiving the query request, the graphical editing tool returns the ladder diagram language to the intermediate controller if generation is complete; otherwise, it returns the current processing progress information. The intermediate controller then processes the returned information accordingly, such as continuing to wait or prompting the user about the processing progress. This periodic query method is relatively simple to implement and can ensure timely acquisition of the ladder diagram language to a certain extent. By appropriately setting the timer interval, a balance can be found between system performance and responsiveness.

[0117] In this embodiment, the intermediate controller sends the ladder diagram data structure to the graphical editing tool of the programmable logic controller's editor. The graphical editing tool generates ladder diagram language based on the ladder diagram data structure, thereby presenting the ladder diagram elements contained in the ladder diagram data structure in an intuitive graphical form. Finally, it generates graphical content in the form of ladder diagram language that can be viewed, edited, and saved by the user, which facilitates the user's writing and debugging of PLC programs.

[0118] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. On this basis, step S110 can be executed before or after any step S10 to step S30, and step S120 can be executed after step S30. Specifically, steps S110 and S120 include: In step S110, in response to the startup operation of the programmable logic controller's editor, the development interface of the editor is displayed, which includes a graphical language display area.

[0119] The graphical language display area is used to display the generated graphical language.

[0120] It should be noted that, in response to the startup operation of the programmable logic controller's editor, the editor's development interface can be displayed first, followed by the dialog window; or the dialog window can be displayed first, followed by the editor's development interface; or both the editor's development interface and the dialog window can be displayed simultaneously.

[0121] In one alternative approach, such as Figure 3As shown, the editor's development interface and dialog window can be displayed using a split-column layout, which can achieve either left-right or top-bottom splitting. Specifically, window splitting controls such as the split view function can be used to display the editor's development interface on the left side of the current screen and the dialog window on the right; alternatively, the editor's development interface can be displayed on the right side of the current screen and the dialog window on the left; the editor's development interface can be displayed at the top of the current screen and the dialog window at the bottom; or the editor's development interface can be displayed at the bottom of the current screen and the dialog window at the top. After using the split-column layout, the column ratio can be adjusted by dragging to improve the display effect of the dialog window and the editor's development interface. By displaying the dialog window and the editor's development interface simultaneously on the same screen, the need for user navigation is reduced.

[0122] Another alternative approach is to use pop-up embedding technology. The dialog window is designed as a floating pop-up that can be minimized or maximized. The pop-up does not obscure the editor's development interface, such as the code editing area and console, and users can switch between interactive and execution perspectives at any time. Specifically, a shortcut control for the dialog window can be embedded in the editor. Triggering this shortcut control will pop up the dialog window. In this way, the dialog window can be displayed only when needed and hidden when not needed, avoiding any obstruction of the editor's development interface.

[0123] Step S120: Obtain the graphical language of the second region and display the graphical language in the graphical language display area.

[0124] After the graphical language is displayed in the second area, the image language of the second area can be obtained. The graphical language can be displayed automatically in the graphical language display area, or it can be displayed in the image language display area in response to a trigger operation or drag operation.

[0125] In this embodiment, after the intelligent assistant generates the graphical language, the graphical language generated by the intelligent assistant is displayed in the graphical language display area of ​​the programmable logic controller's editor, realizing the process from generation to use of the graphical language and providing convenience for the use of the graphical language.

[0126] In one feasible implementation, step S120 includes: acquiring the graphical language in response to a triggering operation of a control associated with the graphical language; and displaying the graphical language in the graphical language display area in response to a triggering operation of a second control on the development interface.

[0127] In one alternative approach, after displaying the graphical language in the second area, the associated control can also be displayed simultaneously. Triggering this control allows the graphical language to be copied, achieving the purpose of acquiring the graphical language. Triggering the second control in the development interface allows the graphical language to be copied to the graphical language display area of ​​the editor. This enables convenient interaction between the intelligent assistant and the PLC editor, realizing the generation and use of the graphical language.

[0128] In this embodiment, by providing copy and paste functions for graphical language, the process from generating to using graphical language is realized, thus facilitating the use of graphical language.

[0129] In another feasible implementation, step S120, displaying the graphical language in the graphical language display area, may further include: in response to a drag operation of the graphical language, dragging the graphical language in the second area; and when the graphical language is dragged from the second area to the graphical language display area, in response to a release operation corresponding to the drag operation, displaying the graphical language in the graphical language display area.

[0130] In one alternative approach, after displaying the graphical language in the second area, the area containing the graphical language can be selected, and the graphical language displayed in the second area can be dragged and dropped into the graphical language display area of ​​the development interface. Once the graphical language is in the development interface, a release operation is performed to display the graphical language in the graphical language display area. The dragging and releasing operations can be determined by detecting mouse events. This enables convenient interaction between the intelligent assistant and the PLC editor, realizing the generation and use of graphical language.

[0131] In this embodiment, by providing a drag-and-drop function for the graphical language, the graphical language can be quickly dragged from the second area to the graphical language display interface of the development interface, thereby improving the efficiency of using the graphical language.

[0132] In other embodiments, the AI ​​large model, parsing tool, graphics element management tool, graphics editing tool, and programmable logic controller editor described above can not only use an intermediate controller for data forwarding and retrieval, but also directly communicate with each other. For example, refer to... Figure 4 In the second area of ​​the front end (corresponding to) Figure 4 After entering the task requirement description in the question-and-answer input box, the AI ​​large model generates text language (corresponding to...). Figure 4 (② in the text) is parsed by a parsing tool to obtain the syntax tree (corresponding to...) Figure 4 (③) Generates the graphic element data structure (corresponding to) through the graphic element management tool. Figure 4 (④ in the text) generates a graphical language (corresponding to) through graphical editing tools. Figure 4(⑤) The graphic editing tool can directly send the generated graphic language to the second area of ​​the smart assistant's front end for display, or display it directly on the graphic language display area of ​​the editor. This method can further improve the efficiency of graphic language generation and use.

[0133] In other embodiments, the interfaces of the editor's functional components can be directly provided to the AI ​​model. After receiving the task requirement description information, the AI ​​model calls these interfaces to directly generate graphical language without generating intermediate text language. In this case, the AI ​​model can be pre-trained or fine-tuned using task requirement description information samples and graphical language samples, enabling graphical language generation. Although this method allows the AI ​​model to directly generate graphical language, the training cost and difficulty are high due to the complexity of graphical language generation rules.

[0134] For example, to help understand the implementation flow of the graphical language generation method obtained by combining this embodiment with the above embodiments, please refer to... Figure 5 and Figure 6 , Figure 5 This is a schematic diagram of the architecture of the PLC editor and intelligent assistant in this application. Figure 6 An interactive flowchart illustrating a method for generating a graphical language is provided, specifically: In response to the startup operation of the programmable logic controller's editor, the editor's development interface and dialog window are displayed. The development interface includes a graphical language display area, and the dialog window includes a first area, a second area, and a first control.

[0135] Step S20: Based on the first region, receive task requirement description information.

[0136] In step S311, in response to the triggering operation of the first control, the AI ​​big model parses the task requirement description information and the system prompt information associated with the task requirement description information to obtain the intent recognition result; based on the preset instruction content that matches the intent recognition result, an instruction table language is generated, and the preset instruction content is stored in the preset instruction database.

[0137] Step S3211: The lexical analysis of the instruction list language is performed by a parsing tool, and the syntax of the instruction list language is parsed to generate a syntax tree; the parsing tool is a functional component of the programmable logic controller's editor.

[0138] Step S3221: Traverse the nodes in the syntax tree using the graphical element management tool; search for matching ladder diagram elements from the preset graphical element database according to the attributes of each node, and generate a ladder diagram data structure based on the connection relationship between the nodes; the graphical element management tool is a functional component of the programmable logic controller's editor.

[0139] Step S3231: Generate ladder diagram language based on ladder diagram data structure using a graphical editing tool; the graphical editing tool is a functional component of the programmable logic controller's editor.

[0140] Step S120: Obtain the graphical language of the second region and display the graphical language in the graphical language display area.

[0141] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the graphical language generation method of this application. Any simple transformations based on this technical concept are all within the protection scope of this application.

[0142] Based on the same inventive concept, this application also provides a graphical language generation device, please refer to... Figure 7 The graphical language generation device includes: The first display module 10 is used to display a dialog window in response to the startup operation of the editor of the programmable logic controller, wherein the dialog window includes a first area, a second area and a first control; The receiving module 20 is used to receive task requirement description information based on the first region; The second display module 30 is used to display a graphical language generated based on the task requirement description information in the second area in response to the triggering operation of the first control.

[0143] In one embodiment, the second display module 30 is further configured to, in response to the triggering operation of the first control, generate text language based on the AI ​​large model and task requirement description information, and display the text language in the second area; generate graphical language based on the text language, and display the graphical language in the second display area.

[0144] In one embodiment, the second display module 30 is further configured to parse the text language to obtain a syntax tree; convert the syntax tree into a graphical element data structure; generate graphical language based on the graphical element data structure; and display the graphical language in a second area.

[0145] In one embodiment, the text language includes an instruction list language. The second display module 30 is also used to respond to the triggering operation of the first control. The AI ​​big model parses the task requirement description information and the system prompt information associated with the task requirement description information to obtain the intent recognition result. An instruction list language is generated based on the preset instruction content that matches the intent recognition result. The preset instruction content is stored in a preset instruction database.

[0146] In one embodiment, the text language includes an instruction list language. The second display module 30 is also used to verify the lexical structure of the instruction list language using a parsing tool, and to perform syntactic parsing on the instruction list language to generate a syntax tree. The parsing tool is a functional component of the programmable logic controller's editor.

[0147] In one embodiment, the graphical element data structure includes a ladder diagram data structure and a second display module 30, which is also used to traverse the nodes in the syntax tree through a graphical element management tool; search for matching ladder diagram elements from a preset graphical element database according to the attributes of each node, and generate a ladder diagram data structure according to the connection relationship between the nodes; the graphical element management tool is a functional component of the editor of the programmable logic controller.

[0148] In one embodiment, the graphical element data structure includes a ladder diagram data structure, and the graphical language includes a ladder diagram language; the second display module 30 is further configured to generate a ladder diagram language based on the ladder diagram data structure using a graphical editing tool; the graphical editing tool is a functional component of the editor of a programmable logic controller.

[0149] In one embodiment, the device further includes a third display module, configured to display the development interface of the editor in response to the startup operation of the programmable logic controller's editor, the development interface including a graphical language display area; acquire the graphical language of the second area, and display the graphical language in the graphical language display area.

[0150] In one embodiment, the third display module is further configured to acquire the graphical language in response to a triggering operation of a control associated with the graphical language; and to display the graphical language in the graphical language display area in response to a triggering operation of a second control on the development interface.

[0151] In one embodiment, the third display module is further configured to drag the graphical language of the second area in response to the drag operation of the graphical language; and to display the graphical language in the graphical language display area in response to the release operation corresponding to the drag operation when the graphical language is dragged from the second area to the graphical language display area.

[0152] The graphical language generation apparatus provided in this application, employing the graphical language generation method described in the above embodiments, can improve the development efficiency and shorten the development cycle of PLC graphical languages. Compared with the prior art, the beneficial effects of the graphical language generation apparatus provided in this application are the same as those of the graphical language generation method provided in the above embodiments, and other technical features in the graphical language generation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0153] Based on the same inventive concept, this application provides a graphical language generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the graphical language generation method in the above embodiments.

[0154] The graphical language generation device provided in this application, employing the graphical language generation method in the above embodiments, can improve the development efficiency of PLC graphical languages ​​and shorten the development cycle of PLC graphical languages. Compared with the prior art, the beneficial effects of the graphical language generation device provided in this application are the same as those of the graphical language generation method provided in the above embodiments, and other technical features in this graphical language generation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0155] Based on the same inventive concept, this application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, which are used to execute the graphical language generation method in the above embodiments.

[0156] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0157] The aforementioned computer-readable storage medium may be included in the graphical language generating device; or it may exist independently and not assembled into the graphical language generating device.

[0158] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by a graphical language generation device, the graphical language generation device can improve the development efficiency of the PLC's graphical language and shorten the development cycle of the PLC's graphical language.

[0159] 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++, as well as 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 can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0160] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0161] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0162] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described graphical language generation method. This improves the development efficiency of PLC graphical languages ​​and shortens the development cycle of PLC graphical languages. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the graphical language generation method provided in the above embodiments, and will not be repeated here.

[0163] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for generating a graphical language, characterized in that, The method includes: In response to the startup operation of the programmable logic controller's editor, a dialog window is displayed, wherein the dialog window includes a first area, a second area, and a first control; Based on the first region, receive task requirement description information; In response to the triggering operation of the first control, a graphical language generated based on the task requirement description information is displayed in the second area.

2. The method for generating graphical language as described in claim 1, characterized in that, In response to the triggering operation of the first control, displaying the graphical language generated based on the task requirement description information in the second area includes: In response to the triggering operation of the first control, text language is generated based on the AI ​​big model and the task requirement description information, and the text language is displayed in the second area; A graphical language is generated based on the text language, and the graphical language is displayed in the second display area.

3. The method for generating graphical language as described in claim 2, characterized in that, The step of generating a graphical language based on the textual language and displaying the graphical language in the second display area includes: The text language is parsed to obtain a syntax tree; The syntax tree is converted into a graphical element data structure; Based on the graphical element data structure, a graphical language is generated and displayed in the second area.

4. The method for generating graphical language as described in claim 2, characterized in that, The text language includes an instruction list language, and the generation of the text language based on the AI ​​big model and the task requirement description information in response to the triggering operation of the first control includes: In response to the triggering operation of the first control, the AI ​​big model parses the task requirement description information and the system prompt information associated with the task requirement description information to obtain the intent recognition result; and generates the instruction table language based on the preset instruction content that matches the intent recognition result, and the preset instruction content is stored in the preset instruction database.

5. The method for generating graphical language as described in claim 3, characterized in that, The text language includes an instruction list language, and the parsing of the text language to obtain a syntax tree includes: The lexical analysis of the instruction list language is performed by a parsing tool, and the syntax of the instruction list language is parsed to generate the syntax tree; the parsing tool is a functional component of the editor of the programmable logic controller.

6. The method for generating graphical language as described in claim 3, characterized in that, The graphical element data structure includes a ladder diagram data structure, and the step of converting the syntax tree into a graphical element data structure includes: The nodes in the syntax tree are traversed using a graphical element management tool; matching ladder diagram elements are searched from a preset graphical element database based on the attributes of each node, and the ladder diagram data structure is generated based on the connection relationships between the nodes; the graphical element management tool is a functional component of the editor of the programmable logic controller.

7. The method for generating graphical language as described in claim 3, characterized in that, The graphical element data structure includes a ladder diagram data structure, and the graphical language includes a ladder diagram language; generating the graphical language based on the graphical element data structure includes: The ladder diagram language is generated based on the ladder diagram data structure using a graphical editing tool; the graphical editing tool is a functional component of the editor of the programmable logic controller.

8. The method for generating a graphical language as described in claim 1, characterized in that, The method for generating the graphical language also includes: In response to the startup operation of the programmable logic controller's editor, the development interface of the editor is displayed, the development interface including a graphical language display area; Obtain the graphical language of the second region and display the graphical language in the graphical language display area.

9. The method for generating a graphical language as described in claim 8, characterized in that, The step of acquiring the graphical language of the second region and displaying the graphical language in the graphical language display area includes: In response to a triggering operation of a control associated with the graphical language, the graphical language is obtained; In response to the triggering operation of the second control in the development interface, the graphical language is displayed in the graphical language display area.

10. The method for generating a graphical language as described in claim 8, characterized in that, Displaying the graphical language in the graphical language display area includes: In response to the drag operation of the graphical language, drag the graphical language of the second area; When the graphical language is dragged from the second area to the graphical language display area, the graphical language is displayed in the graphical language display area in response to the release operation corresponding to the drag operation.

11. A graphical language generation device, characterized in that, The device includes: The first display module is used to display a dialog window in response to the startup operation of the editor of the programmable logic controller, wherein the dialog window includes a first area, a second area, and a first control; The receiving module is used to receive task requirement description information based on the first region; The second display module is used to respond to the triggering operation of the first control and display the graphical language generated based on the task requirement description information in the second area.

12. A graphical language generation device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the method for generating a graphical language as claimed in any one of claims 1 to 10.

13. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the graphical language generation method as described in any one of claims 1 to 10.

Images