Method and device for debugging programmable controller variable based on communication test platform

Abstract

This application provides a method and apparatus for debugging programmable logic controller (PLC) variables based on a communication testing platform. The method includes: sending communication probe requests to candidate devices within the device scanning range and identifying the target lower-level device; obtaining PLC variable description data corresponding to the target lower-level device and parsing the variable hierarchy and variable communication identifiers; generating a variable tree according to the variable hierarchy and establishing a mapping relationship between variable nodes and variable communication identifiers in the variable tree; generating variable read requests, variable write requests, or variable subscription tasks based on the mapping relationship and adding them to an asynchronous communication task queue; executing the tasks in the asynchronous communication task queue through an independent communication thread, receiving variable processing data returned by the target lower-level device, synchronizing the variable processing data to the variable tree and log information, and generating PLC variable debugging results. This application can improve device discovery efficiency, enhance variable management consistency, and reduce the risk of communication blockage.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and apparatus for debugging programmable controller variables based on a communication testing platform. Background Technology

[0002] With the development of industrial automation, equipment control, and programmable logic controller (PLC) system integration technologies, the demand for data communication and on-site debugging between Windows clients and Linux lower-level machines is constantly increasing. During equipment commissioning, protocol verification, program debugging, and operation monitoring, debugging personnel typically need to continuously monitor and operate the lower-level machine connection status, PLC variable structure, real-time variable values, and changes in key parameters to determine whether the communication link is normal, whether the equipment status is stable, and whether the control parameters meet the debugging requirements.

[0003] Existing communication debugging tools mostly focus on single communication connections or simple data reading and writing, typically requiring manual configuration of target device addresses and communication parameters. In scenarios involving multiple devices or batch debugging on the same network segment, it is difficult to quickly identify connectable target lower-level machines. Furthermore, existing tools manage programmable controller variables in a fragmented manner, lacking structured parsing and unified display of variable hierarchical relationships. Debuggers must rely on variable names, addresses, or external documents for searching, making variable location and parameter verification processes cumbersome.

[0004] In addition, in existing debugging methods, variable reading, variable writing and periodic monitoring are often independent of each other, making it difficult to complete continuous debugging operations based on a unified variable object. In scenarios with a large number of variables or high-frequency communication, communication processing can easily consume interface response resources, leading to interface lag, data refresh delay or unstable subscription monitoring, thereby affecting the efficiency of equipment joint debugging, the accuracy of fault diagnosis and the continuity of the on-site debugging process. Summary of the Invention

[0005] In view of this, embodiments of this application provide a programmable controller variable debugging method and apparatus based on a communication testing platform to solve the problems of existing technologies, such as reliance on manual equipment discovery, decentralized variable management, and easy blockage of communication debugging.

[0006] A first aspect of this application provides a programmable logic controller (PLC) variable debugging method based on a communication testing platform, comprising: determining a device scanning range based on the current network environment of the client; sending communication probe requests to candidate devices within the device scanning range; identifying a target lower-level device based on the response data returned by the candidate devices; establishing a communication connection based on the target lower-level device; obtaining PLC variable description data corresponding to the target lower-level device; and parsing the variable hierarchy relationship and variable communication identifier based on the variable description data; generating a variable tree according to the variable hierarchy relationship; and establishing a mapping relationship between variable nodes in the variable tree and variable communication identifiers; responding to debugging operations on variable nodes; generating variable read requests, variable write requests, or variable subscription tasks according to the mapping relationship; and adding the variable read requests, variable write requests, or variable subscription tasks to an asynchronous communication task queue; executing the tasks in the asynchronous communication task queue through an independent communication thread; receiving variable processing data returned by the target lower-level device; synchronizing the variable processing data to the variable tree and log information; and generating PLC variable debugging results.

[0007] A second aspect of this application provides a programmable logic controller (PLC) variable debugging device based on a communication testing platform, comprising: a sending module, configured to determine the device scanning range based on the current network environment of the client, send communication probe requests to candidate devices within the device scanning range, and identify the target lower-level device based on the response data returned by the candidate devices; a parsing module, configured to establish a communication connection based on the target lower-level device, obtain PLC variable description data corresponding to the target lower-level device, and parse the variable hierarchy relationship and variable communication identifier based on the variable description data; a mapping module, configured to generate a variable tree according to the variable hierarchy relationship, and establish a mapping relationship between variable nodes in the variable tree and variable communication identifiers; a generation module, configured to generate variable read requests, variable write requests, or variable subscription tasks according to the mapping relationship in response to debugging operations on variable nodes, and add the variable read requests, variable write requests, or variable subscription tasks to an asynchronous communication task queue; and an execution module, configured to execute the tasks in the asynchronous communication task queue through an independent communication thread, receive variable processing data returned by the target lower-level device, synchronize the variable processing data to the variable tree and log information, and generate PLC variable debugging results.

