Controller virtual simulation method, system and device and storage medium

Abstract

The invention discloses a controller virtual simulation method, system and device and a storage medium, and relates to the technical field of digital twinning, and the method comprises the steps: collecting a virtual operation signal, and converting the virtual operation signal into a control instruction which can be recognized by an entity programmable logic controller according to an input and output point location mapping relation; transmitting the control instruction to an entity programmable logic controller, and receiving a returned state feedback signal and program operation data; and driving the three-dimensional model to generate a synchronous action according to the state feedback signal, and comparing the program operation data with a preset judgment standard to obtain a simulation assessment result. According to the method, the flexibility of the virtual simulation scene in the aspects of scene switching, cost control and safety drilling is reserved, and the three-dimensional model is driven to synchronously act through real participation and state feedback of the entity PLC, so that the defect that a pure software simulation tool cannot reflect physical characteristics is overcome; therefore, the authenticity and flexibility of PLC teaching and engineering debugging are both considered.

Description

Technical Field

[0001] This application relates to the field of digital twin technology, and in particular to a controller virtual simulation method, system, device and storage medium. Background Technology

[0002] With the continuous improvement of industrial automation, PLCs (Programmable Logic Controllers) are increasingly widely used in industrial production. They are core control devices in industrial automation, and the quality of their training and engineering debugging directly affects production efficiency and system reliability. Currently, PLC practical training mainly relies on real hardware equipment, including physical PLCs, sensors, and actuators. However, this all-hardware approach has significant shortcomings: high equipment costs, complex maintenance, and frequent rewiring required when switching training scenarios, resulting in poor flexibility. In actual production environments, directly using field equipment for program development and debugging often leads to long downtime and high safety risks; program errors can cause equipment damage or production accidents.

[0003] To overcome these problems, some pure software PLC simulation tools have emerged on the market. While these tools reduce costs and improve safety, the simulated input / output signals, timing logic, and dynamic responses of external devices often differ from the actual hardware environment, failing to accurately reflect physical characteristics such as sensor noise, actuator delays, and communication jitter. The experience gained by learners in software simulation is difficult to directly transfer to real equipment, and engineers cannot use software simulation to verify key indicators such as hardware interface compatibility and real-time performance. Summary of the Invention

[0004] The main purpose of this application is to provide a virtual simulation method, system, device and storage medium for controllers, aiming to solve the technical problem that it is difficult to achieve both realism and flexibility in PLC teaching and engineering debugging.

[0005] To achieve the above objectives, this application proposes a controller virtual simulation method, which includes: The system collects virtual operation signals from a virtual simulation scenario and converts these signals into control commands that can be recognized by a physical programmable logic controller (PLC) based on a preset input / output point mapping relationship. The control command is transmitted to the physical programmable logic controller, and the status feedback signal and program running data returned by the physical programmable logic controller based on the control command are received. The state feedback signal drives the three-dimensional model in the virtual simulation scene to generate synchronous actions, and the program running data is compared with the preset evaluation criteria to obtain the simulation evaluation result. The three-dimensional model is constructed based on the three-dimensional size data of the physical programmable logic controller and the external device corresponding to the physical programmable logic controller.

[0006] In one embodiment, the step of converting the virtual operation signal into control instructions recognizable by a physical programmable logic controller according to a preset input / output point mapping relationship includes: Parse the virtual port identifier and signal value corresponding to the virtual operation signal; Using the virtual port identifier as an index, the corresponding physical port identifier and signal conversion strategy are queried in the input / output point mapping relationship; The signal value is converted into a target operation signal in the target data format according to the signal conversion strategy, and the control command is formed based on the target operation signal and the entity port identifier.

[0007] In one embodiment, after the step of acquiring virtual operation signals in the virtual simulation scene, the method further includes: Read the configuration data block storing the input / output point mapping relationship, and obtain the binary sequence of the configuration data block, wherein the binary sequence consists of a target data segment and a preset cyclic redundancy check code; Calculate the actual cyclic redundancy check code of the target data segment, and compare the actual cyclic redundancy check code with the preset cyclic redundancy check code; If the actual cyclic redundancy check code and the preset cyclic redundancy check code are consistent, the check is deemed to be successful, and the process of parsing the virtual port identifier and signal value corresponding to the virtual operation signal is executed. If the actual cyclic redundancy check code and the preset cyclic redundancy check code are inconsistent, the check is deemed to have failed, a mapping error signal is output, and the step of parsing the virtual port identifier and signal value corresponding to the virtual operation signal is canceled.

[0008] In one embodiment, the step of transmitting the control command to the physical programmable logic controller includes: The control command is encapsulated into a data frame to be transmitted, and a timestamp is added to the data frame to be transmitted to obtain the first target data frame. The first target data frame is written non-blockingly to the write port of the bidirectional data buffer queue, so that the entity programmable logic controller reads the second target data frame from the read port of the bidirectional data buffer queue. If the difference between the timestamp of the second target data frame and the current system time exceeds a preset time limit, a retransmission request signal is returned. If the difference does not exceed the preset time limit, the control instruction is executed, and the status feedback signal and the program running data are returned. The retransmission request signal is used to request that the first target data frame be rewritten non-blockingly to the write port.

[0009] In one embodiment, the step of receiving the status feedback signal and program execution data returned by the physical programmable logic controller based on the control instructions includes: The system receives the raw data stream returned by the physical programmable logic controller through a bidirectional data buffer queue, and extracts the status feedback signal and the program execution data from the raw data stream. The state feedback signal is transmitted to the 3D model driving interface so that the step of driving the 3D model in the virtual simulation scene to generate synchronous actions based on the state feedback signal can be executed by calling the 3D model driving interface. The program execution data is transmitted to the assessment interface, and the step of comparing the program execution data with the preset evaluation criteria and obtaining the simulation assessment result is executed by calling the assessment interface.

[0010] In one embodiment, the step of driving the 3D model in the virtual simulation scene to generate synchronized actions based on the state feedback signal includes: The device identifier and status parameters are obtained by parsing the status feedback signal; Based on the device identifier, the corresponding model component is retrieved and located in the 3D model, and based on the state parameters, the target pose transformation matrix of the model component and / or the display state switching command is calculated. The target pose transformation matrix and / or display state switching command are applied to the model component to update the pose and / or display state of the model component.

[0011] In one embodiment, the step of comparing the program execution data with preset evaluation criteria to obtain the simulation assessment result includes: The raw values ​​in the program execution data are converted into physical quantities to obtain the actual physical quantities in the target numerical format. The stable value of the actual physical quantity is collected according to the preset delay time, and the stable value is compared with the theoretical value of each assessment item in the preset evaluation criteria to obtain the deviation value of each assessment item. The simulation assessment total score is calculated based on each deviation value and the preset scoring weight, and the simulation assessment total score is used as the simulation assessment result.

[0012] Furthermore, to achieve the above objectives, this application also proposes a controller virtual simulation system, which includes: The signal mapping module is used to convert the virtual operation signal into control instructions that can be recognized by the physical programmable logic controller according to the preset input-output point mapping relationship; The signal transmission module is used to transmit the control command to the physical programmable logic controller and receive the status feedback signal and program running data returned by the physical programmable logic controller based on the control command. The simulation assessment module is used to drive the three-dimensional model in the virtual simulation scene to generate synchronous actions according to the state feedback signal, and compare the program running data with the preset evaluation criteria to obtain the simulation assessment result. The three-dimensional model is constructed based on the three-dimensional size data of the physical programmable logic controller and the external device corresponding to the physical programmable logic controller.

[0013] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: 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 controller virtual simulation method as described above.

[0014] 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 controller virtual simulation method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application collects virtual operation signals from a virtual simulation scene and uses the input / output point mapping relationship to accurately convert the virtual operation signals into control commands that the physical PLC can recognize. This allows the physical PLC to receive control input from the virtual environment without changing the wiring of the physical equipment. The control commands are then transmitted to the physical PLC, and the application receives status feedback signals and program execution data returned by the physical PLC after the actual execution of the control commands. This two-way communication mechanism ensures that the real operating status of the physical PLC can be fed back to the virtual side in real time. Based on this, the application drives the 3D model constructed based on the 3D dimension data of the physical PLC and its external equipment to generate synchronous movements according to the status feedback signals. This allows the device pose and display status in the virtual simulation scene to accurately follow the real physical response of the physical equipment. At the same time, the application compares the program execution data with preset evaluation criteria to automatically obtain the simulation evaluation results. Therefore, this technical solution retains the flexibility of virtual simulation scenarios in terms of scene switching, cost control, and safety drills. It also overcomes the shortcomings of pure software simulation tools in reflecting physical characteristics by driving the synchronous movement of the 3D model through the real participation of the physical PLC and its status feedback. This allows learners to directly transfer the experience gained in the virtual environment to real equipment, and engineers can also verify the compatibility and real-time performance of hardware interfaces. Thus, it balances the authenticity and flexibility of PLC teaching and engineering debugging. Attached Figure Description

[0016] 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.

[0017] 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.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the virtual simulation method for the controller in this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the controller virtual simulation method of this application; Figure 3 This is a simplified flowchart illustrating the controller virtual simulation method provided in Embodiment 2 of this application; Figure 4 This is a schematic diagram of the module structure of the controller virtual simulation system according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the controller virtual simulation method in this application embodiment.

[0019] 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

[0020] 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.

[0021] 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.

[0022] The main solution of this application embodiment is as follows: virtual operation signals are collected from a virtual simulation scene, and the virtual operation signals are converted into control instructions recognizable by a physical programmable logic controller (PLC) according to a preset input / output point mapping relationship; the control instructions are transmitted to the PLC, and status feedback signals and program running data returned by the PLC based on the control instructions are received; the three-dimensional model in the virtual simulation scene is driven to generate synchronous actions according to the status feedback signals, and the program running data is compared with preset evaluation criteria to obtain simulation evaluation results. The three-dimensional model is constructed based on the three-dimensional dimension data of the PLC and the corresponding external device.

