Synchronous debugging method and device for control logic and equipment model and computer equipment

Abstract

The invention relates to a control logic and equipment model synchronous debugging method and device and computer equipment, and relates to the technical field of industrial automation control and simulation. The method comprises the following steps: receiving and responding to a debugging instruction, compiling a to-be-debugged logic control program to obtain compiled control logic, and displaying and rendering a to-be-debugged equipment model; executing the compiled control logic every preset scanning period, and updating the variable state of the variable of the compiled control logic; and in each rendering frame, on the basis of a pre-established shared variable table, determining a variable of a control logic associated with a driving parameter of the to-be-debugged equipment model, reading a newest variable state of the associated variable, and driving the to-be-debugged equipment model on the basis of the newest variable state, the shared variable table is a variable table of an incidence relation between variables of the control logic and driving parameters of the equipment model. By adopting the method, the debugging efficiency of the control logic and the equipment model of the industrial automation system can be improved.

Description

Technical Field

[0001] This application relates to the field of industrial automation control and simulation technology, and in particular to a method for synchronous debugging of control logic and equipment models, a device for synchronous debugging of control logic and equipment models, computer equipment, computer-readable storage media, and computer program products. Background Technology

[0002] With the development of automation control technology, industrial automation systems have been widely used in the industrial field. These systems use control logic to achieve automatic control, monitoring, and management of industrial production processes, reducing manual intervention and improving production efficiency. However, in the development of industrial automation systems, especially in intelligent manufacturing and digital production lines, the writing of control logic (such as PLC (Programmable Logic Controller) programs) and the debugging of equipment mechanical structures are often separated. Control engineers use dedicated programming software to write logic programs such as FBD (Function Block Diagram) or SFC (Sequential Function Chart), while mechanical or simulation engineers use 3D design software and simulation platforms to build 3D models of the equipment and create animations. This heterogeneous software environment leads to a disconnect between the debugging of control logic and the simulation verification of the equipment model, resulting in low debugging efficiency. Summary of the Invention

[0003] Based on this, it is necessary to provide a synchronous debugging method for control logic and device model, a synchronous debugging device for control logic and device model, a computer device, a computer-readable storage medium, and a computer program product that can improve the efficiency of adjustment and debugging, in order to address the above-mentioned technical problems.

[0004] Firstly, this application provides a method for synchronously debugging control logic and a device model, the method comprising:

[0005] Receive and respond to debugging commands, compile the logic control program to be debugged, obtain the compiled control logic, and display and render the device model to be debugged;

[0006] At each preset scan cycle, the compiled control logic is executed, and the variable state of the compiled control logic variables is updated;

[0007] In each rendering frame, based on a pre-established shared variable table, the variables of the control logic associated with the driving parameters of the device model to be debugged are determined, the latest variable state of the associated variables is read, and the device model to be debugged is driven based on the latest variable state. The shared variable table is a variable table that shows the relationship between the variables of the control logic and the driving parameters of the device model.

[0008] In some embodiments, the method further includes:

[0009] Receive and respond to operation commands on the displayed device model to be debugged, and drive the device model to be debugged to perform the driving action corresponding to the operation command;

[0010] Retrieve the updated driver parameters corresponding to the driver action;

[0011] Based on a pre-established shared variable table, the variable state of the compiled control logic variables is updated by updating the updated driver parameters.

[0012] In some embodiments, the method further includes:

[0013] In response to a debugging command, the logic control program to be debugged is displayed in the first display area, and the device model to be debugged is displayed in the second display area.

[0014] In some embodiments, the method further includes:

[0015] During the execution of the compiled control logic, the currently activated functional module in the logic control program to be debugged is displayed with a first display effect, and the functional modules other than the currently activated functional module are displayed with a second display effect. The visual appeal of the second display effect is less than that of the first display effect.

[0016] In some embodiments, the method further includes:

[0017] By using the control thread in the synchronous execution engine, the compiled control logic is executed at preset scan intervals, and the variable state of the compiled control logic variables is updated.

[0018] By using the rendering engine in the synchronous execution engine, in each rendering frame, based on a pre-established shared variable table, the variables of the control logic associated with the driving parameters of the device model to be debugged are determined, the latest variable state of the associated variables is read, and the device model to be debugged is driven based on the latest variable state.

[0019] In some embodiments, the device model to be debugged includes a button control, and the operation instructions include a click instruction on the button control.

[0020] In some embodiments, the device model to be debugged includes a virtual workpiece; the operation instructions include position adjustment operations on the virtual workpiece.

[0021] Secondly, this application also provides a device for synchronously debugging control logic and a device model, comprising:

[0022] The instruction triggering module is used to receive and respond to debugging instructions, compile the logic control program to be debugged, obtain the compiled control logic, and display and render the device model to be debugged.

[0023] The logic debugging module is used to execute the compiled control logic at preset scan intervals and update the variable state of the compiled control logic variables.