[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By determining the device scanning range based on the client's current network environment, communication probe requests are sent to candidate devices within the scanning range, and the target lower-level machine is identified based on the response data returned by the candidate devices. A communication connection is established based on the target lower-level machine, and the corresponding programmable controller variable description data is obtained. The variable hierarchy and variable communication identifiers are then parsed based on the variable description data. A variable tree is generated according to the variable hierarchy, and a mapping relationship is established between variable nodes and variable communication identifiers in the variable tree. In response to debugging operations on variable nodes, variable read requests, variable write requests, or variable subscription tasks are generated based on the mapping relationship, and these tasks are added to an asynchronous communication task queue. Tasks in the asynchronous communication task queue are executed through an independent communication thread, receiving variable processing data returned by the target lower-level machine, synchronizing the variable processing data to the variable tree and log information, and generating programmable controller variable debugging results. This application can improve device discovery efficiency, enhance variable management consistency, and reduce the risk of communication congestion. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating the programmable controller variable debugging method based on a communication test platform provided in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of the programmable controller variable debugging device based on the communication test platform provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] With the development of industrial automation, equipment control, and programmable logic controller (PLC) system integration technologies, the demand for data communication, device integration, variable reading and writing, and operational status monitoring between Windows clients and Linux slave devices is constantly increasing. Existing communication debugging tools can typically achieve basic network connectivity and data reading and writing, but they often rely on manual configuration of target device addresses, communication ports, and related parameters. In scenarios involving multiple devices or batch debugging on the same network segment, it is difficult to quickly identify communicable target slave devices. Furthermore, existing tools manage PLC variables in a fragmented manner, typically using variable lists, address tables, or external configuration files for auxiliary viewing, lacking unified parsing and structured management of variable hierarchical relationships and variable communication identifiers.

[0015] Based on the aforementioned existing technologies, during equipment integration and program debugging, debugging personnel need to repeatedly switch between multiple operation stages, such as device discovery, variable location, variable reading, parameter writing, and periodic monitoring, resulting in a discontinuous debugging process. Especially in scenarios with a large number of variables or high-frequency communication, if communication processing and interface interaction are not effectively decoupled, problems such as slow interface response, delayed data refresh, and unstable subscription monitoring can easily occur. Therefore, existing technologies suffer from at least the problems of relying on manual device discovery, fragmented variable management, and easy blockage in communication debugging.

[0016] To address the aforementioned technical issues, this application provides a programmable logic controller (PLC) variable debugging method based on a communication testing platform. The method determines the device scanning range using the client's current network environment, sends communication probe requests to candidate devices, and identifies the target lower-level machine based on the response data. After establishing a communication connection with the target lower-level machine, it acquires PLC variable description data and parses the variable hierarchy and variable communication identifiers. Furthermore, it generates a variable tree according to the variable hierarchy and establishes a mapping relationship between variable nodes and variable communication identifiers, enabling variable browsing, variable reading, variable writing, and variable subscription to all be performed based on the same variable tree.

[0017] During the debugging process, this application, in response to debugging operations targeting variable nodes, generates variable read requests, variable write requests, or variable subscription tasks based on the mapping relationship corresponding to the variable nodes, and adds the corresponding tasks to the asynchronous communication task queue. Then, through an independent communication thread, it executes the tasks in the asynchronous communication task queue, receives variable processing data returned by the target lower-level machine, and synchronizes the variable processing data to the variable tree and log information, generating programmable controller variable debugging results. Therefore, this application can improve device discovery efficiency, enhance variable management consistency, reduce the risk of blocking during communication debugging, and improve the continuity and stability of device integration debugging, program debugging, and operation monitoring.

[0018] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0019] Figure 1 This is a flowchart illustrating the programmable controller variable debugging method based on a communication test platform provided in an embodiment of this application. Figure 1 As shown, the method may specifically include: S101, determine the device scanning range based on the current network environment of the client, send communication probe requests to candidate devices within the device scanning range, and identify the target lower-level machine based on the response data returned by the candidate devices; S102, establish a communication connection based on the target lower-level machine, obtain the programmable controller variable description data corresponding to the target lower-level machine, and parse the variable hierarchy relationship and variable communication identifier according to the variable description data; S103, Generate a variable tree according to the variable hierarchy, and establish a mapping relationship between variable nodes in the variable tree and variable communication identifiers; S104, in response to the debugging operation for the variable node, generates a variable read request, variable write request or variable subscription task according to the mapping relationship, and adds the variable read request, variable write request or variable subscription task to the asynchronous communication task queue. S105 executes tasks in the asynchronous communication task queue through an independent communication thread, receives variable processing data returned by the target lower-level machine, synchronizes the variable processing data to the variable tree and log information, and generates programmable controller variable debugging results.

[0020] In some embodiments, determining the device scanning range based on the client's current network environment, sending communication probe requests to candidate devices within the device scanning range, and identifying the target lower-level device based on the response data returned by the candidate devices, includes: Obtain the client's network address and communication configuration parameters, determine the set of candidate addresses in the same network segment as the client based on the network address, and generate a communication probe request corresponding to the communication test platform based on the communication configuration parameters; According to the candidate address set, a communication probe request is sent to each candidate device, the response data returned by each candidate device is received, and the device type and communication status are verified in the response data. Candidate devices identified through device type recognition and communication status verification are determined as target lower-level devices, and device scanning results containing the target lower-level device address, connection status, and device identifier are generated.

[0021] Specifically, after the communication test platform starts, the Windows client first reads the local network adapter's enabled status, network address, subnet mask, default gateway, and communication configuration parameters such as the platform's preset communication port, message format, and response wait time. The system calculates the network segment range where the current client is located based on the network address and subnet mask, excluding local addresses, broadcast addresses, and addresses marked as unusable, generating a candidate address set. Taking a production line debugging scenario as an example, after the debugging personnel connect the laptop running the communication test platform to the device control network, the client detects that its local address is in the same control network segment. The system then generates multiple candidate addresses according to this network segment and encapsulates a communication probe request according to the communication test platform's protocol. The communication probe request carries a platform identification field, a communication version field, a request sequence number, and a connectivity query field, allowing candidate devices to determine whether the request belongs to their platform's scanning request.