[0023] Currently, PLC training primarily relies on real hardware devices, including physical PLCs, sensors, and actuators. However, this all-hardware approach has significant drawbacks: high equipment costs, complex maintenance, and frequent rewiring required when switching training scenarios, resulting in poor flexibility. In actual production environments, directly using field equipment for program development and debugging often leads to long downtime and high safety risks; program errors can cause equipment damage or production accidents. To overcome these problems, some purely software-based PLC simulation tools have emerged. While these tools reduce costs and improve safety, their simulated input / output signals, timing logic, and the dynamic response of external devices often differ from the actual hardware environment, failing to accurately reflect physical characteristics such as sensor noise, actuator delays, and communication jitter. Learners' experience gained in software simulations is difficult to directly transfer to real equipment, and engineers cannot use software simulations to verify key indicators such as hardware interface compatibility and real-time performance.

[0024] This application provides a solution that collects virtual operation signals from a virtual simulation scene and accurately converts these signals into control commands recognizable by the physical PLC using input / output point mapping relationships. This allows the physical PLC to receive control input from the virtual environment without altering the wiring of the physical equipment. The control commands are then transmitted to the physical PLC, and the application receives status feedback signals and program execution data returned by the physical PLC after the actual execution of these commands. This bidirectional communication mechanism ensures that the actual operating status of the physical PLC is fed back to the virtual side in real time. Based on this, the status feedback signals drive a 3D model constructed from the 3D dimension data of the physical PLC and its external devices to generate synchronized actions. This allows the device pose and display status in the virtual simulation scene to accurately follow the actual physical response of the physical equipment. Simultaneously, the program execution data is compared with preset evaluation criteria to automatically obtain simulation assessment results. Therefore, this technical solution retains the flexibility of virtual simulation scenarios in terms of scene switching, cost control, and safety drills. It also overcomes the shortcomings of pure software simulation tools in reflecting physical characteristics by driving the synchronous movement of the 3D model through the real participation of the physical PLC and its status feedback. This allows learners to directly transfer the experience gained in the virtual environment to real equipment, and engineers can also verify the compatibility and real-time performance of hardware interfaces. Thus, it balances the authenticity and flexibility of PLC teaching and engineering debugging.

[0025] 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 controller virtual simulation system capable of performing the above functions. The following description uses a controller virtual simulation system as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, embodiments of this application provide a controller virtual simulation method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the controller virtual simulation method of this application.

[0027] In this embodiment, the controller virtual simulation method includes steps S10 to S30: Step S10: Collect virtual operation signals in the virtual simulation scene, and convert the virtual operation signals into control instructions that can be recognized by the physical programmable logic controller according to the preset input-output point mapping relationship. It should be noted that a virtual simulation scene refers to a digital interactive space built using 3D modeling tools (such as SolidWorks and 3ds Max) and 3D engines (such as Unity3D) to simulate the real industrial environment and equipment operating status. This scene not only includes high-precision 3D models constructed from the 3D dimension data of physical PLCs and external devices (such as tri-color lights, buttons, temperature and humidity sensors, stepper motors, and robotic arms), but also presents a near-realistic operating interface and visual feedback through detailed processing such as professional lighting, animated paths, and dynamic bending simulation. Users can perform practical training tasks such as programming, debugging, and troubleshooting within this scene. The scene will drive the 3D model to produce synchronized actions in real time based on the received status feedback signals, allowing users to observe a visual response consistent with the actual operating results of the physical PLC.

[0028] Virtual operation signals are digital trigger signals generated by users in a virtual simulation scenario through a graphical user interface (e.g., clicking virtual buttons, toggling virtual switches, operating virtual touchscreens, or dragging virtual devices). These signals carry the user's intended operation to the control system, which may include, but is not limited to, the virtual port identifier that generated the operation (e.g., the number corresponding to a virtual input point) and the signal value of the operation (e.g., a Boolean value indicating press or release, or a numerical value indicating an analog input). Virtual operation signals are generated in a purely software environment and do not originate directly from physical hardware devices, but through subsequent conversion and transmission, they can drive a real physical PLC to execute corresponding control logic.

[0029] Input / output point mapping relationships are a pre-configured set of associations used to establish a bidirectional correspondence between virtual input / output ports in the virtual simulation scenario and physical input / output ports on the physical PLC. This mapping relationship can exist in the form of a graphical drag-and-drop configuration interface or a configuration file. Users can flexibly bind virtual components such as virtual buttons and virtual sensors to specific input points of the physical PLC, and simultaneously bind the output points of the physical PLC to virtual actuators such as virtual indicator lights and virtual motors. The mapping relationship can also include signal conversion strategies, such as data type conversion, range scaling, and polarity reversal, to ensure that the signal format and physical meaning on the virtual side and the physical side remain consistent. Through this mapping relationship, the system can accurately convert virtual operation signals into control commands that the physical PLC can recognize, and conversely, it can correctly drive the status feedback signals returned by the physical PLC to the corresponding virtual model.

[0030] A physical programmable logic controller (PLC) refers to an actual, programmable industrial control hardware device, such as a specific model of PLC controller. This physical PLC has real physical interfaces, such as digital input / output ports, analog input / output ports, and communication ports. It can receive input signals from external devices, perform logic operations, timing, counting, analog signal processing, and other operations according to the control program written by the user and downloaded to its internal memory, and generate corresponding output signals to drive actuators.

[0031] Control instructions are digital command data that, after conversion, can be directly recognized and executed by the physical PLC. These instructions are derived from virtual operation signals based on the input / output point mapping relationship and may, but are not limited to, contain two key parts: first, the target physical port identifier, indicating which input point or data register of the physical PLC the instruction should apply to; and second, the target operation signal, whose data format and value range conform to the communication protocol and signal specifications of the physical PLC, such as Boolean, integer, or floating-point values. Control instructions can be encapsulated into data frames with timestamps, written in a non-blocking manner through a bidirectional data buffer queue, and transmitted to the physical PLC, thereby driving the physical PLC to execute the corresponding control logic, equivalent to a real hardware button or sensor directly sending a signal to the PLC.

[0032] Step S20: Transmit the control command to the physical programmable logic controller and receive the status feedback signal and program running data returned by the physical programmable logic controller based on the control command; It should be noted that status feedback signals refer to electrical or data signals generated by the output ports or internal status registers of the physical PLC after receiving control commands and executing the corresponding control programs. These signals reflect the actual operating status of the physical equipment. These signals include, but are not limited to: the on / off status of the physical PLC output points (such as the start / stop of a virtual motor), analog output values ​​(such as the speed setpoint for a virtual frequency converter), and the status bits of special registers within the physical PLC (such as fault flags and run / stop status). The status feedback signals are returned by the physical PLC to the host virtual simulation system through the communication interface. They are the key input basis for driving the synchronous actions of the 3D model in the virtual simulation scene. Their realism lies in their embodiment of the inherent physical characteristics of the physical PLC when executing programs in the actual hardware environment, such as output delay and signal jitter.

[0033] Program execution data refers to the digital information recorded in the internal memory of a PLC during the execution of a user-downloaded control program. This information includes various operating parameters, intermediate variables, current values ​​of timers and counters, analog-to-analog conversion values, and the execution trajectory of program steps. Unlike status feedback signals, program execution data focuses more on the logical execution details and numerical calculation results within the PLC program, such as the remaining time of a timer, the dynamic changes of variables in a data block, and the number of times a certain instruction is executed. This data is collected in real time through the communication interface and transmitted to the evaluation interface for comparison with preset evaluation criteria, thereby objectively evaluating the correctness, efficiency, and stability of the user-written PLC program in a real hardware environment.

[0034] Step S30: Drive the three-dimensional model in the virtual simulation scene to generate synchronous actions according to the state feedback signal, and compare the program running data with the preset evaluation criteria to obtain the simulation assessment result. The three-dimensional model is constructed based on the three-dimensional size data of the physical programmable logic controller and the external device corresponding to the physical programmable logic controller.

[0035] It should be noted that the 3D model refers to a parametric, three-dimensional digital model constructed using modeling tools such as SolidWorks and 3ds Max, based on the actual 3D dimensions of the physical PLC and its corresponding external equipment. During the modeling process, not only are the mechanical interfaces and installation dimensions of the model perfectly matched to the physical object, but the appearance of the real equipment is also reproduced through PBR materials (such as metal / plastic textures), UV mapping, and transparent acrylic refraction parameters. Furthermore, dynamic behaviors such as the color switching of the three-color LEDs, the change in button press height, and the rotational speed of the motor are also animated. After the 3D model is imported into the virtual simulation scene, it can update its pose and display status in real time based on status feedback signals, allowing users to observe visual feedback in the virtual environment that is completely synchronized with the actual output of the physical PLC.

[0036] The simulation assessment results can be quantitative evaluation conclusions generated by the system after automatically comparing and calculating the program execution data returned by the physical PLC during the user's training process according to pre-set evaluation criteria and scoring weights. These conclusions can also cover multiple assessment dimensions such as operational standardization, hardware response compliance, and data compatibility, specifically including indicators such as program correctness (e.g., whether the logical function is implemented), execution results (e.g., whether the final output meets expectations), and operation time (e.g., the time taken from startup to stable operation). When generating the assessment results, the system employs a delayed verification mechanism to avoid instantaneous error interference, performs physical quantity conversion on the original values ​​in the program execution data (e.g., hexadecimal to decimal floating-point), and performs step-by-step differentiated evaluation based on a dynamic step-by-step scoring architecture. Finally, it outputs the total simulation assessment score or detailed score breakdown, providing teachers or learners with an objective and fair basis for performance evaluation.

[0037] Understandably, traditional all-hardware PLC training solutions suffer from high equipment costs, complex maintenance, and poor flexibility in scene switching. Meanwhile, pure software simulation tools cannot realistically reflect the physical characteristics of the physical hardware environment, such as sensor noise, actuator delays, and communication jitter. This leads to discrepancies between simulation results and actual operating conditions, making it difficult to transfer learned experience to real equipment. To address this contradiction, this embodiment collects virtual operation signals from the virtual simulation scene and converts them into control instructions recognizable by the physical PLC using a preset input / output point mapping relationship. These control instructions are then transmitted to the physical PLC, which returns status feedback signals and program execution data based on these instructions. On one hand, the status feedback signals drive a 3D model constructed from the 3D dimensions of the physical PLC and external devices to generate synchronized actions. On the other hand, the program execution data is compared with preset evaluation criteria to obtain simulation assessment results. This approach avoids the technical shortcomings of pure software simulation, which cannot reproduce the uncertainties of the physical world (such as signal jitter and execution delays) due to the lack of real hardware participation, and also avoids the drawbacks of all-hardware solutions, such as high costs, cumbersome wiring, and safety hazards. It achieves a unified effect of high-fidelity simulation and flexible, low-cost training under a virtual-real fusion approach.