[0024] The device model debugging module is used in each rendering frame to determine the variables of the control logic associated with the driving parameters of the device model to be debugged, based on a pre-established shared variable table, read the latest variable state of the associated variables, and drive the device model to be debugged based on the latest variable state. The shared variable table is a variable table that shows the relationship between the variables of the control logic and the driving parameters of the device model.

[0025] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the remote photoplethysmography signal detection method of any of the above embodiments.

[0026] Fourthly, this application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the remote photoplethysmography signal detection method of any of the above embodiments.

[0027] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the remote photoplethysmography signal detection method of any of the above embodiments.

[0028] The aforementioned method, apparatus, computer equipment, computer-readable storage medium, and computer program product for synchronous debugging of control logic and device model, upon receiving a debugging instruction, compiles the control program of the logic to be debugged to obtain the compiled control logic. Simultaneously, it displays and shows the corresponding device model to be debugged. At preset scan intervals, it executes the compiled control logic, updates the variable states of the compiled control logic's variables, and thus debugs the control logic. Furthermore, when rendering and updating the device model to be debugged in each rendering frame, it reads the variables of the control logic associated with the driving parameters of the device model to be debugged based on a pre-established shared variable table. The latest variable state is used to drive the device model under test. This allows the device model under test to be driven based on the latest variable state after the variable state of the compiled control logic is updated in each scan cycle. This enables synchronous debugging of the control logic and the device model. Furthermore, after the variable state of the control logic is updated, the device model under test can be driven and updated based on the shared variable table. This eliminates the need to switch back and forth between the control logic program and the device model during debugging, greatly improving the debugging efficiency of the control logic and device model of the industrial automation system. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is an application environment diagram of a synchronous debugging method for control logic and device model in one embodiment;

[0031] Figure 2 This is a flowchart illustrating a method for synchronously debugging control logic and a device model in one embodiment.

[0032] Figure 3 This is a flowchart illustrating the synchronous debugging steps of the control logic and the device model in another embodiment;

[0033] Figure 4 This is a flowchart illustrating the synchronous debugging method of control logic and device model in another embodiment;

[0034] Figure 5 This is a schematic diagram of the architecture of a method for synchronously debugging control logic and device model in a specific example.

[0035] Figure 6This is a structural block diagram of a device for synchronously debugging control logic and a device model in one embodiment;

[0036] Figure 7 This is an internal structure diagram of one embodiment;

[0037] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0039] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0040] It should be noted that all information and data involved in this application (including but not limited to data used for analysis, stored data, and displayed data) are information and data authorized by the user or fully authorized by all parties, and the acquisition, transmission, storage, use, and processing of related data comply with the relevant provisions of national laws and regulations. Users can refuse content pushed to them or can easily refuse content pushes. In the embodiments of this application, certain existing solutions in the industry, such as software, components, and models, may be mentioned. These should be considered exemplary, and their purpose is merely to illustrate the feasibility of implementing the technical solution of this application, but does not mean that the applicant has already used or necessarily used such a solution.

[0041] Currently, when debugging the control logic and equipment models of industrial automation systems, the heterogeneous software environments of the control logic and equipment lead to a lengthy and costly "design-programming-physical debugging" cycle. During debugging, the control logic program must be fully tested on a real PLC and physical equipment. If the control logic program contains logical errors or does not match the mechanical actions, it is necessary to repeatedly modify the program, download it to the PLC, and test it on the physical equipment. This process is cumbersome, has a long debugging cycle, is costly, and poses safety risks.

[0042] Research has revealed that when controlling physical devices through control logic programs, the variables set in the control logic are essentially correlated with the device's drive parameters. Therefore, by establishing a binding relationship between the control logic variables and the device model's drive parameters, the control logic program and the device model can share a variable table. This allows the device model to be driven synchronously during the execution of the control logic, thereby changing the device model's drive state. Furthermore, this enables synchronized and integrated debugging of the control logic and the device model, improving debugging efficiency and avoiding the repeated switching between the control logic and the device.

[0043] The synchronous debugging method for control logic and device model provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, the application environment may involve only terminal 10, or it may involve both terminal 10 and server 20. Terminal 10 communicates with server 20 via a network, and the data storage system can store the data to be processed. The data storage system can be integrated on terminal 10, integrated on server 20, or placed in the cloud or on other network servers.

[0044] The control logic 101 and the device model 102 to be debugged can be deployed on terminal 10 or uploaded to server 20 via terminal 10. An integrated debugging platform can be deployed on terminal 10 or server 20, and synchronous debugging of the control logic 101 and the device model 102 can be performed through the integrated debugging platform. In some examples, terminal 10 can use cloud desktops provided by server 20, and synchronous debugging of the control logic 101 and the device model 102 can be achieved through the cooperation of terminal 10 and server 20.