[0022] When sending communication probe requests, the system does not require debuggers to input Linux lower-level machine addresses one by one. Instead, it sends communication probe requests sequentially or in groups according to the candidate address set, and establishes a scan status record for each candidate address. To avoid network congestion caused by a large number of addresses probing simultaneously, the system can set the concurrency and response timeout according to the communication configuration parameters, and mark candidate addresses that are waiting for a response, have responded, have timed out, or are experiencing an error. When a candidate device returns response data, the system extracts information such as device identifier, system type, communication service status, protocol version, and connectability status from the response data, and matches it with the target lower-level machine identification rules preset by the communication test platform. If the response data indicates that the candidate device is running Linux lower-level machine communication services, and the protocol version, service port, and connection status all meet the communication requirements, then the device type identification and communication status verification are passed; if the response data lacks a platform identification field, the protocol version does not match, or the communication service is not ready, then the candidate device is marked as a non-target device or an unconnectable device.

[0023] In actual joint debugging, the same network segment may simultaneously contain engineer computers, switch management addresses, other controllers, and multiple Linux slave devices. Through device type identification and communication status verification, the system can filter out the target slave device that is truly suitable for programmable controller variable debugging from multiple candidate devices. For example, in a batch device detection scenario, if three devices return response data conforming to the platform protocol, the system records their target slave device address, device identifier, and current connection status, displaying them as connectable in the device list area. For addresses that do not return a response or whose response content does not conform to the platform protocol, only an error log is retained or the response is ignored. After selecting any target slave device from the device list, the user can proceed to the subsequent connection establishment and variable description data acquisition process.

[0024] When generating device scan results, the system associates and saves the target lower-level machine address, connection status, device identifier, and scan time, and synchronizes the device scan results to the device list area and log information area of ​​the interface. If the same device is identified again in a subsequent scan, the system updates its connection status according to the device identifier, instead of creating a duplicate device record; if a connected device fails to return a response on time during status monitoring, its status is adjusted to disconnected or abnormal, and subsequent communication operations relying on that device are stopped.

[0025] Through the above processing, this embodiment can complete the discovery of target lower-level machines without manual configuration of addresses item by item, and connect the device identification results with subsequent communication connections, variable tree loading, variable reading and writing, and subscription monitoring processes, thereby improving device discovery efficiency and reducing the risk of mistakenly connecting to non-target devices.

[0026] In some embodiments, a communication connection is established based on the target lower-level machine, programmable controller variable description data corresponding to the target lower-level machine is obtained, and the variable hierarchy relationship and variable communication identifier are parsed based on the variable description data, including: A connection request is generated based on the target lower-level machine address and communication configuration parameters, and a communication connection is established after the target lower-level machine returns connection confirmation data. Based on the communication connection, a variable acquisition request is sent to the target lower-level machine, the programmable controller variable description data returned by the target lower-level machine is received, and the integrity of the variable description data is verified. Based on the verified variable description data, extract variable path information and variable attribute information, determine the hierarchical level between variables, generate variable hierarchy relationships, and match corresponding variable communication identifiers for each variable.

[0027] Specifically, after the target lower-level device has passed the device scan and is displayed as connectable, the communication test platform generates a connection request based on the target lower-level device address, device identifier, and communication configuration parameters such as preset communication port, connection timeout, and message verification method from the device scan results. This connection request carries the client identifier, target device identifier, communication protocol version, and session establishment parameters. Taking a device integration testing scenario as an example, after the debugging personnel select the Linux lower-level device in the device list area and trigger the connection operation, the client sends a connection request to the target lower-level device. The target lower-level device verifies the protocol version, device identifier, and connection status, and returns connection confirmation data after successful verification. After receiving the connection confirmation data, the client records the session status and communication channel identifier, updates the corresponding device to a connected state, and initializes the resources required for variable acquisition, variable reading and writing, and subscription monitoring.

[0028] After the communication connection is established, the client sends a variable retrieval request to the target lower-level machine. This request retrieves programmable controller (PLC) variable description data that the target lower-level machine can use for debugging. The variable description data includes the variable name, variable path, variable type, access attribute, hierarchical level, and identification information related to communication access. Upon receiving the request, the target lower-level machine reads the variable description data from its variable management area for communication with the PLC and returns it to the client in the agreed-upon data format. After receiving the variable description data, the client performs integrity checks on the message length, variable records, hierarchical fields, variable type, and data checksum. If the check passes, the variable description data is written to the local variable cache; if the check fails, a variable retrieval exception is recorded in the log information area.

[0029] During the variable description data parsing process, the client identifies the hierarchical relationships between variables according to the variable path information and determines whether a variable is a grouping node, a structural node, or a directly readable / writable variable node based on variable attribute information. For example, during programmable logic controller (PLC) program debugging, variable description data includes different categories such as equipment operating status, control parameters, alarm flags, and counting information. The client determines the parent and child objects based on the hierarchical separation relationship in the variable path and determines the data type, read / write permissions, and display method of the variable based on the variable attribute information. For variables with the same parent path, the client merges them into nodes of the same level; for variables with further sub-paths, the client continues to parse downwards, forming a variable hierarchy.

[0030] After determining the variable hierarchy, the client matches a corresponding variable communication identifier for each accessible variable. The variable communication identifier is generated from the access index, variable address, or platform internal identifier returned by the target lower-level machine, and is used to uniquely identify the target variable during subsequent read, write, and subscription processes. The client stores variable path information, variable attribute information, variable hierarchy, and variable communication identifier in a linked manner. For example, when a user selects a runtime parameter variable in the variable tree, the system generates a read request based on the variable communication identifier associated with that node; when a user modifies control parameters or subscribes to critical status variables, the system generates a write request or periodic refresh task based on the same variable communication identifier.