[0038] For example, a virtual simulation scene built using Unity3D is run on a computer. This scene displays a 3D motor model constructed from the 3D dimensions of a physical PLC and its external motor, along with a virtual forward / reverse button. When the user clicks the virtual forward / reverse button in the virtual simulation scene, the system acquires the virtual operation signal. This signal carries the port identifier (e.g., virtual input point I0.0) and signal value (e.g., logic "1" indicating a pressed button) corresponding to the virtual button. Subsequently, the system reads the input / output point mapping relationship pre-configured via a graphical drag-and-drop interface. This mapping relationship records the physical input point I0.0 of the physical PLC corresponding to the virtual input point I0.0, and the signal conversion strategy is direct mapping. Therefore, the system converts the virtual operation signal into a control instruction recognizable by the physical PLC (e.g., a Mod). The system writes a command to the bus, with the target address being %I0.0 of the physical PLC and the data value being 1. The system then appends a timestamp to this control command and transmits it to the physical PLC via TCP / IP. The physical PLC executes its internally downloaded forward / reverse control program, outputting a high level at its output point Q0.0, and returns a status feedback signal (e.g., Q0.0 = 1) and program execution data (e.g., the cumulative time of timer T37) through the communication interface. Upon receiving the status feedback signal, the system drives the motor model in the 3D model to rotate around its axis based on the device identifier (representing the motor) and status parameters (representing startup) in the signal. Simultaneously, the system compares the program execution data (e.g., motor running time) with preset evaluation criteria (e.g., requiring the motor to start within 2 seconds of pressing the button), generates a simulation assessment score, and displays it on the interface.

[0039] This embodiment provides a virtual simulation method for a controller. By collecting virtual operation signals in a virtual simulation scene and using the input / output point mapping relationship, the virtual operation signals are accurately converted into control instructions that can be recognized by the physical PLC. This allows the physical PLC to receive control input from the virtual environment without changing the wiring of the physical equipment. Subsequently, the control instructions are transmitted to the physical PLC, and the system receives status feedback signals and program running data returned by the physical PLC after the actual execution of the control instructions. This two-way communication mechanism ensures that the real operating status of the physical PLC can be fed back to the virtual side in real time. Based on this, the system drives the 3D model constructed based on the 3D dimension data of the physical PLC and its external devices to generate synchronous actions according to the status feedback signals. This allows the device pose and display status in the virtual simulation scene to accurately follow the real physical response of the physical device. At the same time, the program running data is compared with preset evaluation criteria to automatically obtain the simulation evaluation results. Therefore, this technical solution retains the flexibility of virtual simulation scenarios in terms of scene switching, cost control, and safety drills. It also overcomes the shortcomings of pure software simulation tools in reflecting physical characteristics by driving the synchronous movement of the 3D model through the real participation of the physical PLC and its status feedback. This allows learners to directly transfer the experience gained in the virtual environment to real equipment, and engineers can also verify the compatibility and real-time performance of hardware interfaces. Thus, it balances the authenticity and flexibility of PLC teaching and engineering debugging.

[0040] In one feasible implementation, the step of transmitting the control command to the physical programmable logic controller in step S20 may include steps S21-S22: Step S21: Encapsulate the control command into a data frame to be transmitted, and add a timestamp to the data frame to be transmitted to obtain the first target data frame; It should be noted that the data frame to be transmitted refers to the raw data unit obtained after encapsulating the generated control instructions according to the frame format of a specific communication protocol (such as MODBUS, PROFINET, or TCP / IP), without the addition of time information. This data frame may, but is not limited to, contain a frame header, a target address field, a control instruction data field, a checksum field, and a frame trailer. The control instruction data field carries the specific operation content that the PLC can recognize after the input / output point mapping relationship is converted, such as a set or reset command for a certain input point. The data frame to be transmitted serves as the basis for subsequent timestamp addition. Its function is to ensure that control instructions can be transmitted in a standardized form over the communication link, while the checksum field ensures data integrity and prevents the PLC from executing incorrect control logic due to transmission errors.

[0041] The first target data frame is a new data frame formed by appending a nanosecond-level timestamp to the data frame to be transmitted. This timestamp precisely records the moment when the data frame is ready to enter the transmission channel, and can be generated by, but is not limited to, the system's high-precision clock. The first target data frame contains both the original control instruction information and time information, and is the actual data object written into the bidirectional data buffer queue. By appending the timestamp, the first target data frame allows the receiving end (i.e., the physical PLC) to determine the time delay experienced from the transmission to reception of the data frame, thereby deciding whether to directly execute the control instructions or treat it as expired data and request retransmission. This mechanism can effectively solve the data timeliness problem caused by network jitter or buffer congestion in industrial communication.

[0042] Step S22: The first target data frame is written non-blockingly to the write port of the bidirectional data buffer queue, so that the entity programmable logic controller reads the second target data frame from the read port of the bidirectional data buffer queue. If the difference between the timestamp of the second target data frame and the current system time exceeds a preset time limit, a retransmission request signal is returned. If the difference does not exceed the preset time limit, the control instruction is executed, and the status feedback signal and the program running data are returned. The retransmission request signal is used to request that the first target data frame be rewritten non-blockingly to the write port.

[0043] It should be noted that the bidirectional data buffer queue is a two-ended queue data structure that supports insertion and deletion operations at both ends of the queue. In this embodiment, it is used as a data transfer station between the controller virtual simulation system (hereinafter referred to as the virtual simulation system) and the physical PLC. The core feature of this queue is non-blocking read and write, that is, after the sending end (i.e., the virtual simulation system) writes the first target data frame to one end of the queue, it can continue to execute subsequent tasks without waiting for the receiving end to process it. At the same time, the receiving end (i.e., the physical PLC) will not be blocked when reading data frames from the other end of the queue due to the queue being empty. The bidirectional data buffer queue can be used to transmit control commands from the virtual side to the physical side, as well as status feedback signals and program running data from the physical side to the virtual side, thereby achieving smooth buffering and decoupling of data in high-concurrency scenarios and avoiding data loss or system lag caused by the mismatch in processing speed between the two sides.

[0044] The write port is a dedicated interface endpoint in a bidirectional data buffer queue for receiving data write operations. At the software implementation level, the write port can, but is not limited to, manifest as a function or method call. The virtual simulation system calls this port and passes in the first target data frame to add it to the tail (or head) of the queue in a non-blocking manner. The design of the write port ensures that enqueue operations will not be blocked due to a full queue or slow processing at the receiving end: if there is available space in the queue, the data frame will be stored immediately; if the queue is full, the system can return a queue full status flag without getting stuck in an infinite wait, thus maintaining the smoothness of interaction in the virtual simulation scene. The write port is used in conjunction with the read port to form a complete queue access interface.

[0045] The read port is a dedicated interface endpoint in the bidirectional data buffer queue used for data read operations. The communication service program on the physical PLC side can retrieve written data frames from the other end of the queue by calling this port. The read port also supports non-blocking operation: if at least one data frame exists in the queue, it is read immediately (i.e., the second target data frame); if the queue is empty, it immediately returns a null value or a signal indicating no data, without blocking or waiting. This design allows the physical PLC to proactively retrieve data according to its own processing rhythm, without passively waiting for pushes from the virtual side, thus achieving time decoupling between the two communicating parties. Through the cooperation of the write and read ports, the bidirectional data buffer queue can efficiently manage data flow.

[0046] The second target data frame refers to the data frame actually obtained by the physical PLC from the bidirectional data buffer queue through the read port. Ideally, the second target data frame is completely identical in content to the first target data frame previously written by the virtual simulation system, containing the original control instructions and nanosecond-level timestamps. However, due to the first-in-first-out (FIFO) nature of the queue and possible concurrent writes, the second target data frame can actually be a copy of one of the first target data frames in the queue. After receiving the second target data frame, the physical PLC immediately extracts the timestamp and calculates the difference between this timestamp and the physical PLC's current system time. Based on the comparison between this difference and the preset timeout period, the physical PLC decides whether to execute the control instructions in the second target data frame (if the difference has not timed out) or return a retransmission request signal (if the difference has timed out), thus ensuring that only instructions with valid timeouts are executed.

[0047] The retransmission request signal is a specific control signal returned by the physical PLC to the virtual simulation system when it determines that the difference between the timestamp of the second target data frame and the current system time exceeds a preset timeout period. This signal explicitly informs the virtual simulation system that the recently received second target data frame has expired and its control instructions should not be executed. The virtual simulation system is requested to repackage the corresponding first target data frame, attach a new timestamp, and rewrite it to the write port of the bidirectional data buffer queue in a non-blocking manner. The introduction of the retransmission request signal effectively solves the problem of data timeliness loss caused by communication delays, queue backlogs, or instantaneous network jitter, forming a closed-loop reliability guarantee mechanism. After receiving the retransmission request signal, the virtual simulation system will retransmit the control instructions as needed until the physical PLC successfully receives the data frame that has not expired, thus ensuring high reliability and real-time performance of control instruction transmission between the virtual and physical systems.

[0048] It is understandable that during virtual-real interaction, control commands need to pass through a communication link to be transmitted from the virtual simulation system to the physical PLC. However, uncertainties such as network latency, queue congestion, or instantaneous jitter exist in the actual industrial environment, which may cause the control commands received by the physical PLC to expire. Executing such expired commands will cause timing discrepancies between the actions of the 3D model in the virtual scene and the actual response of the physical PLC, and may even lead to incorrect assessment results. To address this issue, this implementation further encapsulates the control commands into a data frame to be transmitted and adds a timestamp, for example, at the nanosecond level, to obtain a first target data frame. The first target data frame is then written to the write port of a bidirectional data buffer queue in a non-blocking manner. This allows the physical PLC to obtain the second target data frame from the read port of the queue, calculate the difference between its timestamp and the current system time, and execute the control command and return a status feedback signal and program running data only if the difference does not exceed a preset time limit. If the difference exceeds the preset time limit, a retransmission request signal is returned to trigger the virtual side to retransmit. This avoids the problem of asynchronous virtual and physical actions caused by the execution of outdated control instructions by the physical PLC due to communication delays or queue backlogs. Furthermore, by using non-blocking write and non-blocking read, it eliminates the risk of system lag or data loss that may be caused by traditional blocking communication. This achieves real-time guarantee, timeliness verification, and automatic retransmission mechanism for control instruction transmission in high-concurrency scenarios, significantly improving the reliability and synchronization accuracy of the virtual-physical collaboration process.