[0045] Terminal 10 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 20 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0046] In one exemplary embodiment, such as Figure 2As shown, a method for synchronous debugging of control logic and device model is provided, which can be applied to... Figure 1 Taking terminal 10 or server 20 as an example, the explanation includes the following steps S201 to S203. Wherein:

[0047] Step S201: Receive and respond to the debugging command, compile the logic control program to be debugged, obtain the compiled control logic, and display and render the device model to be debugged.

[0048] Debugging commands are instructions used to instruct and trigger debugging. In some examples, debugging controls can be set on the interface of the debugging platform. Debugging commands can be issued by operating these controls, such as clicking them, and the receipt of a click on the control confirms the receipt of the debugging command. In other examples, shortcut keys corresponding to debugging commands can be set. These shortcut keys can be combinations of two or more keys, and the receipt of these shortcut keys confirms the receipt of the debugging command. In still other examples, the debugging platform can integrate a voice input control, and the receipt of a corresponding voice command (such as "Start Debugging," "Start Synchronous Debugging," etc.) through the voice input control confirms the receipt of the debugging command. This application does not impose specific limitations on the method of triggering debugging commands.

[0049] Compiling the logic control program to be debugged refers to the crucial process of converting the program into machine code that a computer can directly understand and execute. The specific method for compiling the logic control program can employ existing compilation methods in related technologies, and this application does not impose specific limitations on this method. In this application embodiment, the machine code obtained after compiling the logic control program to be debugged is referred to as the encoded control logic.

[0050] Displaying and rendering the device model to be debugged refers to the process of converting the device model to be debugged into a two-dimensional image and displaying it on a monitor. The specific method of displaying and rendering the device model to be debugged can be the same as the method of displaying and rendering three-dimensional models in related technologies. This application does not specifically limit this method.

[0051] Step S202: At each preset scan cycle, execute the compiled control logic and update the variable state of the compiled control logic variables.

[0052] The preset scan cycle refers to the time period during which the control logic completes one full work cycle. It can be determined based on the time of the three stages: input sampling, program execution, and output refresh. Therefore, at each preset scan cycle interval, the compiled control logic will execute a new work cycle, thereby synchronously updating the variable states of the variables extended to the compiled logic.

[0053] Variables, as the core of control logic, represent different data storage locations and functions, serving as a bridge connecting external devices and internal programs. Different variables can have different types and meanings. For example, variables in some examples may include input variables, output variables, intermediate variables, data variables, timer variables, counter variables, travel distance variables, rotation angle variables, etc. The specific variables may vary depending on the needs of different industrial automation systems.

[0054] It is understandable that, when the preset scanning cycle is reached, the execution of the post-compiled control logic will cause changes in the variable state (e.g., the specific value of the variable) of the relevant variables, thereby updating the variable state of the post-compiled control logic.

[0055] Step S203: In each rendering frame, based on the pre-established shared variable table, determine the variables of the control logic associated with the driving parameters of the device model to be debugged, read the latest variable state of the associated variables, and drive the device model to be debugged based on the latest variable state. The shared variable table is a variable table that shows the relationship between the variables of the control logic and the driving parameters of the device model.

[0056] During the display and rendering of the device model to be debugged, multiple different display frames are generated and displayed every second. Based on the continuous display frames, a visual effect of changes in the device model to be debugged is produced. Therefore, in each rendering frame, an independent two-dimensional image is generated for display. This allows the latest variable state of the associated variables to be obtained based on the rendering frame, thereby driving the device model to be debugged and updating its model state.

[0057] A pre-established shared variable table refers to a table that establishes the association between variables in the control logic and the driving parameters of the device model. This table includes all variables in the control logic to be debugged, as well as all driving parameters of the device model. The variables in the control logic reflect the control of the device's relevant driving parameters during logic control; therefore, a corresponding relationship exists between the control logic variables and the device's driving parameters. By establishing this shared variable table, the variables in the control logic and the driving parameters of the device model are bound together. Therefore, when the state of a variable in the control logic (such as its specific value) is updated, the associated driving parameters of the device model to be debugged can be synchronously determined based on this bound shared variable table. Thus, the latest variable state can be used as the new driving parameters for the device model to be debugged, thereby synchronously achieving the debugging of the device model.

[0058] The method of pre-establishing a shared variable table is not limited. In some examples, it can be for the control logic program that has been written, sorting out the variables defined in the control logic program, and for the created equipment model, defining the actions (such as displacement, rotation, etc.) and corresponding driving parameters (such as target position, moving speed, etc.) of the movable parts (such as cylinders, motors, conveyor belts, etc.) of the equipment model, and associating the sorted variables and the defined driving parameters to obtain the shared variable table.