[0031] Through the above processing, this embodiment transforms programmable controller variable description data into basic variable data with hierarchical relationships and communication access criteria, enabling a continuous process for device connection, variable acquisition, variable parsing, and subsequent variable debugging operations. This embodiment improves the accuracy of variable loading and the clarity of variable location, reduces read / write errors caused by ambiguous variable paths or missing communication identifiers, and provides a data foundation for subsequent variable tree display, real-time reading, parameter writing, and periodic subscription monitoring.

[0032] In some embodiments, a variable tree is generated according to the variable hierarchy, and a mapping relationship is established between variable nodes in the variable tree and variable communication identifiers, including: Based on the hierarchical relationship of variables, determine the node position and subordinate relationship of each variable in the variable tree, and generate variable node data corresponding to the variable organization structure of the programmable controller; The variable node data is hierarchically assembled according to the node position and subordinate relationship to form an expandable and collapsible variable tree; Each variable node is bound to its corresponding variable communication identifier to generate a mapping relationship for variable reading, variable writing, and variable subscription.

[0033] Specifically, after the client completes the connection to the target lower-level machine and obtains the programmable controller variable description data, the communication test platform first reads the generated variable hierarchy relationship and uses the variable path information as the basis for node organization to determine the display level, parent node, and child node of each variable in the variable tree. For variables whose variable attribute information indicates that they are grouped objects or structured objects, the system sets them as parent nodes; for variables whose variable attribute information indicates that they can be directly accessed, the system sets them as leaf variable nodes and retains their variable name, data type, access attribute, current display value, and variable communication identifier. Taking the programmable controller program debugging scenario as an example, the variable description data returned by the target lower-level machine includes categories such as running status, control parameters, alarm flags, and counting information. According to the hierarchy relationship in the variable path, the client organizes the start flag, running mode, and fault status under the running status into one branch, and organizes the speed setting, threshold setting, and switch quantity setting under the control parameters into another branch, thereby generating variable node data corresponding to the programmable controller variable organization structure.

[0034] After the variable node data is generated, the client performs hierarchical assembly according to the node position and hierarchy. The system first creates the root node, then sequentially attaches each group node, structure node, and leaf variable node to its corresponding parent node, and configures the expand, select, and display states for each node. When the user triggers the "Expand All" function, the system expands all nodes in the hierarchical order of the variable tree, allowing the user to view the complete variable structure at once. When the user performs an expand or collapse operation on a single node, the system only updates the display state of that node and its subordinate nodes, without changing the association between variable nodes and variable communication identifiers. If the user triggers the "Clear Tree View" function, the system clears the variable node display data in the current interface, but retains the target lower-level machine connection state, and can regenerate the variable tree after reacquiring variable description data or switching target devices.

[0035] When establishing the mapping relationship, the client binds each accessible variable node to its corresponding variable communication identifier and writes the binding result to the variable node index table. This index table records the correspondence between the display position, variable path, variable attribute information, and variable communication identifier of the variable node. When a user selects a target variable node in the variable tree, the system does not need to re-parse the complete variable description data. Instead, it directly determines the variable communication identifier corresponding to the target variable node based on the variable node index table and further generates variable read requests, variable write requests, or variable subscription tasks. For example, in equipment commissioning tests, after expanding the control parameter branch, the user selects the speed setting variable and inputs a new parameter value. The system encapsulates a write request based on the variable communication identifier bound to that variable node. In operational status monitoring, when a user selects a fault status variable and enables subscription, the system generates periodic read tasks based on the same mapping relationship and updates the displayed value in the variable tree.

[0036] Through the above processing, this embodiment transforms the variable description data returned by the target lower-level machine into a visualized, locatable, and operable variable tree structure, and uses the mapping relationship between variable nodes and variable communication identifiers as a unified entry point for subsequent variable debugging operations. This embodiment can improve the efficiency of variable browsing and location, reduce path matching errors in the variable reading and writing process, enhance data consistency between variable reading, variable writing, and variable subscription, and provide a stable data organization foundation for device joint debugging and operation monitoring in scenarios with a large number of variables.

[0037] In some embodiments, in response to a debugging operation on a variable node, a variable read request, a variable write request, or a variable subscription task is generated based on the mapping relationship, and the variable read request, variable write request, or variable subscription task is added to the asynchronous communication task queue, including: Receive debugging operations for target variable nodes in the variable tree, determine the variable communication identifier corresponding to the target variable node based on the mapping relationship, and generate corresponding task parameters according to the operation type of the debugging operation; Depending on the operation type, the variable communication identifier is encapsulated with the read / write parameters or subscription parameters to generate a variable read request, variable write request, or variable subscription task. Configure the task status and execution order for variable read requests, variable write requests, or variable subscription tasks according to the task parameters, and add them to the asynchronous communication task queue.

[0038] Specifically, after the variable tree has been generated based on the programmable controller variable description data of the target lower-level machine, the communication test platform uses the variable tree as a unified entry point for users to perform debugging operations. When a user selects a target variable node in the variable tree display area, the client reads the node index information of the target variable node and determines the variable communication identifier bound to the target variable node based on the aforementioned mapping relationship, while also reading the variable attribute information corresponding to the node. If the target variable node is a directly accessible leaf variable node, the system continues to identify the operation type triggered by the user in the data operation area; if the target variable node is only a group node or structure node, the system prompts the user to select its subordinate accessible variable node to avoid generating invalid communication tasks for non-readable and writable objects.