[0049] For example, a memory-based double-ended queue is established between the virtual simulation system and the physical PLC as a bidirectional data buffer queue. The queue depth is set to 100, and both the write and read ports are configured to use non-blocking mode. When a generated control instruction (e.g., requiring the physical PLC to set output point Q0.0 to 1) is encapsulated into a data frame to be transmitted conforming to the MODBUS TCP protocol format, the system calls a high-precision clock function to obtain the current nanosecond-level timestamp and appends this timestamp to the end of the data frame to be transmitted to form the first target data frame. Subsequently, the system attempts to enqueue the first target data frame through the write port. If the queue is not full, it immediately stores the data and returns a success flag; if the queue is full, it immediately returns a queue busy flag without blocking or waiting. On the physical PLC side, an independent communication thread runs. This thread attempts to obtain data frames from the read port of the bidirectional data buffer queue at a period of 10 milliseconds. When the second target data frame is read, the timestamp is immediately extracted and the difference is calculated with the current system time of the physical PLC. Assuming the preset timeout period is 100 milliseconds, if the difference (e.g.) If the difference (e.g., 85 milliseconds) is less than 100 milliseconds, the physical PLC executes the control instruction in the second target data frame (sets Q0.0 to 1) and returns a status feedback signal and program running data. If the difference (e.g., 150 milliseconds) is greater than 100 milliseconds, the physical PLC does not execute the instruction but instead returns a retransmission request signal to the virtual simulation system. This retransmission request signal carries the sequence number of the original first target data frame. After receiving the retransmission request signal, the virtual simulation system finds the corresponding original control instruction based on the sequence number, re-encapsulates it, adds a new timestamp (i.e., the current time), and writes it to the write port of the bidirectional data buffer queue in a non-blocking manner. This process is repeated until the physical PLC successfully receives a time-qualified control instruction and returns confirmation.

[0050] In one feasible implementation, the step of receiving the status feedback signal and program execution data returned by the physical programmable logic controller based on the control instruction in step S20 may include steps S23 to S25: Step S23: Receive the raw data stream returned by the physical programmable logic controller through a bidirectional data buffer queue, and extract the status feedback signal and the program running data from the raw data stream; It should be noted that the raw data stream refers to the sequence of binary bytes returned by the physical PLC through a communication interface (such as a serial port or Ethernet), without any parsing or processing. This data stream can be stored in a bidirectional data buffer queue as a payload written from the physical PLC and transmitted to the virtual simulation system. Specifically, after executing control instructions, the physical PLC encapsulates status feedback signals (such as output point on / off status, analog output values) and program execution data (such as current timer values, counter cumulative values, and intermediate variables) into continuous data frames according to the agreed communication protocol (such as MODBUS, PROFINET, or TCP / IP). These data frames may contain auxiliary information such as frame headers, address fields, checksums, and timestamps, forming a raw byte stream without structural distinctions. The virtual simulation system obtains this raw data stream in a non-blocking manner through the read port of the bidirectional data buffer queue. Subsequently, it needs to deframe, checksum, and extract fields according to the protocol specifications to separate the status feedback signals and program execution data that can be directly used later. By using a bidirectional data buffer queue as a relay, the raw data stream can be smoothly transmitted from the physical PLC to the virtual side in high-concurrency scenarios, avoiding data loss caused by the mismatch in processing speed between the two sides.

[0051] Step S24: Transmit the state feedback signal to the 3D model driving interface to execute the step of driving the 3D model in the virtual simulation scene to generate synchronous actions based on the state feedback signal by calling the 3D model driving interface; It should be noted that the 3D model driving interface refers to a predefined function call interface in the virtual simulation system. Its function is to use the state feedback signals parsed from the raw data stream as input parameters, specifically passing them to the underlying rendering unit responsible for updating the pose and display state of the 3D model. This interface can be implemented, but is not limited to, as a function or method, such as `Drive3DModel(deviceId, stateParams)`. `deviceId` identifies the 3D model component to be driven, such as a motor, tri-color light, or button, while `stateParams` contains the specific state parameters extracted from the state feedback signals, such as rotation angle, color switching instructions, and press height. Once the virtual simulation system successfully extracts the state feedback signals from the raw data stream, it can trigger the specific execution logic of "driving the 3D model in the virtual simulation scene to produce synchronous actions based on the state feedback signals" by calling the 3D model driving interface and passing in the corresponding parameters. This maps the actual output of the physical PLC to the pose changes and display state switching of the 3D model in the virtual scene in real time, achieving precise synchronization between virtual and real actions.

[0052] Step S25: The program running data is transmitted to the assessment interface, so that the simulation assessment result is obtained by comparing the program running data with the preset evaluation criteria by calling the assessment interface.

[0053] It should be noted that the assessment interface refers to a predefined, independent function call interface within the virtual simulation system. Its function is to specifically pass the program execution data parsed from the raw data stream to the assessment engine responsible for performance evaluation. This interface can be implemented, but is not limited to, as a function or method, such as `Evaluate(programRunData)`. `programRunData` contains the internal operating parameters of the entity PLC extracted from the raw data stream, such as the current value of the timer, the cumulative value of the counter, and the trajectory of intermediate variable changes. Once the virtual simulation system successfully extracts the program execution data from the raw data stream, by calling the assessment interface and passing in the corresponding data, it can trigger the specific execution logic of "comparing the program execution data with the preset evaluation criteria to obtain the simulation assessment result." This includes a series of automated evaluation operations such as delay verification to avoid instantaneous errors, physical quantity conversion, and step-by-step differentiated scoring, ultimately generating an objective assessment score or detailed score breakdown, providing accurate performance evaluation criteria for teachers and learners.

[0054] Understandably, by receiving the raw data stream returned by the entity PLC through a bidirectional data buffer queue, parsing and extracting the status feedback signal and program execution data from the raw data stream, and then transmitting the status feedback signal to a dedicated 3D model driver interface to execute 3D model synchronization actions, while transmitting the program execution data to a dedicated assessment interface to perform simulation assessment result comparison, it is possible to effectively avoid functional errors caused by data type mismatch and processing interface mismatch, and achieve decoupled distribution and modular processing of data stream, thereby improving the system's logical clarity, maintainability, and data routing accuracy in the virtual-real collaboration process.

[0055] For example, based on the bidirectional data buffer queue already established between the virtual simulation system and the physical PLC, after the physical PLC receives and executes a timely and qualified control command, it encapsulates the status of its output points (e.g., Q0.0 being 1 indicating the motor is rotating forward) and the current value of its internal timer T37 (e.g., 500 milliseconds) into a continuous binary byte sequence according to the MODBUS TCP protocol, forming a raw data stream. This raw data stream is then written to the write port of the bidirectional data buffer queue through the communication interface. An independent receiving thread runs in the virtual simulation system. This thread obtains the raw data stream from the read port of the bidirectional data buffer queue in a non-blocking manner and then processes it according to the same MODBUS protocol. The TCP protocol format performs frame de-framing and field extraction on the raw data stream. Specifically, it reads two bytes from a specified offset position of the data frame, parses them into a Boolean value to obtain a status feedback signal (e.g., Q0.0=1), and then reads two bytes from a subsequent offset position, parses them into a 16-bit integer to obtain program execution data (e.g., T37=500). The virtual simulation system then calls a 3D model driver interface called Drive3DModel, passing in the device identifier "Motor" and the status parameter "speed = 300 rpm". Internally, this interface calculates the rotation angle increment of the motor model based on the status parameter and updates its Transform component, causing the 3D motor model in the virtual scene to begin rotating at a constant speed. Simultaneously, the virtual simulation system calls an evaluation interface called EvaluateScore, passing in the T37 value from the program execution data. Internally, this interface compares this value with preset evaluation criteria (e.g., requiring the timer to run between 450 and 550 milliseconds after motor startup), determines the score for this item, and accumulates it into the total score. Finally, the simulation evaluation result for this operation is displayed on the interface.

[0056] In one feasible implementation, the step S30, which involves driving the 3D model in the virtual simulation scene to generate synchronized actions based on the state feedback signal, may include steps S31 to S33: Step S31: Parse the device identifier and status parameters from the status feedback signal; It should be noted that the device identifier refers to the unique identification code or name obtained from the status feedback signal, used to uniquely identify a 3D model or its partial component in the virtual simulation scene. This identifier can be a string (such as "Motor_Left", "Red_Lamp"), an integer ID (such as 1 for a motor, 2 for a tri-color lamp), or other hashable data types. This identifier information can be implicitly or explicitly included in the status feedback signal returned by the physical PLC. For example, status feedback signals from different output ports of the physical PLC can be pre-mapped to different device identifiers. By extracting the device identifier, the virtual simulation system can quickly locate the specific object that needs to be driven in a large scene containing multiple 3D models, avoiding the performance loss caused by traversing all models, and providing accurate target pointing for subsequent pose transformations or display state switching.

[0057] State parameters are specific numerical or enumerated values ​​obtained from state feedback signals, describing the motion or appearance changes that a 3D model component corresponding to a device identifier should exhibit. State parameters can be continuous quantities (e.g., a motor rotation angle of 30 degrees, a movement distance of 5 centimeters, or an analog voltage of 2.5 volts), discrete quantities (e.g., a Boolean value of 1 indicating a tri-color light is on, and 0 indicating it is off), or enumerated states (e.g., "forward rotation," "reverse rotation," and "stop"). These parameters directly reflect the physical meaning of the actual electrical signal output from the physical PLC after dimensional conversion. For example, if a physical PLC outputs a 0-10V analog signal corresponding to the speed command of a strain gauge, after analysis, the state parameter "speed = 1500 rpm" is obtained. State parameters are the core input basis for calculating the target pose transformation matrix or determining the display state switching command.