[0059] In the relevant embodiments of this application, a shared variable table can be created and maintained first. Variables that need to be defined in the control logic program and driving parameters that need to be defined in the device model scenario can be maintained and set in this shared variable table. The association between variables and driving parameters is established to obtain the shared variable table. Based on the established shared variable table, a complete control logic program is written in a logic editor or similar environment. The actions and corresponding driving parameters of the movable parts of the device model are defined based on the shared variable table. This ensures data definition consistency from the source, laying the foundation for subsequent association and binding. When writing the control logic program and defining driving parameters for the device model, the variables in the logic program can be bidirectionally bound to the driving parameters of the model through the shared variable table and the names of the actions in the device model.

[0060] The synchronous debugging method for control logic and device model based on this embodiment, upon receiving a debugging instruction, compiles the control program of the logic to be debugged to obtain the compiled control logic, and simultaneously displays and shows the corresponding device model to be debugged. At preset scan intervals, it executes the compiled control logic, updates the variable states of the variables in the compiled control logic, and achieves debugging of the control logic. Furthermore, when the device model to be debugged is rendered and updated in each rendering frame, it reads the latest variable states of the control logic variables associated with the driving parameters of the device model to be debugged based on a pre-established shared variable table, and uses the latest variable states to drive the device model to be debugged. This ensures that after updating the variable states of the compiled control logic variables in each scan cycle, the device model to be debugged can be driven based on the latest variable states when rendering the device model in the rendering frame, thereby achieving synchronous debugging of the control logic and device model. Moreover, after updating the variable states of the control logic variables, the device model to be debugged can be driven and updated based on the shared variable table, eliminating the need to switch back and forth between the control logic program and the device model during debugging, greatly improving the debugging efficiency of the control logic and device model of the industrial automation system.

[0061] In some embodiments, reference Figure 3 As shown, the method in this application embodiment further includes:

[0062] Step S301: Receive and respond to the operation command on the displayed device model to be debugged, and drive the device model to be debugged to perform the driving action corresponding to the operation command.

[0063] An operation instruction is an instruction to operate on the device model to be displayed and debugged. In the relevant embodiments of this application, the operation instruction may be an instruction that can trigger the device model to change its device state or execute related driving actions.

[0064] There are no restrictions on how to obtain operation instructions. The settings can be based on the device type of the device model to be debugged. The following are just two examples.

[0065] In some embodiments, the device model to be debugged includes a button control, and the operation instructions include a click instruction on the button control.

[0066] In the device model under test, a button control refers to a component that can control the on / off state. For example, some examples of button controls include normally open contacts representing the normally open state and normally closed contacts representing the normally closed state, but are not limited to this.

[0067] In some embodiments, the device model to be debugged includes a virtual workpiece; the operation instructions include position adjustment operations on the virtual workpiece.

[0068] The virtual workpiece in the equipment model to be debugged is a digital entity corresponding to the real workpiece. In different industrial automation systems, different virtual workpieces can have different functions, such as carrying the results of processing and measurement, driving the simulation process to support decision-making, etc., but are not limited to these.

[0069] For example, some examples include virtual workpieces that are obscured. In the presence of a photoelectric sensor, the position of the obscured workpiece can be moved by a position adjustment operation, thereby changing the input variable of the photoelectric sensor (the light intensity changes), which in turn causes the output value of the photoelectric sensor to change.

[0070] It is understood that the device model to be debugged can be equipped with various related components that can receive operation commands to trigger changes in the drive state. Depending on the different industrial automation systems and the different devices in the industrial automation systems, there may be different related components. This application embodiment does not show them in detail.

[0071] Step S302: Obtain the updated driver parameters corresponding to the driver action.

[0072] Upon receiving an operation command for the displayed device model to be debugged, and driving the device model to execute the corresponding driving action, the updated driving parameters corresponding to the threshold will change, thus obtaining the updated driving parameters. Taking the normally open contact as an example, operating the normally open contact will change the driving parameters of the normally open contact from the open state to the closed state. In the case where the position of the workpiece being moved by the position adjustment operation, obstructing the photoelectric sensor, the light intensity detected by the photoelectric sensor will change.

[0073] Step S303: Based on the pre-established shared variable table, update the variable state of the compiled control logic variables by updating the updated driver parameters.

[0074] By establishing a shared variable table that links the variables of the control logic to the driving parameters of the device model, the variables of the control logic and the driving parameters of the device model are bound together. Therefore, when the driving parameters of the device model are updated, the variables of the control logic to be debugged can be determined synchronously based on the bound shared variable table. Thus, the variable state of the compiled control logic can be updated synchronously with the updated driving parameters.

[0075] Based on this embodiment, the solution can also operate on the displayed and rendered device model to be debugged. Based on this operation and a pre-established shared variable table, the variable states of the control logic can be updated synchronously, achieving bidirectional interaction between control logic variable updates and device model simulation debugging. This further improves the debugging efficiency of the control logic and device model in industrial automation systems. For example, when the control logic and the device actions of the 3D device model are inconsistent, engineers do not need to switch back and forth between programming and simulation software to compare variable states with model postures. They can directly observe the control logic and device model synchronously, which helps to quickly and intuitively locate whether the problem stems from a control logic error or a model animation configuration error, thus facilitating rapid troubleshooting.