[0039] In the read operation scenario, the debugger selects a target variable node such as running status, fault flag, or count information in the variable tree and triggers the read function. The client then generates read task parameters based on the variable communication identifier corresponding to the target variable node. These parameters include the target lower-level machine identifier, communication connection identifier, variable communication identifier, request sequence number, and response waiting time. The system encapsulates the read task parameters into a variable read request and marks it as pending execution. In the write operation scenario, the debugger inputs a target value in the data operation area and triggers the write function. In addition to obtaining the variable communication identifier, the client performs format conversion and access attribute validation on the input value based on variable attribute information. The written value, data type, and write validation information are then encapsulated as write task parameters into a variable write request.

[0040] In subscription operation scenarios, after debugging personnel enable the subscription function for key variables such as device operating parameters and status flags, and set or adopt the default refresh period, the client generates subscription task parameters based on the variable communication identifier, subscription period, and subscription status corresponding to the target variable node, and encapsulates them into a variable subscription task. The variable subscription task is not a one-time communication request, but rather a task object used to continuously generate periodic read tasks according to the subscription period. If the user subsequently triggers the unsubscribe function, the system stops adding new periodic read tasks to the asynchronous communication task queue based on the subscription status corresponding to the variable subscription task, and retains the display values ​​and log records corresponding to completed tasks.

[0041] When adding a task to the asynchronous communication task queue, the client configures the task status and execution order according to the task parameters. For user-triggered read and write requests, the system determines the execution order based on the operation time and the target variable node. For periodic read tasks generated by subscription tasks, the system determines the enqueueing time based on the subscription period, the last execution time, and the current communication load. If the same target variable node has both read and subscription refresh tasks within a short period, the system merges duplicate read tasks based on the task status, or prioritizes write requests over subsequent subscription refresh tasks, so that the variable value after writing can be updated in the variable tree in a timely manner. All enqueued tasks record the task source, target variable node, variable communication identifier, and current status, forming a traceable operation record in the log information area.

[0042] Through the above processing, this embodiment associates the target variable node, variable communication identifier, user debugging operation, and asynchronous communication task queue in the variable tree, enabling variable reading, variable writing, and variable subscription to complete task generation and scheduling on a unified data organization basis. This embodiment can improve the continuity and accuracy of variable debugging operations, reduce the occupation of communication links by invalid and duplicate requests, avoid mutual blocking between interface operations and communication processing, and improve the data interaction efficiency during equipment integration debugging, programmable controller program debugging, and operation status monitoring.

[0043] In some embodiments, the generation and processing of variable subscription tasks include: In response to a subscription operation for a target variable node, the subscription period and subscription status corresponding to the target variable node are obtained, a subscription identifier is generated based on the variable communication identifier corresponding to the target variable node, and a subscription association relationship is established between the subscription identifier, the variable communication identifier, the subscription period, and the subscription status. Based on the subscription period, the subscription relationship is converted into a periodic read task, and the periodic read task is added to the asynchronous communication task queue. Upon receiving an unsubscribe operation for the target variable node, update the subscription status based on the subscription identifier and stop adding the corresponding periodic read task to the asynchronous communication task queue.

[0044] Specifically, after the variable tree has been generated and mapped to the variable communication identifier, the communication test platform uses the subscription function as the continuous data acquisition entry point for operational status monitoring. When a user selects a target variable node in the variable tree display area and triggers a subscription operation in the data operation area, the client first reads the variable attribute information and variable communication identifier corresponding to the target variable node to determine whether the target variable node is an accessible variable node. For variables that need to be continuously observed, such as device operating status, status flags, alarm flags, and count information, the system allows the creation of variable subscription tasks; for parent nodes that are only used for group display, the system does not generate subscription tasks and prompts the user to select its subordinate accessible variable nodes.

[0045] When generating a variable subscription task, the client obtains the subscription period and subscription status corresponding to the target variable node. The subscription period can be set by the user in the interface or by a refresh period preset by the communication testing platform based on the variable type. For example, during the device operation phase, debugging personnel set a shorter refresh period for the running status variable and a longer refresh period for the cumulative count variable to reduce unnecessary communication overhead. The system generates a subscription identifier based on the variable communication identifier corresponding to the target variable node and associates and stores the subscription identifier, variable communication identifier, subscription period, subscription status, target lower-level machine identifier, and variable node display position to form a subscription association. This subscription association is used to record the current subscription object and its execution rules, so that subsequent periodic reading tasks can accurately correspond to the target variable node in the variable tree.

[0046] During the execution of subscription tasks, the system schedules subscription relationships according to the subscription period. When a subscription relationship reaches a preset refresh time, the client converts the subscription relationship into a periodic read task and adds the periodic read task to the asynchronous communication task queue. The periodic read task carries the target lower-level machine identifier, communication connection identifier, variable communication identifier, subscription identifier, and request sequence number. After the independent communication thread retrieves the task from the asynchronous communication task queue, it sends a read request to the target lower-level machine and receives the returned variable value data. Based on the subscription identifier and variable communication identifier, the client synchronously updates the returned variable value data to the corresponding target variable node in the variable tree, and records the refresh time, communication status, and variable return result in the log information area. Taking a PLC program debugging scenario as an example, after the user subscribes to fault status variables and operating mode variables, the system continuously refreshes their current values ​​according to a set period, allowing the user to observe changes in the device's operating status without repeatedly clicking the read button.