[0058] Step S32: Based on the device identifier, retrieve and locate the corresponding model component in the 3D model, and calculate the target pose transformation matrix of the model component and / or display the state switching command based on the state parameters; It's important to note that a model component refers to the smallest independently controllable unit of a 3D model in a virtual simulation scene, corresponding to a specific mechanical or electrical component in a real device driven by a physical PLC. A complete 3D model (such as a robotic arm) can consist of multiple model components, such as a base, upper arm, forearm, wrist, and gripper. Each model component has independent pose (e.g., position and rotation) and display attributes (e.g., visibility, material color, texture mapping). Based on the device identifier parsed from the status feedback signals, the virtual simulation system can retrieve and locate the corresponding model component in the hierarchical tree structure of the 3D model. For example, if the device identifier is "Gripper," the gripper component is located; if the device identifier is "Indicator_Lamp," the indicator light component is located. The independently controllable nature of model components allows for precise virtual-real synchronization down to each active unit within the device.

[0059] The target pose transformation matrix can be a 4×4 mathematical matrix (represented in homogeneous coordinates) used to describe the rotation, translation, and scaling operations required for a model component to transform from its current pose to the target pose. This matrix is ​​calculated kinematically based on state parameters (such as the target rotation angle of a motor or the target extension length of a cylinder). For example, when the state parameter indicates that the motor needs to rotate 90 degrees, the system calculates the rotation matrix for rotating 90 degrees around a specific axis and multiplies it by the current world transformation matrix of the model component to obtain the target pose transformation matrix. After applying this matrix to the transformation component of the model component (such as the Transform component in Unity3D), the model component will smoothly or instantaneously move to the target position and pose, thereby accurately reproducing the motion trajectory of a real device under the control of a physical PLC in the virtual scene.

[0060] Display state switching instructions are non-pose-related control commands used to change the visual appearance of a model component without altering its spatial position or rotation angle. Display state switching instructions may include, but are not limited to: material color switching (e.g., changing the luminous material of a tri-color light model from gray to red), texture mapping switching (e.g., changing the surface texture of a button model from a raised state to a pressed state), visibility switching (e.g., hiding or showing a protective shield model), animation state triggering (e.g., playing the opening and closing animation of a robotic arm gripper), and modifications to rendering parameters such as transparency and self-illumination intensity. When the state parameters parsed from the state feedback signal are discrete or enumerated (e.g., light on / off, button pressed / released), the system generates the corresponding display state switching instruction, rather than a pose transformation matrix. After applying this instruction to the model component, the display appearance of the model component changes immediately, thus visually synchronizing with the actual responses of non-motion devices such as indicator lights and buttons driven by the physical PLC output.

[0061] Step S33: Apply the target pose transformation matrix and / or display state switching command to the model component to update the pose and / or display state of the model component.

[0062] It is understandable that in complex 3D scenes containing multiple devices, each composed of multiple movable parts, directly driving all models or parts uniformly may lead to incorrect parts moving, movements that do not match the actual devices, or an inability to distinguish between pose changes such as rotation / translation and display switches such as light color / material, resulting in asynchronous virtual and real movements or even severe visual distortion. Therefore, this embodiment further parses the device identifier and state parameters from the state feedback signal, retrieves and locates the corresponding model parts in the 3D model based on the device identifier, and calculates the target pose transformation matrix and / or display state switching command that the model parts should present based on the specific value or type of the state parameters. Then, it applies the matrix and / or command to the model parts to update their pose and / or display state, thereby avoiding the multi-device crosstalk and motion distortion problems caused by the lack of fine part-level positioning and motion type differentiation. This achieves classified and high-precision synchronous driving of spatial movement and appearance display of multiple independent model parts in complex virtual scenes, improving the visual fidelity and motion consistency of virtual and real collaboration.

[0063] For example, in a virtual simulation scenario, there exists a 3D model of a motor constructed based on the 3D dimension data of a physical stepper motor. This model includes a rotor model component that can rotate independently. After the physical PLC executes the control command, its output port returns a status feedback signal as a data frame, which carries the device identifier "StepperMotor_Rotor" and the status parameter "target rotation angle = 90 degrees". After parsing the device identifier and status parameter from this status feedback signal, the virtual simulation system searches in the hierarchical tree of the 3D model using the device identifier as the key, locating the model component named "Rotor". Subsequently, based on the target rotation angle of 90 degrees in the status parameter, the system calculates a rotation matrix for rotating 90 degrees around the motor axis (i.e., the Y-axis of the local coordinate system) as the target pose transformation matrix. The system applies this matrix to the Transform component of the model component, updating its local rotation attributes, so that the rotor model component smoothly rotates from the current angle to a 90-degree position in the virtual scene, thereby accurately synchronizing with the actual spatial position changes of the physical stepper motor.

[0064] For example, in a virtual simulation scenario, there exists a 3D model constructed based on a real tri-color lamp. This model contains three independent lampshade model components: red, green, and blue. When the output point Q0.0 of the physical PLC changes from 0 to 1, the status feedback signal returned by the physical PLC carries the device identifier "RedLamp_Cover" and the status parameter "lit state = 1". After parsing the above information, the virtual simulation system locates the red lampshade model component in the 3D model based on the device identifier "RedLamp_Cover". Since the status parameter is a discrete Boolean quantity rather than a continuous pose quantity, the system determines that a display state switching instruction needs to be executed. Therefore, it calculates and generates an instruction: "Switch the color of the self-illuminating material of the model component to red, set the self-illumination intensity to 2.0, and switch the diffuse texture to a bright texture." The system applies this display state switching instruction to the material attribute unit of the red lampshade model component, and the lampshade appearance immediately changes from a gray off state to a red bright state, thus visually synchronizing with the display state change of the physical PLC driving the real red lamp to light up.

[0065] For example, in a virtual simulation scenario, there exists a 3D model constructed based on a real pneumatic robotic arm. This model contains multiple model components, among which joint 2 requires both rotational movement and the display of a clamping status indicator light at the gripper. The status feedback signal returned by the physical PLC is a composite data frame, which, after parsing, yields the device identifier "Arm_Joint2" and a set of status parameters: rotation angle = 45 degrees, gripper indicator light = 1. The system locates the model component of joint 2 based on the device identifier, then calculates the target pose transformation matrix for rotation around the local Z-axis of the joint based on the rotation angle of 45 degrees in the status parameters. Simultaneously, based on gripper indicator light = 1, it generates a display status switching command: "Switch the material color of the small LED model component on the gripper base to green." The system applies the target pose transformation matrix to the Transform component of the joint 2 model component, causing it to rotate 45 degrees, and simultaneously applies the display status switching command in parallel to the material module of the LED model component, illuminating the green indicator light. Thus, while the robotic arm joint 2 in the virtual simulation scene is rotating in space, its gripper indicator light also switches its display status synchronously, completely replicating the composite action effect of the physical PLC driving the real robotic arm to move and lighting up the indicator light.

[0066] In one feasible implementation, the step S30, which compares the program execution data with a preset evaluation standard to obtain the simulation assessment result, may include steps S34-S36: Step S34: Perform physical quantity conversion on the original values ​​in the program running data to obtain the actual physical quantities in the target numerical format; It should be noted that raw values ​​refer to the initial numerical representation of the program execution data returned by the physical PLC before any dimensional conversion or engineering unit conversion. The data processed internally by the physical PLC can be, but is not limited to, binary two's complement, hexadecimal integer, BCD code, or raw A / D conversion values. For example, an analog input module directly converts a 4-20mA current signal into an integer value of 0-27648, or a temperature sensor outputs a raw hexadecimal value of 0x01F4. While these raw values ​​can be directly used by the PLC's internal logic operations, they lack intuitive physical meaning (such as temperature, pressure, speed, etc.) for the evaluation system. In this embodiment, the raw values ​​are the input basis for performing the physical quantity conversion step. The system needs to convert them into readable actual physical quantities according to a preset range conversion formula or calibration parameters before a meaningful comparison can be made with the theoretical values ​​in the preset evaluation criteria.

[0067] Actual physical quantities are quantified results obtained by mathematically transforming raw values ​​according to specific conversion formulas or calibration curves, resulting in definite engineering units (such as degrees Celsius, millimeters per second, revolutions per minute, Pascals, etc.). For example, a raw value of 1250 returned from a temperature sensor is converted to 12.5 degrees Celsius using the formula "actual temperature = raw value × 0.01", or a raw value of 16384 returned from an analog output module is converted to approximately 1777 revolutions per minute using the formula "actual speed = raw value × 3000 / 27648". The introduction of actual physical quantities solves the problem of unit mismatch and dimension inconsistency between raw values ​​and theoretical values ​​in preset evaluation standards, enabling the assessment system to evaluate the correctness of program operation data in an understandable and physically consistent way. For example, it may require "motor speed should be between 1450 and 1550 revolutions per minute" instead of requiring "raw value should be between 13344 and 14280".

[0068] Step S35: Collect the stable value of the actual physical quantity according to the preset delay time, and compare the stable value with the theoretical value of each assessment item in the preset evaluation criteria to obtain the deviation value of each assessment item. It should be noted that a stable value refers to the value selected to represent the steady-state response of a system after continuously collecting multiple samples within a preset delay time specified by the delay verification mechanism for a specific physical quantity. In real industrial environments, sensor signals or actuator responses often exhibit noise fluctuations, overshoot, or oscillations during transient processes. For example, the speed of a motor may spike and then drop immediately upon startup, or a temperature sensor may require a certain amount of time to stabilize after a step change. If instantaneous values ​​are read directly without a delay, accidental spikes or glitches may lead to misjudgments in the assessment. This implementation method collects stable values ​​of actual physical quantities according to a preset delay time, for example, setting the delay time to 500 milliseconds. After the system extracts the actual physical quantity from the program execution data returned by the physical PLC, it waits 500 milliseconds before reading the final value of that quantity, or it samples multiple times during this delay period and takes the average or median value as the stable value. This effectively avoids the interference of instantaneous errors on the scoring results and ensures that the data used for assessment truly reflects the actual operating performance of the equipment under steady-state conditions.