[0076] In some embodiments, the method of this application further includes:

[0077] In response to a debugging command, the logic control program to be debugged is displayed in the first display area, and the device model to be debugged is displayed in the second display area.

[0078] The first display area is used to display the program code of the logic control program to be debugged during debugging, and the second display area is used to display the model of the device to be debugged during debugging. The positions of the first and second display areas are not limited. For example, the first display area can be located on the left or right side of the display screen, and the second display area can be located on the right or left side of the display screen. As another example, the first display area can be located on the top or bottom side of the display screen, and the second display area can be located on the bottom or top side of the display screen.

[0079] The first display area for displaying the logic control program to be debugged and the second display area for displaying the device model to be debugged can be fixed or adjusted as needed. For example, the positions of the first and second display areas on the screen can be adjusted by dragging the interface window displaying the logic control program to be debugged or the interface window displaying the device model to be debugged.

[0080] The sizes of the first and second display areas are not limited. In some examples, the sizes of the first and second display areas can be the same, or they can be adjusted as needed. For example, the size of the first display area displaying the logic control program to be debugged can be adjusted by scaling the interface window displaying the logic control program to be debugged, and the size of the second display area displaying the device model to be debugged can be adjusted by scaling the interface window displaying the device model to be debugged.

[0081] Specifically, when scaling the interface window displaying the logic control program to be debugged, and adjusting the size of the first display area displaying the logic control program (e.g., shrinking / enlarging), the size of the interface window displaying the device model to be debugged can remain unchanged, or the interface window displaying the device model can be simultaneously adjusted in the opposite way (e.g., enlarged). Similarly, when scaling the interface window displaying the device model to be debugged to adjust the size of the second display area displaying the device model (e.g., shrinking), the interface window displaying the device model to be debugged can remain unchanged, or the interface window displaying the device model can be simultaneously adjusted in the opposite way (e.g., enlarged).

[0082] Understandably, in some examples, the interface window displaying the logic control program to be debugged or the interface window displaying the device model to be debugged can be displayed in full screen via the interface zoom command, which helps to observe the details of the logic control program or the device model to be debugged.

[0083] Based on the solution of this embodiment, in response to the debugging command, the logic control program to be debugged is also displayed in the first display area, and the device model to be debugged is displayed in the second display area. This allows the logic control program to be debugged and the device model to be debugged to be displayed simultaneously in different areas of the display screen, enabling the logic control program to be debugged and the device model to be debugged to be viewed simultaneously, which helps to improve the visualization performance of synchronous debugging.

[0084] In some embodiments, reference Figure 4 As shown, the method also includes:

[0085] Step S401: During the execution of the compiled control logic, the currently activated functional module in the logic control program to be debugged is displayed with a first display effect, and the functional modules other than the currently activated functional module are displayed with a second display effect, wherein the visual appeal of the second display effect is less than that of the first display effect.

[0086] The currently activated functional module in the logic control program to be debugged refers to the module that has control, is being executed, or is scheduled to run during the current scan cycle or control state. This module typically generates valid output to the outside. The method for determining the currently activated functional module is not limited; existing methods in related technologies can be used, and this application embodiment does not specifically limit this approach.

[0087] The specific display method of the first display effect is not limited, including but not limited to increasing the font size, bolding, highlighting colors, animation effects, etc., but not limited to these. As long as it can be distinguished from the display of other functional modules and has a higher visual appeal than the second display effect, it is acceptable.

[0088] The specific display method of the second display effect is not limited, including but not limited to reducing the font size, reducing the opacity, and displaying in a dark color, but it is not limited to these. As long as it can not attract too much attention compared to the content displayed by the first display effect, it is acceptable.

[0089] According to the scheme of this embodiment, during the execution of the compiled control logic, the currently activated functional module is displayed with a first display effect that is more visually appealing, while other functional modules are displayed with a second display effect that is less visually appealing. This differentiates the currently activated functional module from other functional modules, allowing users to visually identify which functional module is currently being executed. Since variables are updated during the execution of a functional module, the corresponding model components of the device model to be debugged will also execute driving actions based on the latest variables. This creates a strong visual correlation between the currently activated functional module and the model components of the device model to be debugged, which helps to understand the causal relationship between the control logic and the actions of the device model during debugging. It also helps to locate anomalies when debugging anomalies occur, thereby further improving debugging efficiency.

[0090] In some embodiments, step S202 includes: executing the compiled control logic at preset scan intervals by the control thread in the synchronous execution engine, and updating the variable state of the variables in the compiled control logic;

[0091] Step S203 above includes: in each rendering frame, through the rendering engine in the synchronous execution engine, determining the variables of the control logic associated with the driving parameters of the device model to be debugged based on a pre-established shared variable table, reading the latest variable state of the associated variables, and driving the device model to be debugged based on the latest variable state.