[0047] In multi-variable subscription scenarios, the communication testing platform can maintain multiple subscription relationships simultaneously and determine the queuing order of periodic read tasks based on the subscription period and the communication task queue status. For multiple target variable nodes with the same refresh period and belonging to the same target lower-level machine, the system can merge them into batch read tasks according to their task status. For periodic read tasks that are already in the waiting execution state, the system avoids repeatedly adding read tasks corresponding to the same variable communication identifier to reduce communication backlog caused by high-frequency subscriptions. When the communication connection is abnormal or the target lower-level machine fails to return a response on time, the system marks the corresponding subscription relationship as abnormal and records the abnormal information in the log information area. Scheduling will continue according to the subscription status after the connection is restored.

[0048] When a user selects a subscribed target variable node in the variable tree and triggers an unsubscription operation, the client searches for the subscription association based on the subscription identifier corresponding to the target variable node, updates the subscription status to a stopped state, and stops adding the corresponding periodic read tasks to the asynchronous communication task queue. For periodic read tasks that have entered the asynchronous communication task queue but have not yet been executed, the system removes them or marks them as not requiring execution based on the task status; for tasks that have been completed, the system retains the last refresh value and log records. Through the above processing, this embodiment enables key programmable controller variables to be continuously refreshed according to a set period, and promptly releases communication resources after unsubscription, improving the continuity of operation status monitoring, reducing invalid communication load, and enhancing the software response stability in multi-variable, high-frequency debugging scenarios.

[0049] In some embodiments, tasks in the asynchronous communication task queue are executed through an independent communication thread, variable processing data returned by the target lower-level machine is received, and the variable processing data is synchronized to the variable tree and log information to generate programmable controller variable debugging results, including: The task to be executed is extracted from the asynchronous communication task queue through an independent communication thread, and a communication request is sent to the target lower-level machine according to the task status and execution order of the task to be executed. Receive variable processing data returned by the target lower-level machine, parse the variable processing data, and obtain variable value data or task execution status data corresponding to the task to be executed; Based on the variable communication identifier, the variable value data or task execution status data is synchronized to the corresponding variable node, and log information corresponding to the task to be executed is generated; Based on the synchronized variable tree and log information, the programmable controller variable debugging results are generated.

[0050] Specifically, after variable read requests, variable write requests, or variable subscription tasks have been added to the asynchronous communication task queue, the communication testing platform uses an independent communication thread to poll the queue or retrieve data via event triggering. The independent communication thread is separate from the interface display thread. The interface display thread responds to user operations on the device list area, variable tree display area, data operation area, and log information area, while the independent communication thread executes data transmission and reception with the target lower-level machine. When retrieving a task to be executed, the independent communication thread first reads the task status, execution order, target lower-level machine identifier, communication connection identifier, and variable communication identifier corresponding to that task, and determines whether the target lower-level machine is still connected. If the target lower-level machine's connection status is normal, the communication request is encapsulated according to the task type of the task to be executed; if the target lower-level machine's connection status is abnormal, the task to be executed is marked as failed, and a connection error record is generated in the log information area.

[0051] When performing a variable reading task, an independent communication thread generates a read communication request based on the variable communication identifier and sends it to the target lower-level machine. Upon receiving the read communication request, the target lower-level machine accesses the corresponding programmable controller variable based on the variable communication identifier and encapsulates the variable's current value, return status, and verification information into variable processing data, which is then returned to the client. After receiving the variable processing data, the client parses the message length, request sequence number, variable communication identifier, and verification information of the returned data to obtain the variable value data corresponding to the task to be executed. Taking a device integration testing scenario as an example, after the user selects a running status variable in the variable tree and triggers a read, the system sends a read request to the target lower-level machine through an independent communication thread. The returned running status value is parsed and synchronously displayed in the corresponding variable node, while the read time, target lower-level machine address, and read result are recorded in the log information area.

[0052] When performing a variable write task, an independent communication thread encapsulates the write communication request based on the variable communication identifier, the write value, and the data type, and sends it to the target lower-level machine. After the target lower-level machine performs the variable write, it returns task execution status data. The client determines whether the write is complete based on the returned status and synchronizes the write result to the target variable node in the variable tree. For example, during the debugging of a programmable logic controller (PLC) program, after the user inputs a new set value for a control parameter variable and triggers the write, the system sends a write request through an independent communication thread. After the target lower-level machine returns a write completion status, the client updates the displayed value of the target variable node to the written value and generates log information containing the variable name, write value, execution status, and time information. If the target lower-level machine returns write rejection, type mismatch, or communication timeout information, the system updates the corresponding task status to exception and records the exception reason in the log information area.

[0053] When executing periodic read tasks generated by variable subscription tasks, the independent communication thread sends communication requests in the order of execution in the asynchronous communication task queue. After receiving variable processing data, it looks up the corresponding target variable node based on the subscription identifier and variable communication identifier. For device operation status monitoring scenarios, after users subscribe to operating parameters, status flags, and alarm flags, periodic read tasks continuously enter the asynchronous communication task queue. The independent communication thread executes each task sequentially and synchronizes the returned variable value data to the variable tree. During synchronization, the system uses a thread-safe data update method, writing the variable value data to the variable node cache before notifying the interface display thread to refresh the corresponding node's display content, avoiding interface blocking or display conflicts caused by the communication thread directly manipulating the interface.

[0054] During log generation, the system generates log information based on the task source, task type, target lower-level machine address, variable communication identifier, execution start time, execution completion time, and return status of the task to be executed, and writes the log information to the log information area in chronological order. For read tasks, the log information reflects the variable value return status; for write tasks, the log information reflects whether the write is complete; for subscription tasks, the log information reflects the periodic refresh status and abnormal status. Finally, the system generates programmable controller variable debugging results based on the synchronized variable tree and log information, allowing users to view the current variable value, task execution status, and communication process records on the same interface. This embodiment executes asynchronous tasks through independent communication threads and synchronizes variable processing data to the variable tree and log information, which can reduce the risk of interface blocking, improve data refresh stability in high-frequency communication scenarios, and enhance the operational continuity during equipment integration, program debugging, and fault diagnosis.