[0069] Step S36: Calculate the total simulation assessment score based on each deviation value and the preset scoring weight, and use the total simulation assessment score as the simulation assessment result.

[0070] It should be noted that the simulation assessment score is a single score that quantifies the user's overall performance in this simulation training by weighting and summing or comprehensively calculating the deviation values ​​of each assessment item according to preset scoring weights. Specifically, the system first converts the raw values ​​in the program's running data into actual physical quantities, and extracts stable values ​​after delay verification. Then, it compares these stable values ​​with the theoretical values ​​of each assessment item in the preset evaluation criteria, calculating the deviation value of each assessment item (e.g., absolute error, relative error, or deduction for logical correctness). Each assessment item has a pre-set corresponding weight coefficient or full score. The system determines the score for that item based on the deviation value (e.g., full score for complete correctness, proportional deduction for deviations within the tolerance range, and zero score for deviations exceeding the tolerance range). Finally, the scores of all assessment items are summed or weighted to obtain the simulation assessment score. This total score is usually presented in a percentage or per mille format and can be used directly as an objective basis for evaluating students' training performance, or it can be used in engineering debugging to determine whether the control program meets the design requirements.

[0071] It is understandable that directly using unconverted raw values ​​for comparison would cause the assessment results to deviate from the true physical meaning. Collecting instantaneous values ​​might lead to misjudgments due to spikes or glitches at startup. Applying the same weight to all assessment items would fail to reflect the differences in importance between different operational steps. Therefore, this implementation further converts the raw values ​​in the program's running data into physical quantities to obtain actual physical quantities with engineering units. Then, based on a preset delay time, it collects stable values ​​of these actual physical quantities under steady-state conditions to avoid interference from instantaneous errors. These stable values ​​are then compared item by item with the theoretical values ​​of each assessment item in the preset evaluation criteria to obtain each deviation value. Finally, the simulation assessment total score is calculated based on each deviation value and the preset scoring weights. This avoids the problem of invalid comparisons due to dimensional mismatch, eliminates the interference of noise fluctuations during transient processes on the scoring, and achieves differentiated weighted comprehensive evaluation of multiple assessment items, thereby improving the objectivity and precision of the simulation assessment results.

[0072] For example, after the physical PLC completes the motor forward and reverse rotation control training, the program execution data received by the system includes a raw value "0x01F4" (e.g., hexadecimal, corresponding to decimal 500). This raw value represents the current count value of timer T37. The system converts the raw value "0x01F4" into the actual physical quantity "500 milliseconds" according to the preset physical quantity conversion strategy. Subsequently, the system starts the delay verification mechanism, setting the preset delay time to 200 milliseconds, that is, waiting for 200 milliseconds before reading the value of the timer again. At this time, the stable value read is 502 milliseconds (because the actual motor inertia causes the timer to exceed slightly). The system compares this stable value of 502 milliseconds with the "motor start time" in the preset evaluation criteria. The theoretical value of the core item is compared with 500 milliseconds, and the deviation value is calculated to be +2 milliseconds. At the same time, the system will repeat the above conversion, delay acquisition and comparison process for other assessment items (such as forward and reverse switching sequence, overload protection action value, etc.) to obtain their respective deviation values. According to the preset scoring weights (e.g., startup time accounts for 30%, switching sequence accounts for 50%, overload protection accounts for 20%), the system maps each deviation value to a score (e.g., a startup time deviation of 2 milliseconds within the allowable tolerance of ±5 milliseconds gets a full score of 30 points, a correct switching sequence gets 50 points, and an overload protection deviation exceeding the range gets 0 points). Finally, the weighted calculation yields a total simulation assessment score of 80 points (e.g., a full score of 100 points), and the total score is displayed on the training interface as the simulation assessment result of this operation.

[0073] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2The step S10, which involves converting the virtual operation signal into a control instruction recognizable by a physical programmable logic controller based on a preset input / output point mapping relationship, may include steps S11 to S13: Step S11: Parse the virtual port identifier and signal value corresponding to the virtual operation signal; It's important to note that a virtual port identifier is a code or name used to uniquely identify a virtual input or output port in a virtual simulation scenario. This identifier corresponds to a graphical element that the user interacts with in the virtual environment, such as a virtual button, virtual switch, virtual sensor, or a touch area on a virtual touchscreen. Internally, each interactive virtual element is assigned a unique virtual port identifier, such as "Virt_Button_Start" or "I0.0_Virtual". When a user clicks a virtual button in the virtual simulation scenario, the system captures the action and parses the corresponding virtual port identifier, which is then used to find the physical PLC port bound to that virtual port in the input / output point mapping relationship. The design of the virtual port identifier decouples the operating elements on the virtual side from the hardware ports on the physical side. Users can flexibly change the correspondence between virtual elements and physical ports by reconfiguring the mapping relationship without modifying the physical PLC wiring.

[0074] Signal values ​​are specific data extracted from virtual operation signals, representing the current state or input value of a virtual port. The data type of the signal value depends on the nature of the virtual component. For example, for discrete components such as buttons and switches, the signal value can be Boolean, with 1 indicating pressed or closed, and 0 indicating released or open. For continuous components such as knobs, sliders, and analog input boxes, the signal value can be integer or floating-point, with floating-point numbers between 0 and 10 representing voltage settings, or integers between 0 and 27648 representing the original analog value. The signal value directly reflects the quantified result of the user's interactive actions in the virtual scene. For example, when the user rotates the virtual speed control knob to 75%, the system collects a signal value of 0.75 or 75. This signal value is sent to the signal conversion strategy module, where it undergoes necessary format transformations to generate the target operation signal, which is then transmitted to the physical PLC.

[0075] Step S12: Using the virtual port identifier as an index, query the corresponding physical port identifier and signal conversion strategy in the input / output point mapping relationship; It's important to note that a physical port identifier is an address code or symbolic name used on a physical PLC to identify a specific input or output physical port. Different PLC brands and models use different addressing methods. For example, in one brand of PLC, digital input points might be addressed as %I0.0, %I0.1, etc., digital output points as %Q0.0, %Q0.1, etc., and analog inputs as %IW64, %IW66, etc.; another brand might use X0, X1 to represent inputs and Y0, Y1 to represent outputs. The physical port identifier is the sole basis for identifying the source and destination of signals at the physical PLC hardware level. In the input / output point mapping relationship, each virtual port identifier corresponds to one or more physical port identifiers. When the system queries the mapping relationship using a virtual port identifier as an index, the result includes the physical port identifier to which the virtual operation signal should be sent. Subsequent control instructions will include this identifier, enabling the physical PLC to correctly route instructions to the corresponding physical port or data register.