[0092] The synchronous execution engine is the core component responsible for transforming instructions based on compiled control logic into specific processing procedures and outputting results, as well as transforming driver operations on the device model under test into specific driver operations to change the state of the device model after driving. In this embodiment, the synchronous execution engine comprises two parts: a control thread and a rendering engine. The control thread executes the compiled control logic, and the rendering engine drives and updates the device model, thereby enabling a synchronous debugging mechanism for the control logic and the device model.

[0093] Based on this embodiment, by providing a synchronous execution engine that simultaneously includes a control thread and a rendering engine, the compiled control logic and the rendering driver of the device model to be debugged can be executed respectively through the control thread and the rendering engine in the synchronous execution engine. By using two cooperating control threads and rendering engines in the same synchronous execution engine to synchronously execute the synchronous debugging process of the control logic and the device model, it can help to further improve the synchronous debugging performance.

[0094] Based on the embodiments described above, a detailed example of a specific application is provided below. In this specific example, the overall architecture and flowchart can be as follows: Figure 5 As shown.

[0095] The synchronous debugging method for control logic and device model in this application embodiment is based on a unified working platform. Through the association mapping of the internal shared variable table and the synchronous execution engine, the control flow of the control logic and the geometric motion flow of the device model are closely integrated to form a closed-loop, interactive virtual debugging environment.

[0096] refer to Figure 5 As shown in the example, the overall architecture and process can include the following steps.