[0055] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0056] Figure 2 This is a schematic diagram of the structure of the programmable controller variable debugging device based on a communication test platform provided in an embodiment of this application. Figure 2 As shown, the device includes: The sending module 201 is used to determine the device scanning range based on the current network environment of the client, send communication probe requests to candidate devices within the device scanning range, and identify the target lower-level device based on the response data returned by the candidate devices; The parsing module 202 is used to establish a communication connection based on the target lower-level machine, obtain the programmable controller variable description data corresponding to the target lower-level machine, and parse the variable hierarchy relationship and variable communication identifier according to the variable description data; The mapping module 203 is used to generate a variable tree according to the variable hierarchy and establish a mapping relationship between variable nodes and variable communication identifiers in the variable tree; The generation module 204 is used to respond to debugging operations on variable nodes, generate variable read requests, variable write requests, or variable subscription tasks according to the mapping relationship, and add the variable read requests, variable write requests, or variable subscription tasks to the asynchronous communication task queue. The execution module 205 is used to execute tasks in the asynchronous communication task queue through an independent communication thread, receive variable processing data returned by the target lower-level machine, synchronize the variable processing data to the variable tree and log information, and generate programmable controller variable debugging results.

[0057] In some embodiments, Figure 2 The sending module 201 obtains the client's network address and communication configuration parameters, determines a set of candidate addresses in the same network segment as the client based on the network address, and generates a communication probe request corresponding to the communication test platform based on the communication configuration parameters; it sends the communication probe request to each candidate device according to the candidate address set, receives the response data returned by each candidate device, and performs device type identification and communication status verification on the response data; it identifies the candidate devices that pass the device type identification and communication status verification as the target lower-level machine, and generates a device scan result containing the target lower-level machine address, connection status, and device identifier.

[0058] In some embodiments, Figure 2 The parsing module 202 generates a connection request based on the target lower-level machine address and communication configuration parameters, and establishes a communication connection after the target lower-level machine returns connection confirmation data; it sends a variable acquisition request to the target lower-level machine based on the communication connection, receives the programmable controller variable description data returned by the target lower-level machine, and performs integrity verification on the variable description data; it extracts variable path information and variable attribute information based on the verified variable description data, determines the subordinate hierarchy between variables, generates variable hierarchy relationships, and matches corresponding variable communication identifiers for each variable.

[0059] In some embodiments, Figure 2 The mapping module 203 determines the node position and subordinate relationship of each variable in the variable tree according to the variable hierarchy relationship, and generates variable node data corresponding to the variable organization structure of the programmable controller; it assembles the variable node data hierarchically according to the node position and subordinate relationship to form an expandable and foldable variable tree; it binds each variable node with the corresponding variable communication identifier to generate a mapping relationship for variable reading, variable writing and variable subscription.

[0060] In some embodiments, Figure 2The generation module 204 receives debugging operations for target variable nodes in the variable tree, determines the variable communication identifier corresponding to the target variable node based on the mapping relationship, and generates corresponding task parameters according to the operation type of the debugging operation; according to the operation type, it encapsulates the variable communication identifier with read / write parameters or subscription parameters to generate variable read request, variable write request or variable subscription task; according to the task parameters, it configures the task status and execution order for the variable read request, variable write request or variable subscription task, and adds it to the asynchronous communication task queue.

[0061] In some embodiments, Figure 2 In response to a subscription operation for a target variable node, the generation module 204 obtains the subscription period and subscription status corresponding to the target variable node, generates a subscription identifier based on the variable communication identifier corresponding to the target variable node, and establishes a subscription association relationship among the subscription identifier, variable communication identifier, subscription period, and subscription status; according to the subscription period, it converts the subscription association relationship into a periodic reading task and adds the periodic reading task to the asynchronous communication task queue; when a cancel subscription operation is received for the target variable node, it updates the subscription status based on the subscription identifier and stops adding the corresponding periodic reading task to the asynchronous communication task queue.

[0062] In some embodiments, Figure 2 The execution module 205 extracts tasks to be executed from the asynchronous communication task queue through an independent communication thread, and sends communication requests to the target lower-level machine according to the task status and execution order of the tasks to be executed; it receives variable processing data returned by the target lower-level machine, parses the variable processing data, and obtains variable value data or task execution status data corresponding to the tasks to be executed; according to the variable communication identifier, it synchronizes the variable value data or task execution status data to the corresponding variable node, and generates log information corresponding to the tasks to be executed; based on the synchronized variable tree and log information, it generates programmable controller variable debugging results.

[0063] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0064] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0065] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0066] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0067] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0068] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0069] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0070] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for debugging programmable logic controller (PLC) variables based on a communication test platform, characterized in that, include: The device scanning range is determined based on the current network environment of the client, communication probe requests are sent to candidate devices within the device scanning range, and the target lower-level machine is identified based on the response data returned by the candidate devices. A communication connection is established based on the target lower-level machine, the programmable controller variable description data corresponding to the target lower-level machine is obtained, and the variable hierarchy relationship and variable communication identifier are parsed according to the variable description data; Generate a variable tree according to the variable hierarchy relationship, and establish a mapping relationship between the variable nodes in the variable tree and the variable communication identifier; In response to the debugging operation for the variable node, a variable read request, a variable write request, or a variable subscription task is generated according to the mapping relationship, and the variable read request, the variable write request, or the variable subscription task is added to the asynchronous communication task queue. The task in the asynchronous communication task queue is executed by an independent communication thread, the variable processing data returned by the target lower-level machine is received, and the variable processing data is synchronized to the variable tree and log information to generate programmable controller variable debugging results.