[0076] Signal conversion strategies are predefined data processing schemes for the mapping relationship between a specific pair of virtual and physical ports. They convert signal values ​​acquired from the virtual side into target operation signals that the physical PLC can correctly recognize and receive. Signal conversion strategies may include, but are not limited to: data type conversion (e.g., converting Boolean 1 / 0 to TRUE / FALSE in bit setting commands, or converting floating-point 0.0-1.0 to integer 0-27648), range scaling (e.g., scaling a virtual knob's 0-100% range to the digital value 5530-27648 corresponding to 4-20mA), logic inversion (e.g., when a virtual button is pressed, the signal value is 1, but the physical PLC requires a low-level active signal, so it is inverted to 0), nonlinear mapping (e.g., converting angle values ​​to voltage values ​​according to a preset curve), and unit conversion (e.g., converting millimeters to pulse counts). The introduction of signal conversion strategies solves the problem of the difference between the user-friendly interactive dimensions in the virtual scene and the signal format required by the physical PLC hardware, ensuring that the converted target operation signal is physically equivalent to the effect of direct input from the real hardware.

[0077] Step S13: Convert the signal value into a target operation signal in the target data format according to the signal conversion strategy, and form the control command based on the target operation signal and the entity port identifier.

[0078] It should be noted that the target operation signal is the final data value obtained after processing the original signal value in the virtual operation signal through a signal conversion strategy, conforming to the input format and dimensional requirements of the physical PLC. The data type, value range, and precision of the target operation signal perfectly match the specifications expected by the physical PLC when receiving external inputs. For example, for digital input points, the target operation signal is a Boolean value (e.g., 0 or 1); for analog input channels, the target operation signal is a 16-bit integer (e.g., 0-27648) or a floating-point number. The target operation signal, together with the physical port identifier, constitutes the control instructions recognizable by the physical PLC. The physical port identifier specifies the target address to which the signal should be written, and the target operation signal is the specific value to be written to that address. By generating the target operation signal, the virtual simulation system can simulate the electrical signals or data values ​​sent by real hardware devices (e.g., buttons, sensors, transmitters) to the physical PLC, thereby driving the physical PLC to operate according to predetermined control logic.

[0079] Understandably, by parsing virtual operation signals to obtain virtual port identifiers and signal values, and using these virtual port identifiers as indexes to look up the corresponding physical port identifiers and signal conversion strategies in the input / output point mapping relationship, the original signal values ​​are then converted into target operation signals conforming to the target data format according to the signal conversion strategy. Finally, the target operation signals and physical port identifiers together form control instructions. This avoids the problem of incorrect instruction issuance due to unclear port correspondence, as well as the problem of physical PLC parsing failure or execution abnormality due to mismatched signal dimensions or data types. Thus, it simultaneously achieves flexible adaptation to different PLC models and different signal formats, thereby improving the accuracy, universality, and configurability of the virtual-to-physical conversion process.

[0080] For example, a virtual button for controlling motor start is set in the virtual simulation scenario. This button is assigned the virtual port identifier "Virt_Start_Btn". When the user clicks the virtual button with the mouse, the system collects the virtual operation signal, parses out the virtual port identifier "Virt_Start_Btn", and the signal value is a Boolean value of 1 (indicating a pressed state). The system then reads the input / output point mapping table pre-configured through the graphical interface. This table records that the physical port identifier corresponding to the virtual port "Virt_Start_Btn" is a certain brand of PLC. The digital input address "%I0.0" is bound to a signal conversion strategy of "direct mapping (Boolean value 1 → TRUE)". Based on this signal conversion strategy, the system directly converts the original signal value 1 into the target operation signal TRUE (indicating that the data format conforms to the bit addressing of a certain brand of PLC). Finally, the system combines the physical port identifier "%I0.0" with the target operation signal TRUE into a complete control instruction, such as a write request under the S7 communication protocol, and sends it to the physical PLC through the communication interface, thereby simulating the effect of sending a high-level signal to the PLC input point I0.0 when a real button is pressed.

[0081] In this embodiment, the virtual operation signal is first parsed to obtain the virtual port identifier and signal value. Then, the corresponding physical port identifier and signal conversion strategy are queried in the mapping relationship using the virtual port identifier as an index. The original signal value is then converted into a target operation signal that conforms to the target data format according to the signal conversion strategy. Finally, the target operation signal and the physical port identifier are combined to form a control command. This avoids problems such as incorrect correspondence between virtual and physical ports, mismatch of signal dimensions, and poor compatibility of different PLC data formats that may be caused by direct fuzzy mapping. At the same time, it realizes accurate, flexible and configurable conversion from virtual side user-friendly operation to physical PLC hardware-level signal format, thereby improving the accuracy, adaptability and maintainability of the virtual-physical mapping process.

[0082] In one feasible implementation, after the step of acquiring virtual operation signals in the virtual simulation scene described in step S10, steps S01 to S04 may also be included: Step S01: Read the configuration data block storing the input / output point mapping relationship and obtain the binary sequence of the configuration data block, wherein the binary sequence consists of a target data segment and a preset cyclic redundancy check code; It should be noted that a configuration data block is a structured data unit used to persistently store the mapping relationship between input / output points. It can exist, but is not limited to, in file form (such as binary configuration files, JSON files, XML files) or a fixed area in memory. This configuration data block contains at least two parts: first, the target data segment, which is the effective data payload that actually records the mapping relationship between virtual port identifiers, physical port identifiers, and signal conversion strategies; second, a pre-set cyclic redundancy check (CRC) code, which is a checksum calculated using a CRC algorithm based on the content of the target data segment when the configuration data block is generated or before each write to the storage medium, and appended to the target data segment. When the system needs to perform virtual-physical mapping, it first reads this configuration data block, extracts the binary sequence from it, and verifies whether bit errors have occurred in the target data segment during storage or transmission using the checksum. The introduction of the configuration data block ensures the integrity and reliability of the mapping relationship, preventing erroneous mappings caused by data corruption.

[0083] The binary sequence is a string of 0s and 1s obtained after reading the configuration data block as a raw byte stream. Structurally, this binary sequence is divided into two consecutive segments: the first few bytes constitute the target data segment, storing the actual configuration content of the input / output point mapping relationship, such as each mapping entry containing a virtual port name string, an integer value for the physical port address, and an enumerated value for the conversion strategy; the following few bytes (e.g., 2 bytes, 4 bytes, or 8 bytes) constitute a preset cyclic redundancy check (CRC) code, used to verify the integrity of the target data segment. The binary sequence is the direct target of the verification algorithm. When reading the configuration data block, the system obtains the complete binary sequence and separates the target data segment and the preset CRC code from it for subsequent verification and comparison operations.

[0084] Step S02: Calculate the actual cyclic redundancy check code of the target data segment, and compare the actual cyclic redundancy check code with the preset cyclic redundancy check code; It should be noted that the actual cyclic redundancy check (CRCD) code refers to the check value recalculated by the system after reading the configuration data block and obtaining the binary sequence, specifically for the target data segment portion of the binary sequence, using the same CRCD algorithm (e.g., CRC-16, CRC-32, etc.) as when generating the preset CRCD code. This actual CRCD code reflects the true binary content of the target data segment at the current reading moment. The system compares the actual CRCD code bit by bit with the preset CRCD code stored at the end of the binary sequence: if they are completely identical, it means that the target data segment has not experienced data corruption or bit flipping during storage or transmission, the verification passes, and the mapping relationship can be safely used to perform subsequent virtual operation signal conversions; if they are inconsistent, it means that the target data segment has experienced data errors, and the mapping relationship must be rejected. The calculation of the actual CRCD code is the core step in realizing self-verification of data integrity.

[0085] Step S03: If the actual cyclic redundancy check code and the preset cyclic redundancy check code are consistent, the check is determined to be successful, and the virtual port identifier and signal value corresponding to the virtual operation signal are parsed. Step S04: If the actual cyclic redundancy check code and the preset cyclic redundancy check code are inconsistent, the check fails, a mapping error signal is output, and the step of parsing the virtual port identifier and signal value corresponding to the virtual operation signal is canceled.

[0086] It should be noted that the mapping error signal is a clearly defined status indication signal output by the system when it determines that the actual cyclic redundancy check (CRC) code is inconsistent with the preset CRC code. This signal can be implemented in various forms, such as setting a global error flag to 1, throwing a custom exception object, logging a "CRC check failed" error message in the log, or displaying a warning dialog box on the graphical user interface displaying "Point mapping configuration file is corrupted, please reconfigure." The output of the mapping error signal triggers subsequent actions, namely canceling the step of parsing the virtual port identifier and signal value corresponding to the virtual operation signal. This prohibits any virtual-to-real conversion operations using the corrupted mapping relationship, thereby preventing control commands from being sent to the wrong physical port or generating incorrect target operation signals due to incorrect mapping relationships, avoiding the risk of malfunction of the physical PLC or even equipment damage. The timely output of the mapping error signal also provides users with a clear fault indication, guiding them to check and reconfigure the mapping relationship.

[0087] It is understandable that if the system directly uses the input / output point mapping relationship as the basis for executing the parsing and conversion of virtual operation signals, but does not perform any verification of the data integrity of the mapping relationship during storage or transmission, and bit errors occur in the configuration data block due to file corruption, storage medium bit flipping, network transmission packet loss, etc., the system may use the wrong virtual port to physical port correspondence or the wrong signal conversion strategy without knowing it, thereby generating wrong control commands and sending them to the physical PLC, causing the physical PLC to drive the wrong actuator to act, or even causing equipment damage or safety accidents. To address this potential risk, this embodiment further reads the binary sequence of the configuration data block storing the input / output point mapping relationship. This sequence consists of a target data segment and a preset cyclic redundancy check (CRC) code. The actual CRC code of the target data segment is calculated and compared with the preset CRC code. The subsequent virtual port identifier and signal value parsing steps are only executed if the verification matches. If the verification does not match, a mapping error signal is output and execution is canceled. This avoids the problem of incorrect mapping and incorrect control commands due to corrupted configuration data, realizes automatic verification of the integrity of the mapping relationship and fault warning, thereby improving the security and data reliability of the virtual-to-real conversion process.

[0088] For example, each time the virtual simulation system starts up or after each virtual operation signal is acquired, the system first reads a configuration data block named "plc_mapping.bin" from local storage. The first 512 bytes of this data block are the target data segment, which records the physical PLC port "%Q0.0" corresponding to the virtual button "Virt_Button_A" and the signal conversion strategy as "Boolean value inversion". The next 2 bytes are a preset cyclic redundancy check code (calculated using the CRC-16 algorithm, for example, 0x8F3C). The system obtains the complete binary sequence of this configuration data block and separates the target data segment and the preset CRC-16 code from it. The system performs a CRC-16 checksum calculation and then recalculates the actual cyclic redundancy checksum using the same CRC-16 algorithm on the target data segment. If the actual calculated checksum is also 0x8F3C, the checksum passes, and the system continues to parse the virtual port identifier and signal value in the virtual operation signal. If the actual checksum is another value (e.g., 0xA12D), the checksum fails, and the system immediately outputs a mapping error signal on the interface (e.g., a dialog box pops up saying "Configuration file verification failed, please check the mapping relationship"), and cancels all subsequent steps of parsing the virtual port identifier and signal value, thereby avoiding the use of a corrupted mapping relationship that would cause the physical PLC to receive incorrect control commands.

[0089] For example, to help understand the implementation flow of the controller virtual simulation method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 3 , Figure 3 A simplified flowchart of a controller virtual simulation method is provided, specifically: First, virtual operation signals from the virtual simulation scene are acquired and converted into control instructions recognizable by the physical PLC based on the pre-configured input / output point mapping relationship. Then, a timestamp is appended to the control instruction, and it is transmitted to the physical PLC via a bidirectional data buffer queue. The physical PLC determines whether the data has timed out based on the timestamp; if it has, a retransmission mechanism is triggered; otherwise, the instruction is executed and the original data stream is returned. The system separates the status feedback signal and program execution data from the original data stream. On one hand, the status feedback signal is used to drive the 3D model constructed based on the 3D dimensions of the physical device to generate synchronous actions (including pose changes and display status switching). On the other hand, the program execution data is converted into physical quantities, and the delay stability value is collected and compared item by item with the preset evaluation criteria. The weighted calculation yields the total simulation assessment score.

[0090] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the virtual simulation method of the controller in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0091] This application also provides a controller virtual simulation system; please refer to... Figure 4 The controller virtual simulation system includes: The signal mapping module 10 is used to convert the virtual operation signal into control instructions that can be recognized by the physical programmable logic controller according to the preset input-output point mapping relationship. The signal transmission module 20 is used to transmit the control command to the physical programmable logic controller and receive the status feedback signal and program running data returned by the physical programmable logic controller based on the control command. The simulation assessment module 30 is used to drive the three-dimensional model in the virtual simulation scene to generate synchronous actions according to the state feedback signal, and compare the program running data with the preset evaluation criteria to obtain the simulation assessment result. The three-dimensional model is constructed based on the three-dimensional size data of the physical programmable logic controller and the external device corresponding to the physical programmable logic controller.

[0092] Optionally, the signal mapping module 10 is further configured to: Parse the virtual port identifier and signal value corresponding to the virtual operation signal; Using the virtual port identifier as an index, the corresponding physical port identifier and signal conversion strategy are queried in the input / output point mapping relationship; The signal value is converted into a target operation signal in the target data format according to the signal conversion strategy, and the control command is formed based on the target operation signal and the entity port identifier.