[0097] First, during the environment setup phase, a unified software development environment integrating a logic editor (such as the FBD / SFC logic editor) and a 3D simulation view pane can be created. This development environment maintains a shared variable table, which can be shared by the logic editor and the simulation environment in the 3D simulation view pane. All variables defined in the control logic program (e.g., move #1, rotate #1) and driving parameters defined in the 3D scene are set in this shared variable table, ensuring data consistency from the source and laying the foundation for subsequent associations.

[0098] Secondly, the association and mapping stage between the control model and the 3D device model aims to establish a mapping connection between the control logic program and the 3D model. In a specific example, this can be done in the following way:

[0099] On the one hand, regarding control logic: complete control logic programs can be written in the logic editor based on the shared variable table, such as writing complete FBD / SFC control logic programs.

[0100] On the other hand, regarding the 3D model side: in the 3D simulation view, the 3D model of the device corresponding to the control logic to be tested can be imported or created, and the actions (such as displacement, rotation) and driving parameters (such as target position, movement speed) of each movable part (such as cylinder, motor, conveyor belt) of the device can be defined.

[0101] Based on the above operations, the bidirectional binding between variables in the control logic program and the driving parameters of the 3D device model can be automatically achieved by sharing the variable table with the names of the actions and driving parameters of the movable parts of the user-defined model.

[0102] During the synchronous debugging phase, after receiving the debugging command to start the simulation, the integrated environment's built-in compiler compiles the control logic program into intermediate code executable within the environment, achieving bidirectional initialization binding between the control logic program and the device model's drive parameters. Subsequently, a synchronous execution mode is initiated. In this mode, the integrated synchronous execution engine enables synchronous debugging of the control logic program and the device model. This execution engine comprises two cooperating parts:

[0103] Control thread: This control thread runs in the background at a fixed scan cycle, that is, at a preset scan cycle interval, to execute the compiled control logic and update the variable state of the multiple variables in the compiled control logic.

[0104] Rendering Engine: This rendering engine can be a 3D rendering engine. It renders the 3D scene in real-time in the foreground and actively reads the latest variable states (i.e., the latest values) of all bound variables from the control thread in each rendering frame. Then, based on the bidirectional binding relationship between the variables in the established control logic program and the driving parameters of the 3D device model, the 3D rendering engine uses the read variable values ​​to drive the corresponding 3D model in real-time, such as controlling the 3D model's posture, position, and motion state. For example, when the cylinder extension logic becomes true, the cylinder in the 3D model immediately begins to extend, thus achieving positive synchronization between the control logic and the 3D model's actions.

[0105] During the debugging process, integrated interactive debugging is also possible, extending from visualization to debuggability, providing powerful debugging tools, specifically:

[0106] On the one hand, multiple users can influence the control logic not only by modifying variables in the control logic program through the structure tree;

[0107] On the other hand, users can directly interact with the device model in the 3D view and influence the control logic through interactive operations. For example, clicking buttons on the virtual control screen or dragging a virtual workpiece to block photoelectric sensors are operations based on a shared variable table. These operations can directly modify the input variable values ​​in the corresponding control logic, triggering the control logic from the 3D environment and simulating input signals from the real world.

[0108] In this specific example, during the execution of the control thread, the currently activated functional module (e.g., an FBD (Function Block Diagram)) is displayed with a primary effect, such as being highlighted in green. Simultaneously, in the 3D view, the model components corresponding to the logic of this functional module also begin to move. This provides a strong visual correlation, enabling debugging engineers to instantly understand the causal relationship between the logic and the model's actions.

[0109] The types of contact points that can perform interactive operations provided and supported by the device model are not limited. These contact points can serve as fundamental elements of the control logic and, in this embodiment, are given a new dimension of dynamics and visualization in the 3D simulation environment. The specific types of contact points are not limited; for example, they can include normally open and normally closed contacts expressing switch states, as well as rising-edge and falling-edge contacts for detecting signal changes. It is understood that in the unified development environment provided in this embodiment, each contact point capable of receiving interactive operations is bound to a variable in a shared variable table, such as a corresponding Boolean variable in a shared scalar table. Its on / off state can be directly determined by the logical value of the bound variable. When the compiled logic control program is executed, the energized or de-energized state of the contact points will be displayed in real-time and highlighted in the logic editor. This state change, through a two-way binding relationship, can immediately trigger the actions of the virtual devices associated with it in the 3D simulation model (such as the on and off of sensor status indicator lights), or reverse map the user's interactive operations in the 3D scene (such as collision virtual sensors) into the state change of the touch point, thereby establishing a seamless, intuitive and two-way linkage debugging bridge between the control logic and the geometric device model.

[0110] There are no restrictions on the types of contacts supported. Some examples of contacts may be as follows:

[0111] Input contact: This input contact is used to provide an input signal that is associated with a variable (reading the state of the variable) or a constant;

[0112] Output contact: This output contact is used to provide an output signal that is associated with a variable (the state of the write meter volume);

[0113] Non-Boolean logical functions: used to control the output signal to be the opposite of the input signal;

[0114] Logical AND Boolean functions: These are used to control the output signal to be the result of a Boolean AND operation between two input signals;

[0115] Logical OR Boolean functions: used to control the output signal to be the result of a Boolean OR operation between two input signals;

[0116] Rising edge: Used to indicate that when the state of the input signal changes from False to True, the output signal is true within one program execution cycle;

[0117] Falling edge: Used to indicate that when the state of the input signal changes from True to False, the output signal is true within one program execution cycle;

[0118] Timer: Used to indicate that the output signal becomes True after a delay of a certain time, which is usually defined in seconds;

[0119] Assignment: This indicates that if the bottom input is True, the state of the top input is copied to the output state; otherwise, the output state remains unchanged.

[0120] Computation: Used to represent performing mathematical calculations between two or more input states and writing the results to the output state;

[0121] Comparison: Used to compare the states of two inputs and write the obtained boolean result (False or True) to the output state;

[0122] SFC initialization: Used to indicate the step+ transition of SFC, and can start entering the first execution step;

[0123] SFC: Used to indicate the step+ transition of SFC, which can proceed to the next execution step.

[0124] It is understood that the examples of contacts in the above examples are merely illustrative of some contacts and are not intended to limit the specific contacts in the debugging environment. In the actual debugging process, there may be different or more contacts, and this application embodiment does not make specific limitations in this regard.

[0125] As can be seen from the above, the solution of this application upgrades 3D simulation from passive animation display to an active, interactive debugging platform. It can realize in-depth closed-loop verification of control logic, complete the full verification of control program in virtual environment, and form a debugging closed loop of "logic-model-logic". The status synchronization highlighting and single-step execution functions make problem location intuitive and accurate, and can quickly discover logic errors and timing problems. It reduces costs and risks, greatly reduces dependence on physical PLCs and physical equipment, avoids equipment collisions and downtime caused by program errors, and achieves "zero-risk" debugging. It provides a unified collaboration platform for the control and mechanical fields, reduces communication costs, and improves team collaboration efficiency.

[0126] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0127] Based on the same inventive concept, this application also provides a device for synchronously debugging control logic and device models to implement the above-described method for synchronously debugging control logic and device models. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more embodiments of the device for synchronously debugging control logic and device models provided below can be found in the limitations of the synchronous debugging method for control logic and device models described above, and will not be repeated here.

[0128] In one exemplary embodiment, such as Figure 6 As shown, a synchronous debugging device for control logic and device model is provided, including: an instruction triggering module 601, a logic debugging module 602, and a device model debugging module 603, wherein:

[0129] The instruction triggering module 601 is used to receive and respond to debugging instructions, compile the logic control program to be debugged, obtain the compiled control logic, and display and render the device model to be debugged.

[0130] The logic debugging module 602 is used to execute the compiled control logic at preset scan intervals and update the variable state of the compiled control logic variables.

[0131] The device model debugging module 603 is used to determine the variables of the control logic associated with the driving parameters of the device model to be debugged in each rendering frame, based on a pre-established shared variable table, read the latest variable state of the associated variables, and drive the device model to be debugged based on the latest variable state. The shared variable table is a variable table that shows the relationship between the variables of the control logic and the driving parameters of the device model.