2. The method according to claim 1, characterized in that, The step of determining the device scanning range based on the client's current network environment, sending communication probe requests to candidate devices within the scanning range, and identifying the target lower-level device based on the response data returned by the candidate devices includes: Obtain the client's network address and communication configuration parameters, determine a set of candidate addresses in the same network segment as the client based on the network address, and generate a communication probe request corresponding to the communication test platform based on the communication configuration parameters; The communication probe request is sent to each candidate device according to the candidate address set, the response data returned by each candidate device is received, and the response data is used to identify the device type and verify the communication status. Candidate devices identified through the device type identification and communication status verification are determined as target lower-level devices, and device scanning results containing the target lower-level device address, connection status, and device identifier are generated.

3. The method according to claim 1, characterized in that, The step of establishing a communication connection based on the target lower-level machine, obtaining the programmable controller variable description data corresponding to the target lower-level machine, and parsing the variable hierarchy relationship and variable communication identifier according to the variable description data includes: A connection request is generated based on the target lower-level machine address and communication configuration parameters, and a communication connection is established after the target lower-level machine returns connection confirmation data. Based on the communication connection, a variable acquisition request is sent to the target lower-level machine, the programmable controller variable description data returned by the target lower-level machine is received, and the integrity of the variable description data is verified. Based on the verified variable description data, extract variable path information and variable attribute information, determine the hierarchical level between variables, generate variable hierarchy relationships, and match corresponding variable communication identifiers for each variable.

4. The method according to claim 1, characterized in that, The step of generating a variable tree according to the variable hierarchy and establishing a mapping relationship between variable nodes in the variable tree and variable communication identifiers includes: Based on the variable hierarchy, determine the node position and subordinate relationship of each variable in the variable tree, and generate variable node data corresponding to the variable organization structure of the programmable controller; The variable node data is hierarchically assembled according to the node position and the subordinate relationship to form an expandable and collapsible variable tree; Each variable node is bound to its corresponding variable communication identifier to generate a mapping relationship for variable reading, variable writing, and variable subscription.

5. The method according to claim 1, characterized in that, The step of responding to a debugging operation on the variable node by generating a variable read request, a variable write request, or a variable subscription task according to the mapping relationship, and adding the variable read request, the variable write request, or the variable subscription task to the asynchronous communication task queue, includes: Receive debugging operations for target variable nodes in the variable tree, determine the variable communication identifier corresponding to the target variable node based on the mapping relationship, and generate corresponding task parameters according to the operation type of the debugging operation; Based on the operation type, the variable communication identifier is encapsulated with read / write parameters or subscription parameters to generate a variable read request, variable write request, or variable subscription task. Configure the task status and execution order for the variable read request, the variable write request, or the variable subscription task according to the task parameters, and add them to the asynchronous communication task queue.

6. The method according to claim 5, characterized in that, The generation and processing of the variable subscription task includes: In response to a subscription operation for a target variable node, the subscription period and subscription status corresponding to the target variable node are obtained, a subscription identifier is generated based on the variable communication identifier corresponding to the target variable node, and a subscription association relationship is established between the subscription identifier, the variable communication identifier, the subscription period, and the subscription status. According to the subscription period, the subscription association is converted into a periodic read task, and the periodic read task is added to the asynchronous communication task queue; Upon receiving an unsubscribe operation for the target variable node, the subscription status is updated according to the subscription identifier, and the addition of the corresponding periodic read task to the asynchronous communication task queue is stopped.

7. The method according to claim 1, characterized in that, The process involves executing tasks in the asynchronous communication task queue via an independent communication thread, receiving variable processing data returned by the target lower-level machine, synchronizing the variable processing data to the variable tree and log information, and generating programmable controller variable debugging results, including: The task to be executed is extracted from the asynchronous communication task queue through an independent communication thread, and a communication request is sent to the target lower-level machine according to the task status and execution order of the task to be executed. Receive variable processing data returned by the target lower-level machine, parse the variable processing data, and obtain variable value data or task execution status data corresponding to the task to be executed; Based on the variable communication identifier, the variable value data or the task execution status data is synchronized to the corresponding variable node, and log information corresponding to the task to be executed is generated; Based on the synchronized variable tree and the log information, the programmable controller variable debugging results are generated.

8. A programmable logic controller (PLC) variable debugging device based on a communication test platform, characterized in that, include: The sending module is used to determine the device scanning range based on the current network environment of the client, send communication probe requests to candidate devices within the device scanning range, and identify the target lower-level machine based on the response data returned by the candidate devices; The parsing module is used to establish a communication connection based on the target lower-level machine, obtain the programmable controller variable description data corresponding to the target lower-level machine, and parse the variable hierarchy relationship and variable communication identifier according to the variable description data; The mapping module is used to generate a variable tree according to the variable hierarchy relationship and establish a mapping relationship between the variable nodes in the variable tree and the variable communication identifier; The generation module is used to respond to the debugging operation for the variable node, generate a variable read request, a variable write request, or a variable subscription task according to the mapping relationship, and add the variable read request, the variable write request, or the variable subscription task to the asynchronous communication task queue. The execution module is used to execute tasks in the asynchronous communication task queue through an independent communication thread, receive variable processing data returned by the target lower-level machine, synchronize the variable processing data to the variable tree and log information, and generate programmable controller variable debugging results.

9. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images