[0093] Optionally, the signal mapping module 10 is further configured to: Read the configuration data block storing the input / output point mapping relationship, and obtain the binary sequence of the configuration data block, wherein the binary sequence consists of a target data segment and a preset cyclic redundancy check code; Calculate the actual cyclic redundancy check code of the target data segment, and compare the actual cyclic redundancy check code with the preset cyclic redundancy check code; If the actual cyclic redundancy check code and the preset cyclic redundancy check code are consistent, the check is deemed to be successful, and the process of parsing the virtual port identifier and signal value corresponding to the virtual operation signal is executed. If the actual cyclic redundancy check code and the preset cyclic redundancy check code are inconsistent, the check is deemed to have failed, a mapping error signal is output, and the step of parsing the virtual port identifier and signal value corresponding to the virtual operation signal is canceled.

[0094] Optionally, the signal transmission module 20 is further configured to: The control command is encapsulated into a data frame to be transmitted, and a timestamp is added to the data frame to be transmitted to obtain the first target data frame. The first target data frame is written non-blockingly to the write port of the bidirectional data buffer queue, so that the entity programmable logic controller reads the second target data frame from the read port of the bidirectional data buffer queue. If the difference between the timestamp of the second target data frame and the current system time exceeds a preset time limit, a retransmission request signal is returned. If the difference does not exceed the preset time limit, the control instruction is executed, and the status feedback signal and the program running data are returned. The retransmission request signal is used to request that the first target data frame be rewritten non-blockingly to the write port.

[0095] Optionally, the signal transmission module 20 is further configured to: The system receives the raw data stream returned by the physical programmable logic controller through a bidirectional data buffer queue, and extracts the status feedback signal and the program execution data from the raw data stream. The state feedback signal is transmitted to the 3D model driving interface so that the step of driving the 3D model in the virtual simulation scene to generate synchronous actions based on the state feedback signal can be executed by calling the 3D model driving interface. The program execution data is transmitted to the assessment interface, and the step of comparing the program execution data with the preset evaluation criteria and obtaining the simulation assessment result is executed by calling the assessment interface.

[0096] Optionally, the simulation assessment module 30 is further used for: The device identifier and status parameters are obtained by parsing the status feedback signal; Based on the device identifier, the corresponding model component is retrieved and located in the 3D model, and based on the state parameters, the target pose transformation matrix of the model component and / or the display state switching command is calculated. The target pose transformation matrix and / or display state switching command are applied to the model component to update the pose and / or display state of the model component.

[0097] Optionally, the original values ​​in the program execution data are converted into physical quantities to obtain the actual physical quantities in the target numerical format; The stable value of the actual physical quantity is collected according to the preset delay time, and the stable value is compared with the theoretical value of each assessment item in the preset evaluation criteria to obtain the deviation value of each assessment item. The simulation assessment total score is calculated based on each deviation value and the preset scoring weight, and the simulation assessment total score is used as the simulation assessment result.

[0098] The controller virtual simulation system provided in this application, employing the controller virtual simulation method described in the above embodiments, can solve the technical problem of simultaneously achieving realism and flexibility in PLC teaching and engineering debugging. Compared with the prior art, the beneficial effects of the controller virtual simulation system provided in this application are the same as those of the controller virtual simulation method provided in the above embodiments, and other technical features of the controller virtual simulation system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0099] This application provides an electronic 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, the instructions being executed by the at least one processor to enable the at least one processor to perform the controller virtual simulation method in Embodiment 1 above.

[0100] The following is for reference. Figure 5The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0101] like Figure 5 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0102] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0103] The electronic device provided in this application, employing the controller virtual simulation method described in the above embodiments, can solve the technical problem of simultaneously achieving realism and flexibility in PLC teaching and engineering debugging. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the controller virtual simulation method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0104] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0105] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0106] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the controller virtual simulation method in the above embodiments.

[0107] 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 or 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 (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage 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 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, RF (Radio Frequency), etc., or any suitable combination thereof.

[0108] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0109] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by an electronic device, the electronic device causes the electronic device to: acquire virtual operation signals in a virtual simulation scene, and convert the virtual operation signals into control instructions recognizable by a physical programmable logic controller (PLC) according to a preset input / output point mapping relationship; transmit the control instructions to the PLC, and receive status feedback signals and program running data returned by the PLC based on the control instructions; drive the three-dimensional model in the virtual simulation scene to generate synchronous actions according to the status feedback signals, and compare the program running data with preset evaluation criteria to obtain simulation evaluation results. The three-dimensional model is constructed based on the three-dimensional dimension data of the PLC and the corresponding external device.

[0110] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language 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).

[0111] 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.

[0112] 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.

[0113] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described controller virtual simulation method. This solves the technical problem of simultaneously achieving realism and flexibility in PLC teaching and engineering debugging. 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 controller virtual simulation method provided in the above embodiments, and will not be elaborated upon here.

[0114] The above description is only a part of the embodiments of this application and does 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 virtual simulation method for a controller, characterized in that, The controller virtual simulation method includes: The system collects virtual operation signals from a virtual simulation scenario and converts these signals into control commands that can be recognized by a physical programmable logic controller (PLC) based on a preset input / output point mapping relationship. The control command is transmitted to the physical programmable logic controller, and the status feedback signal and program running data returned by the physical programmable logic controller based on the control command are received. The state feedback signal drives the three-dimensional model in the virtual simulation scene to generate synchronous actions, and the program running data is compared with the preset evaluation criteria to obtain the simulation evaluation result. The three-dimensional model is constructed based on the three-dimensional size data of the physical programmable logic controller and the external device corresponding to the physical programmable logic controller.

2. The controller virtual simulation method as described in claim 1, characterized in that, The step of converting the virtual operation signal into a control instruction recognizable by a physical programmable logic controller according to a preset input / output point mapping relationship includes: Parse the virtual port identifier and signal value corresponding to the virtual operation signal; Using the virtual port identifier as an index, the corresponding physical port identifier and signal conversion strategy are queried in the input / output point mapping relationship; The signal value is converted into a target operation signal in the target data format according to the signal conversion strategy, and the control command is formed based on the target operation signal and the entity port identifier.

3. The controller virtual simulation method as described in claim 2, characterized in that, Following the step of acquiring virtual operation signals in the virtual simulation scenario, the following also applies: Read the configuration data block storing the input / output point mapping relationship, and obtain the binary sequence of the configuration data block, wherein the binary sequence consists of a target data segment and a preset cyclic redundancy check code; Calculate the actual cyclic redundancy check code of the target data segment, and compare the actual cyclic redundancy check code with the preset cyclic redundancy check code; If the actual cyclic redundancy check code and the preset cyclic redundancy check code are consistent, the check is deemed to be successful, and the process of parsing the virtual port identifier and signal value corresponding to the virtual operation signal is executed. If the actual cyclic redundancy check code and the preset cyclic redundancy check code are inconsistent, the check is deemed to have failed, a mapping error signal is output, and the step of parsing the virtual port identifier and signal value corresponding to the virtual operation signal is canceled.

4. The controller virtual simulation method as described in claim 1, characterized in that, The step of transmitting the control command to the physical programmable logic controller includes: The control command is encapsulated into a data frame to be transmitted, and a timestamp is added to the data frame to be transmitted to obtain the first target data frame. The first target data frame is written non-blockingly to the write port of the bidirectional data buffer queue, so that the entity programmable logic controller reads the second target data frame from the read port of the bidirectional data buffer queue. If the difference between the timestamp of the second target data frame and the current system time exceeds a preset time limit, a retransmission request signal is returned. If the difference does not exceed the preset time limit, the control instruction is executed, and the status feedback signal and the program running data are returned. The retransmission request signal is used to request that the first target data frame be rewritten non-blockingly to the write port.

5. The controller virtual simulation method as described in claim 1, characterized in that, The step of receiving the status feedback signal and program execution data returned by the physical programmable logic controller based on the control command includes: The system receives the raw data stream returned by the physical programmable logic controller through a bidirectional data buffer queue, and extracts the status feedback signal and the program execution data from the raw data stream. The state feedback signal is transmitted to the 3D model driving interface so that the step of driving the 3D model in the virtual simulation scene to generate synchronous actions based on the state feedback signal can be executed by calling the 3D model driving interface. The program execution data is transmitted to the assessment interface, and the step of comparing the program execution data with the preset evaluation criteria and obtaining the simulation assessment result is executed by calling the assessment interface.

6. The controller virtual simulation method as described in claim 1, characterized in that, The step of driving the 3D model in the virtual simulation scene to generate synchronous actions based on the state feedback signal includes: The device identifier and status parameters are obtained by parsing the status feedback signal; Based on the device identifier, the corresponding model component is retrieved and located in the 3D model, and based on the state parameters, the target pose transformation matrix of the model component and / or the display state switching command is calculated. The target pose transformation matrix and / or display state switching command are applied to the model component to update the pose and / or display state of the model component.

7. The controller virtual simulation method as described in claim 1, characterized in that, The step of comparing the program execution data with preset evaluation criteria to obtain the simulation assessment results includes: The raw values ​​in the program execution data are converted into physical quantities to obtain the actual physical quantities in the target numerical format. The stable value of the actual physical quantity is collected according to the preset delay time, and the stable value is compared with the theoretical value of each assessment item in the preset evaluation criteria to obtain the deviation value of each assessment item. The simulation assessment total score is calculated based on each deviation value and the preset scoring weight, and the simulation assessment total score is used as the simulation assessment result.

8. A virtual simulation system for a controller, characterized in that, The controller virtual simulation system includes: The signal mapping module is used to convert the virtual operation signal into control instructions that can be recognized by the physical programmable logic controller according to the preset input-output point mapping relationship; The signal transmission module is used to transmit the control command to the physical programmable logic controller and receive the status feedback signal and program running data returned by the physical programmable logic controller based on the control command. The simulation assessment module is used to drive the three-dimensional model in the virtual simulation scene to generate synchronous actions according to the state feedback signal, and compare the program running data with the preset evaluation criteria to obtain the simulation assessment result. The three-dimensional model is constructed based on the three-dimensional size data of the physical programmable logic controller and the external device corresponding to the physical programmable logic controller.

9. An electronic 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 controller virtual simulation method as described in any one of claims 1 to 7.

10. 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 controller virtual simulation method as described in any one of claims 1 to 7.

Images