[0132] In some embodiments, the device model debugging module 603 is used to receive and respond to an operation command on the displayed device model to be debugged, and drive the device model to be debugged to perform a driving action corresponding to the operation command.

[0133] The logic debugging module 602 is used to obtain the updated driving parameters corresponding to the driving action; based on the pre-established shared variable table, it updates the variable state of the compiled control logic variables through the updated driving parameters.

[0134] In some embodiments, the instruction triggering module 601 is configured to display the logic control program to be debugged in a first display area and the device model to be debugged in a second display area in response to a debugging instruction.

[0135] In some embodiments, the instruction triggering module 601 is used to display the currently activated functional module in the logic control program to be debugged with a first display effect during the execution of the compiled control logic, and to display the functional modules other than the currently activated functional module with a second display effect, wherein the visual appeal of the second display effect is less than that of the first display effect.

[0136] In some embodiments, the logic debugging module 602 is used to execute the compiled control logic at preset scan intervals by the control thread in the synchronous execution engine, and update the variable state of the variables in the compiled control logic.

[0137] The device model debugging module 603 is used to determine the variables of the control logic associated with the driving parameters of the device model to be debugged in each rendering frame based on a pre-established shared variable table, through the rendering engine in the synchronous execution engine, read the latest variable state of the associated variables, and drive the device model to be debugged based on the latest variable state.

[0138] In some embodiments, the device model to be debugged includes a button control, and the operation instructions include a click instruction on the button control.

[0139] In some embodiments, the device model to be debugged includes a virtual workpiece; the operation instructions include position adjustment operations for the virtual workpiece.

[0140] The various modules in the aforementioned control logic and device model synchronous debugging device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0141] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for synchronously debugging control logic and the device model.

[0142] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a method for synchronously debugging control logic and device models. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0143] Those skilled in the art will understand that Figure 7 , 8The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0144] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the methods in the above embodiments.

[0145] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the methods described in the above embodiments.

[0146] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the methods described in the above embodiments.

[0147] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0148] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0149] The above embodiments merely illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application's patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for synchronously debugging control logic and device model, characterized in that, The method includes: Receive and respond to debugging commands, compile the logic control program to be debugged, obtain the compiled control logic, and display and render the device model to be debugged; At each preset scan cycle, the compiled control logic is executed, and the variable state of the variables in the compiled control logic is updated; In each rendering frame, based on a pre-established shared variable table, the variables of the control logic associated with the driving parameters of the device model to be debugged are determined, the latest variable state of the associated variables is read, and the device model to be debugged is driven based on the latest variable state. The shared variable table is a variable table that shows the relationship between the variables of the control logic and the driving parameters of the device model.

2. The method according to claim 1, characterized in that, The method further includes: Receive and respond to operation instructions on the displayed device model to be debugged, and drive the device model to be debugged to perform driving actions corresponding to the operation instructions; Obtain the updated driving parameters corresponding to the driving action; Based on the pre-established shared variable table, the variable state of the variables in the compiled control logic is updated through the updated driving parameters.

3. The method according to claim 1, characterized in that, The method further includes: In response to the debugging command, the logic control program to be debugged is displayed in the first display area, and the device model to be debugged is displayed in the second display area.

4. The method according to claim 3, characterized in that, The method further includes: During the execution of the compiled control logic, the currently activated functional module in the logic control program to be debugged is displayed with a first display effect, and the functional modules other than the currently activated functional module are displayed with a second display effect, wherein the visual appeal of the second display effect is less than that of the first display effect.

5. The method according to claim 1, characterized in that, The method further includes: By using the control thread in the synchronous execution engine, the compiled control logic is executed at preset scan intervals, and the variable state of the variables in the compiled control logic is updated. In each rendering frame, the rendering engine in the synchronous execution engine determines the variables of the control logic associated with the driving parameters of the device model to be debugged, based on a pre-established shared variable table, reads the latest variable state of the associated variables, and drives the device model to be debugged based on the latest variable state.

6. The method according to claim 2, characterized in that, Includes at least one of the following: First item: The device model to be debugged includes a button control, and the operation instructions include a click instruction on the button control; Second item: The device model to be debugged includes a virtual workpiece; the operation instructions include the operation of adjusting the position of the virtual workpiece.

7. A device for synchronously debugging control logic and device model, characterized in that, The device includes: The instruction triggering module is used to receive and respond to debugging instructions, compile the logic control program to be debugged, obtain the compiled control logic, and display and render the device model to be debugged. The logic debugging module is used to execute the compiled control logic at preset scan intervals and update the variable state of the variables in the compiled control logic. The device model debugging module is used to determine, in each rendering frame, the variables of the control logic associated with the driving parameters of the device model to be debugged based on a pre-established shared variable table, read the latest variable state of the associated variables, and drive the device model to be debugged based on the latest variable state. The shared variable table is a variable table that shows the relationship between the variables of the control logic and the driving parameters of the device model.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method of any one of claims 1 to 6.

Images