Board card state monitoring and event-driven method, terminal and system

Abstract

This application relates to the field of industrial control, specifically to a board status monitoring and event-driven method, terminal, and system. The method includes: acquiring board operating status data collected according to a preset cycle; determining whether the board's operating status has changed based on the current cycle's board operating status data and the previous cycle's board operating status data; if so, generating board operating status change data; writing the board operating status change data into a preset shared data memory; and sending an event notification signal to a main application based on the current cycle's board operating status data, so that the main application, in response to the received event notification signal, reads the current cycle's board operating status data from the shared data memory and executes corresponding business processing. This application decouples the board monitoring process from the main application's business logic, improving the real-time performance, reliability, and system operating efficiency of board status monitoring.

Description

Technical Field

[0001] This application relates to the field of industrial control, specifically to board status monitoring and event-driven methods, terminals, and systems. Background Technology

[0002] In the field of industrial automation control, monitoring the operational status of boards such as motion control boards and I / O control boards is fundamental to the safe and stable operation of equipment. Current technologies often use a polling method by the main application to collect board status data. Since the main application simultaneously handles business logic and board status monitoring, the priority of board monitoring tasks cannot be guaranteed, leading to issues such as fluctuating status acquisition cycles and delayed responses to anomalies. When the main program freezes or crashes, the board monitoring function is interrupted, posing a safety hazard to the equipment. Summary of the Invention

[0003] In addressing the issue that the priority of board monitoring task scheduling cannot be guaranteed in practical applications of existing technologies in industrial scenarios, making it difficult to meet the high real-time and high reliability requirements of industrial scenarios, this application provides a board status monitoring and event-driven method, terminal, and system.

[0004] A first aspect of this application provides a board status monitoring and event-driven method, the method comprising: Acquire board operating status data collected according to a preset cycle, determine whether the board's operating status has changed based on the current cycle's board operating status data and the previous cycle's board operating status data, and if so, generate board operating status change data. Write the board's operating status change data to the preset shared data memory; Based on the current cycle board operating status data, an event notification signal is sent to the main application, so that the main application can read the current cycle board operating status data in the shared data memory in response to the received event notification signal and execute the corresponding business processing.

[0005] Optionally, the shared data memory includes a status flag bit and a shared data area, and the generation of board operating status change data includes: An operating status identifier is generated based on the change in the board's operating status, and the operating status identifier and the current period's board operating status data are used as the board operating status change data; The step of writing the board's operating status change data into a preset shared data memory includes: Update the status flag bit in the shared data memory based on the running status flag; Write the current cycle board operating status data into the shared data area of ​​the shared data memory.

[0006] Optionally, the board includes a motion control board and an I / O control board, and the step of acquiring the board's operating status data collected according to a preset period includes: A data acquisition command is generated by triggering a periodic timer according to a preset cycle. In response to the acquisition command, the device operating status data of the motion control board is read through the underlying operation control driver interface; The input / output status data of the IO control board is read through the underlying IO driver interface. Based on the read device operating status data and input / output status data, board operating status data is generated and temporarily stored in the local cache.

[0007] Optionally, the method further includes: If the operating state of the board changes, determine whether the reason for the change in the operating state of the board is a system fault. If so, determine whether the fault type of the system fault is an acute basic fault. If it is an acute basic fault, determine the corresponding fault troubleshooting instruction and transmit it to the corresponding board for execution to eliminate the acute basic faults of all boards; otherwise, continue to execute the step of sending an event notification signal to the main application. If the acute basic fault still exists after a preset time period, an acute fault event notification signal is sent to the main application so that the main application can match the preset fault handling logic based on the received acute fault event notification signal.

[0008] Optionally, the method further includes: At each preset time interval, determine whether board operation status change data is generated. If not, read board operation status data within multiple consecutive collection cycles, verify the values ​​of all data items, and confirm the stagnation type corresponding to the absence of board operation status change data. Based on the confirmed stall type, perform the corresponding hardware link verification and generate the corresponding hardware link verification result. Based on the hardware link verification results, stagnation fault information data is generated, written to the fault storage partition of the shared data area, and the fault status flag is updated so that the main application can match the preset fault handling logic based on the received stagnation fault event notification signal.

[0009] A second aspect of this application provides a board status monitoring and event-driven method, including: The system receives event notification signals transmitted from the monitoring terminal, reads board operating status change data from the shared data memory, and executes corresponding business processing. The event notification signal is generated when the monitoring terminal acquires board operating status data collected according to a preset period. Based on the current period's board operating status data and the previous period's board operating status data, the system determines whether the board's operating status has changed. If so, it generates board operating status change data and writes it into the preset shared data memory, based on the current period's board operating status data.

[0010] Optionally, reading the board operating status change data in the shared data memory and performing the corresponding business processing includes: Obtain the running status identifier from the status identifier bit of the shared data memory, and verify whether the running status identifier has been updated; If so, obtain the current cycle board running status data from the shared data area of ​​the shared data memory to determine the current service cycle status; If the current business cycle is completed, the next business cycle is determined based on the preset business chain, and the corresponding business processing instructions are generated and transmitted to the corresponding board for execution.

[0011] A third aspect of this application provides a monitoring terminal, comprising: The acquisition module is used to acquire board operating status data collected according to a preset cycle, and determine whether the operating status of the board has changed based on the current cycle board operating status data and the previous cycle board operating status data. If so, it generates board operating status change data. The shared data module is used to write the board's operating status change data into the preset shared data memory; The event notification module is used to send an event notification signal to the main application based on the current cycle board operating status data, so that the main application can read the current cycle board operating status data in the shared data memory and execute the corresponding business processing in response to the received event notification signal.

[0012] The fourth aspect of this application provides a main program terminal, including: The main application module is used to receive event notification signals transmitted by the monitoring terminal, read the current period board operating status data in the shared data memory, and execute corresponding business processing. The event notification signal is obtained by the monitoring terminal from board operating status data collected according to a preset period. Based on the current period board operating status data and the previous period board operating status data, it is determined whether the board operating status has changed. If so, board operating status change data is generated; the board operating status change data is written into the preset shared data memory, which is based on the current period board operating status data.

[0013] The fifth aspect of this application provides a board status monitoring and event-driven system, including a monitoring terminal, a main program terminal, and a board; The monitoring terminal acquires board operation status data collected according to a preset cycle. Based on the current cycle's board operation status data and the previous cycle's board operation status data, it determines whether the board's operation status has changed. If so, it generates board operation status change data, writes the board operation status change data into a preset shared data memory, and sends an event notification signal to the main application of the main program terminal based on the current cycle's board operation status data. This causes the main application to respond to the received event notification signal, read the board operation status change data in the shared data memory, and execute the corresponding business processing.

[0014] As can be seen from the above technical solution, this application periodically collects board operating status data through an independently configured monitoring process, compares the operating status data of previous and subsequent periods, writes the data to a created shared memory when the board operating status changes, and sends an event notification signal to trigger the main program to perform business processing. During this process, the main application does not need to perform board operating status data collection and operating status judgment, thus avoiding interference from the business load of the main application on the real-time performance of board monitoring and ensuring the stability of the collection cycle. In addition, the main application of this application does not need to continuously poll, but only reads the board operating status data on demand when the board operating status changes, thereby executing the corresponding business processing. This reduces the resource consumption of the main application and achieves immediate response to board status changes. At the same time, the board monitoring process is decoupled from the business logic of the main application, ensuring the continuous operation of the board monitoring function and improving the real-time performance, reliability, and system operating efficiency of board status monitoring. Attached Figure Description

[0015] 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, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating the board status monitoring and event-driven method in the embodiments of this application.

[0017] Figure 2 This is a schematic diagram of the process of writing board operating status change data in an embodiment of this application.

[0018] Figure 3 This is a schematic diagram of the process for obtaining board operation status data collected according to a preset cycle in an embodiment of this application.

[0019] Figure 4 This is a flowchart illustrating the acute basic fault handling method in the embodiments of this application.

[0020] Figure 5 This is a flowchart illustrating a stall-type fault handling method in an embodiment of this application.

[0021] Figure 6 This is a flowchart illustrating the process by which the main application performs corresponding business processing in an embodiment of this application.

[0022] Figure 7 This is a flowchart illustrating the monitoring terminal in an embodiment of this application.

[0023] Figure 8 This is a schematic diagram of the board status monitoring and event-driven system in the embodiments of this application. Detailed Implementation

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

[0025] In existing technologies, semiconductor chip testing equipment typically employs a main application polling board status monitoring scheme. The main application integrates human-computer interaction, test process control, and board status monitoring functions. It triggers the polling action through a periodic timer. In each polling cycle, the main application sequentially calls the underlying driver interface to read data such as the axis running status, limit signals, and alarm information of the motion control board, as well as the input and output channel status data of the IO control board. After reading, the status parsing, anomaly judgment, and corresponding business processing are synchronously completed within the main program thread.

[0026] In high-density testing scenarios where the equipment is running at full load, the main thread of the above solution needs to simultaneously handle tasks such as test algorithm calculation, human-machine interface rendering, and multi-axis linkage control. The scheduling priority of polling tasks is often preempted by business operations, resulting in significant fluctuations in the polling cycle and delays in response to emergency states such as limit alarms, exceeding the threshold for safe operation of the equipment. When the main application lags or the process crashes, the board status monitoring function is interrupted, which can easily lead to equipment damage accidents such as overtravel collisions of the motion mechanism. In addition, continuous high-frequency polling will consume a lot of computing resources of the main application, resulting in a decrease in the execution efficiency of the test process.

[0027] Based on this, this application provides an implementation method for board status monitoring and event-driven methods, such as... Figure 1 As shown, the method includes: S101: Obtain board operating status data collected according to a preset cycle; determine whether the board's operating status has changed based on the current cycle's board operating status data and the previous cycle's board operating status data; if so, generate board operating status change data.

[0028] S102, writes the board's operating status change data into the preset shared data memory.

[0029] S103, based on the current cycle board operating status data, an event notification signal is sent to the main application, so that the main application responds to the received event notification signal by reading the current cycle board operating status data in the shared data memory and executing the corresponding business processing.

[0030] It should be noted that, in the embodiments of this application, the collection of board operating status data can be performed by a monitoring process independent of the main application. It is understood that, in an optional implementation, the monitoring process can be integrated with the main application or set up independently. For example, the main application is set on the main program terminal, and the monitoring process can be set on a separate monitoring terminal or integrated with the main application and set on the main program terminal. Those skilled in the art can set the main application and monitoring process according to actual needs, and this application does not impose any limitations on this.

[0031] It should be noted that the preset period is configured according to the actual needs of the industrial control scenario. For example, in scenarios with high real-time requirements such as semiconductor testing equipment and motion platforms, the preset period can be set to 1ms to 20ms. In scenarios with relatively low real-time requirements such as ordinary automated production lines, the preset period can be set to 20ms to 100ms. The specific configuration parameters of the preset period are stored in the non-volatile storage medium of the operating system. When the monitoring process starts, it automatically reads the configuration parameters to complete the setting of the acquisition period.

[0032] Optionally, the preset cycle configuration can also be modified online. The main application can send a cycle adjustment command to the monitoring terminal according to the operating conditions of the device. After receiving the command, the monitoring terminal updates the timing parameters of the periodic timer after the current acquisition cycle is completed, so as to realize the dynamic adjustment of the acquisition cycle. The adjustment process will not interrupt the continuous operation of the status monitoring process.

[0033] It should be noted that the board described in this embodiment may include a motion control board and an I / O control board. The board's operating status data includes the device operating status data corresponding to the motion control board and the input / output status data corresponding to the I / O control board. The device operating status data of the motion control board includes, but is not limited to, at least one of the following: actual position data of a single or multiple axes, target position data, actual speed data, target speed data, acceleration data, deceleration data, axis enable status data, axis alarm status data, positive limit trigger status data, negative limit trigger status data, origin signal status data, and following error data. The input / output status data of the I / O control board includes, but is not limited to, at least one of the following: level status data of digital input channels, level status data of digital output channels, numerical data of analog input channels, numerical data of analog output channels, and channel fault status data. The specific data items of the board's operating status data can be expanded or reduced according to the board's model, number of channels, and function type. The monitoring terminal will automatically identify the connected board model and configuration during the initialization phase and automatically adapt the corresponding data item structure without requiring manual modification of the acquisition logic.

[0034] In this embodiment of the application, the monitoring terminal has a fixed-length storage area in the local cache for storing the board operation status data collected in the previous cycle. The board operation status data includes multiple operation status data. After completing the collection of the board operation status data in the current cycle, the monitoring terminal compares the board operation status data in the current cycle with the board operation status data in the previous cycle bit by bit. When the value of any operation status data changes, it is determined that the operation status of the board has changed.

[0035] For example, for Boolean-type status data, such as limit trigger status and channel level status, the values ​​are directly compared for consistency; if the values ​​differ, the data item is determined to have changed. For floating-point-type numerical data, such as actual position and actual speed, a preset comparison threshold is set. When the absolute value of the difference between any running status data in the current cycle and the corresponding running status data in the previous cycle exceeds the preset comparison threshold, the current running status data is determined to have changed. For example, taking the actual position data of a motion axis as an example, the preset comparison threshold is set to 0.001mm. When the difference between the actual position collected in the current cycle and the actual position in the previous cycle exceeds 0.001mm, the current actual position data item is determined to have changed.

[0036] It should be noted that, in the embodiments of this application, the preset shared data memory is the memory space created by the shared memory mechanism provided by the operating system kernel. This memory space can be accessed by the monitoring terminal and the main application at the same time, and data interaction between processes can be realized without multiple data copies.

[0037] In this embodiment, the event notification signal is a signal generated by the inter-process event notification mechanism provided by the operating system. For example, the event notification mechanism may be any one of event objects, semaphores, message queues, and pipes, and this application does not impose any restrictions on it. The event notification signal is only used to notify the main application that the board's running status has changed, and does not carry specific board running status data. The specific board running status data is read by the main application from the shared data memory, thereby reducing the amount of data transmission in inter-process communication and improving notification efficiency.

[0038] It should be noted that the main application has a dedicated event listener thread. This thread listens for event notification signals sent by the monitoring terminal. When no event notification signal is received, the event listener thread remains blocked and does not consume operating system resources. It is only awakened upon receiving an event notification signal, triggering the main application's business processing thread to execute the corresponding operation. The event listener thread has a higher scheduling priority than other threads in the main application, ensuring that event notification signals are responded to promptly and avoiding delays in event response caused by other business operations in the main application.

[0039] For example, when the main application reads the board's operating status data and the positive limit state of axis 1 is in the triggered state, the business processing performed by the main application includes: updating the limit state of axis 1 to triggered on the human-machine interface and indicating it with a red indicator; issuing an emergency stop command to all axes to the motion control board, prohibiting all motion axes from continuing to run; recording the timestamp of the limit trigger event, the position of the corresponding axis, and the speed data to the fault log file; and triggering the device's audible and visual alarm device to alert on-site operators to handle the abnormality. The specific process of business processing can be configured according to the actual needs of the device. Different state changes correspond to different processing logics without modifying the underlying state monitoring and event notification mechanisms, thus improving the system's scalability.

[0040] In embodiments achievable under this application, the shared data memory includes a status flag bit and a shared data area, and the generation of board operating status change data includes: An operating status identifier is generated based on the change in the board's operating status, and the operating status identifier and the current period's board operating status data are used as the board operating status change data.

[0041] like Figure 2 As shown, writing the board's operating status change data into a preset shared data memory includes: S201, update the status flag bit in the shared data memory based on the running status flag.

[0042] S202, write the current cycle board operating status data into the shared data area of ​​the shared data memory.

[0043] In a specific example, the shared data memory comprises two contiguous storage areas: a status flag and a shared data area. The status flag is located at the beginning of the shared data memory, occupying a fixed number of bytes. The shared data area is located at the subsequent address range of the status flag, occupying the remaining shared data memory space. The status flag stores information such as changes in the board's operating status, data validity, and data synchronization status. The shared data area stores complete board operating status data, fault information, and other relevant data.

[0044] Specifically, the status flag is divided into multiple independent flag segments, each corresponding to one piece of board operating status data. The number of flag segments is consistent with the number of categories of board operating status data. For example, each flag segment occupies 1 byte of storage space, where the least significant bit is used to indicate whether the status data of the corresponding category has changed, and the remaining bits are used to indicate the validity, fault status, and other information of the corresponding category data. For example, the flag segments are categorized according to the type and function of the board, including motion control axis 1 status flag segment, motion control axis 2 status flag segment, digital input status flag segment, digital output status flag segment, system fault status flag segment, etc. Each flag segment corresponds to an independent piece of status data. The main application reads only the data corresponding to the category that has changed based on the status of the flag segment, without having to read the entire shared data area, thus reducing the time spent reading data.

[0045] It should be noted that, in this embodiment, the running status identifier is binary data corresponding to the structure of the status identifier bits. The byte length of the running status identifier is the same as the byte length of the status identifier bits, and the meaning of each data bit matches the meaning of the corresponding data bit in the status identifier bits. When the monitoring terminal determines that the running status of the board has changed, it sets the change identifier bit of the corresponding identifier segment in the running status identifier to the corresponding value according to the category to which the changed data item belongs. At the same time, it sets the remaining data bits of the corresponding identifier segment according to the validity of the data and the fault status, thereby generating a complete running status identifier. The generation process of the running status identifier is completed in the local cache of the monitoring terminal. After generation, it is written to the status identifier bit area of ​​the shared data memory to avoid the efficiency loss caused by multiple memory write operations.

[0046] Specifically, the shared data area is logically divided into multiple contiguous data storage partitions. Each data storage partition corresponds to a type of board operating status data. The partitioning of data storage corresponds one-to-one with the flag segments in the status flag. The storage space size of each data storage partition is configured according to the maximum storage requirements of the corresponding category of board operating status data. After updating the status flag, the monitoring terminal writes the board operating status data for the current period into the corresponding data storage partition in the shared data area according to the category. After the write operation is completed, the valid flag bit of the corresponding flag segment in the status flag is set to a valid state, thereby marking that the data of that category has been updated and can be read by the main application. Each data storage partition has an independent valid flag bit. The main application can confirm whether the data of the corresponding category is valid based on the status of the valid flag bit, avoiding reading invalid data that has not been updated.

[0047] In embodiments achievable under this application, such as Figure 3 As shown, the board includes a motion control board and an I / O control board. The step of acquiring the board's operating status data collected according to a preset cycle includes: S301 uses a periodic timer to trigger the generation of acquisition commands according to a preset cycle.

[0048] S302, in response to the acquisition command, read the device operating status data of the motion control board through the underlying operation control driver interface.

[0049] S303 reads the input / output status data of the IO control board through the underlying IO driver interface.

[0050] S304 generates board operation status data based on the read device operation status data and input / output status data, and temporarily stores it in the local cache.

[0051] It should be noted that the acquisition command is an inter-thread communication command within the monitoring terminal. The monitoring terminal has an independent data acquisition thread. When the data acquisition thread does not receive an acquisition command, it is in a blocked waiting state. When the periodic timer is triggered and an acquisition command is generated, the data acquisition thread is awakened and immediately performs the reading operation of the board's operating status data, thereby ensuring the timely execution of the acquisition action and reducing triggering delay.

[0052] In this embodiment, the underlying operation control driver interface can directly interact with the hardware registers of the motion control board to read the board's operating status data. During the initialization phase, the monitoring terminal loads the motion control board driver program and creates a device handle. When performing a data reading operation, it calls the corresponding underlying operation control driver interface through the device handle to obtain the device operating status data of the motion control board. For example, taking an 8-axis motion control board, the operating status data of each axis is stored in consecutive register addresses of the board hardware. The monitoring terminal completes the reading of all operating status data of the 8 axes through a single batch read interface call, without needing to call the interface separately for each axis. This reduces the number of driver interface calls from 8 to 1, shortening the total data reading time.

[0053] It should be noted that the underlying I / O driver interface directly interacts with the hardware of the I / O control board to read input and output status data. During the initialization phase, the monitoring terminal simultaneously loads the I / O control board driver and creates the device handle. After reading the device operation status data of the motion control board, it immediately calls the underlying I / O driver interface through the device handle to read the input and output status data of the I / O control board. For digital input channels, the read data is the channel's high or low level status, usually stored in binary bits, with each binary bit corresponding to one digital input channel. For analog input channels, the read data is the voltage or current value acquired by the channel, usually stored as 16-bit or 32-bit integer data. After reading the raw data, the monitoring terminal converts the raw integer data into the corresponding actual physical quantity value according to the preset conversion coefficient.

[0054] In this embodiment, the monitoring terminal's local cache includes at least two storage partitions: a current cycle cache and a previous cycle cache. After generating the current cycle's board operating status data, the monitoring terminal writes this data completely into the current cycle cache. Simultaneously, it uses the previous cycle's board operating status data from the previous cycle cache as a comparison for judging status changes. After completing the status change judgment for the current cycle, the monitoring terminal completely copies the data from the current cycle cache to the previous cycle cache, overwriting the original data and updating the data. It should be noted that the local cache uses contiguous memory addresses for storage, ensuring that data comparison operations can be executed quickly through memory block comparison functions, reducing the computation time of the comparison operations.

[0055] In embodiments achievable under this application, such as Figure 4 As shown, the method further includes: S401, if the operating state of the board changes, determine whether the reason for the change in the operating state of the board is a system fault; if so, determine whether the fault type of the system fault is an acute basic fault.

[0056] S402, if it is an acute basic fault, determine the corresponding fault troubleshooting instruction and transmit it to the corresponding board for execution to eliminate the acute basic faults of all boards; otherwise, continue to execute the step of sending an event notification signal to the main application.

[0057] S403, if the acute basic fault still exists after a preset time period, an acute fault event notification signal is sent to the main application so that the main application matches the preset fault handling logic based on the received acute fault event notification signal.

[0058] In this embodiment, after determining that the operating status of the board has changed, the monitoring terminal first performs fault identification on the board's operating status data for the current period to determine whether the change in operating status is due to a system fault. The system faults include, but are not limited to, at least one of the following: axis alarm faults, driver faults, limit switch abnormalities, and tracking error exceeding tolerance faults of the motion control board; and channel short circuit faults, channel open circuit faults, and communication interruption faults of the IO control board. The monitoring terminal has preset system fault determination rules, which set corresponding determination conditions for different types of faults. The monitoring terminal compares the board's operating status data for the current period with the preset determination conditions. When the data meets any one of the fault determination conditions, the change in operating status is determined to be due to a system fault.

[0059] For example, for the axis alarm fault of the motion control board, the judgment condition is that the alarm code bit in the axis status data is a non-zero value; for the tracking error exceeding the tolerance fault, the judgment condition is that the absolute value of the difference between the actual position and the target position of the axis exceeds the preset tracking error threshold; for the communication interruption fault of the IO control board, the judgment condition is that valid input and output status data cannot be read through the underlying IO driver interface within two consecutive acquisition cycles.

[0060] It should be noted that the monitoring terminal has a pre-set fault type mapping table, which stores the fault type identifier corresponding to each type of system fault. When a system fault is identified, the monitoring terminal queries the fault type mapping table to determine whether the fault type of the system fault is an acute basic fault.

[0061] Acute basic system faults can typically be queued through simple restarts or switching, allowing the monitoring process to directly identify them and determine troubleshooting strategies in real time. This is achieved by issuing troubleshooting commands to quickly resolve the system fault and prevent business processing failures. Specifically, when a system fault is determined to be an acute basic fault, the monitoring terminal queries a pre-defined fault handling rule table based on the fault type to determine the corresponding troubleshooting command. The troubleshooting command is a hardware control instruction directly sent to the corresponding board via the board's underlying driver interface. The command content includes, but is not limited to, command type, target board identifier, target channel or axis identifier, and command parameters. Upon receiving the troubleshooting command, the board immediately executes the corresponding action to attempt to resolve the acute basic fault. The fault handling rule table stores a sequence of troubleshooting commands for different acute basic faults, supporting the execution of single or combined commands. The execution order and interval of the commands can be configured according to the fault type.

[0062] Of course, in some implementations, the monitoring process can only troubleshoot acute basic faults with simple troubleshooting instructions. However, there are still cases where the troubleshooting instructions cannot achieve the desired effect. Therefore, to avoid the fault persisting for a long time and affecting the business process, in this optional implementation, after issuing the troubleshooting instruction, it is determined at preset time intervals whether the acute basic fault still exists. If it still exists after the preset time interval, in order to ensure the smooth processing of the business, an acute fault event notification message is sent to the main application so that the main application can use preset fault handling logic such as business rollback to quickly troubleshoot the fault, thereby ensuring the efficiency of fault troubleshooting and business processing.

[0063] Specifically, after issuing a troubleshooting command, the monitoring terminal continuously collects the board's operational status data in each subsequent collection cycle to determine whether the corresponding acute basic fault has been resolved. If, after a preset time period, the collected board operational status data still shows the existence of the acute basic fault, the troubleshooting is deemed unsuccessful. The monitoring terminal then sends an acute fault event notification signal to the main application. The main application queries a preset fault handling logic table, matches the fault handling logic corresponding to the acute basic fault, and executes the corresponding handling operation. The fault handling logic table stores the handling procedures corresponding to different fault types, including but not limited to emergency stop, power cut-off, alarm prompt, log recording, and process pause.

[0064] In embodiments achievable under this application, such as Figure 5 As shown, the method further includes: S501 determines whether board operating status change data is generated at preset time intervals. If not, it reads board operating status data from multiple consecutive acquisition cycles, verifies the values ​​of all data items, and confirms the stagnation type corresponding to the absence of board operating status change data.

[0065] S502, based on the confirmed stall type, performs the corresponding hardware link verification and generates the corresponding hardware link verification result.

[0066] S503 generates stall fault information data based on the hardware link verification result, writes the stall fault information data to the fault storage partition of the shared data area, and updates the fault status flag bit so that the main application can match the preset fault handling logic based on the received stall fault event notification signal.

[0067] It should be noted that another feasible fault handling embodiment of this application is to set a stagnation state monitoring timer in the monitoring terminal. The timing period of the stagnation state monitoring timer is longer than the acquisition period of the board operation status data. This timing period is a preset time period. Every time the stagnation state monitoring timer passes a preset time period, it triggers a stagnation state verification operation to confirm whether board operation status change data has been generated within the preset time period.

[0068] In this embodiment, when it is determined that no board operation status change data is generated within a preset time interval, the monitoring terminal reads board operation status data from the local cache for multiple consecutive collection cycles. The number of collection cycles read is greater than or equal to the total number of collection cycles within the preset time interval, ensuring coverage of the entire set time range of the stagnation state. The monitoring terminal performs numerical verification on each data item of the board operation status data read in all collection cycles, verifying whether the value of each data item remains unchanged within multiple consecutive collection cycles and whether the value is within a preset reasonable range. Based on the verification results, the stagnation type corresponding to the absence of board operation status change data is confirmed. The numerical verification operation includes data consistency verification and data reasonableness verification. Data consistency verification is used to confirm whether the data remains fixed within consecutive cycles, and data reasonableness verification is used to confirm whether the data is within the numerical range corresponding to normal device operation, thereby distinguishing between normal standby stagnation and abnormal collection or communication stagnation.

[0069] It should be noted that the types of stagnation include, but are not limited to, device standby stagnation, data acquisition stagnation, and hardware communication stagnation. For example, when the confirmed stagnation type is data acquisition stagnation or hardware communication stagnation, the monitoring terminal performs the corresponding hardware link verification operation based on the confirmed stagnation type. The hardware link verification operation includes, but is not limited to, at least one of driver interface status verification, board hardware connection verification, communication bus status verification, and board power supply status verification. Different stagnation types correspond to different hardware link verification processes. The monitoring terminal has a preset mapping relationship between stagnation types and verification processes. Based on the confirmed stagnation type, the corresponding verification process is executed, generating the corresponding hardware link verification result. The hardware link verification result includes verification items, verification results, abnormal location, error code, and other information. The execution of the hardware link verification operation will not affect the normal status acquisition process of the monitoring terminal. The verification operation is executed in an independent verification thread, running in parallel with the data acquisition thread to avoid fluctuations in the acquisition cycle caused by the verification operation.

[0070] In this embodiment, the monitoring terminal generates corresponding stall fault information data based on the hardware link verification results. This stall fault information data includes, but is not limited to, fault type identifier, fault occurrence timestamp, hardware link verification results, board operating status data for the corresponding acquisition period, and fault level identifier. A separate fault storage partition is pre-set in the shared data area to store fault-related information data. After generating the stall fault information data, the monitoring terminal writes the stall fault data into the fault storage partition of the shared data area.

[0071] It should be noted that the fault status flag is an independent flag segment within the status flag, used to identify the system's fault status. After completing the writing of the stalled fault information data, the monitoring terminal updates the corresponding data bits in the fault status flag according to the fault type and level, marking the existence and type of the fault, and simultaneously sends a stalled fault event notification signal to the main application. The stalled fault event notification signal is an independent event notification signal. Upon receiving this signal, the main application reads the fault status flag from the status flag in the shared data memory to confirm the fault type, then reads the corresponding stalled fault information data from the fault storage partition, queries the preset fault handling logic table, matches the fault handling logic corresponding to the stalled fault, and executes the corresponding handling operation.

[0072] A second aspect of this application provides a board status monitoring and event-driven method, including: The system receives event notification signals transmitted from the monitoring terminal, reads the board operating status change data from the shared data memory, and executes corresponding business processing. The event notification signal is generated by the monitoring terminal acquiring board operating status data collected according to a preset period. Based on the current period's board operating status data and the previous period's board operating status data, the system determines whether the board's operating status has changed. If so, it generates board operating status change data and writes the board operating status change data into the preset shared data memory, based on the current period's board operating status data.

[0073] In this embodiment, the main application receives event notification signals transmitted by the monitoring terminal, reads data from the shared data memory based on the event notification signals, and executes corresponding business processes to realize functions such as equipment process control, human-machine interaction, and security protection. The main application and the monitoring terminal are two completely independent processes with their own independent memory space and thread scheduling resources. The running state of the main application will not affect the status acquisition and event notification functions of the monitoring terminal. Even if the main application experiences lag, crashes, or becomes unresponsive, the monitoring terminal can still continuously perform board status acquisition, fault identification, and fault troubleshooting operations to ensure the continued effectiveness of the equipment's basic security protection functions.

[0074] In embodiments achievable under this application, such as Figure 6 As shown, the step of reading the board's operating status change data from the shared data memory and executing the corresponding business processing includes: S601, obtain the running status identifier from the status identifier bit of the shared data memory, and verify whether the running status identifier has been updated.

[0075] S602, if so, obtain the current cycle board running status data of the board from the shared data area of ​​the shared data memory, and determine the current service cycle status.

[0076] S603: If the current business cycle is completed, the next business cycle is determined based on the preset business chain, the corresponding business processing instruction is generated and transmitted to the corresponding board for execution.

[0077] Specifically, after receiving an event notification signal, the main application first reads the running status identifier from the starting address area of ​​the shared data memory. After obtaining the running status identifier, the main application compares it bit by bit with the historical running status identifier stored during the last business process to verify whether the running status identifier has been updated. If there is any difference between the running status identifier and the historical running status identifier, it is determined that the running status identifier has been updated, and subsequent data acquisition operations are performed. If the running status identifier is completely consistent with the historical running status identifier, it is determined that the running status identifier has not been updated, the current business process ends, and the application waits for the next event notification signal to be triggered.

[0078] In this embodiment, after verifying that the running status identifier has been updated, the main application classifies the changed data items marked in the running status identifier and reads the corresponding category of the current cycle board running status data from the shared data area of ​​the shared data memory. This eliminates the need to read all data in the shared data area, thereby reducing data reading time and improving the response speed of business processing. After obtaining the current cycle board running status data, the main application combines the current operating process, process parameters, and historical operating data to determine the current business cycle state of the equipment. The business cycle state includes, but is not limited to, at least one of the following: equipment standby state, process execution state, fault handling state, emergency stop state, and maintenance state.

[0079] It should be noted that the main application pre-sets a pre-defined business chain for device operation. This pre-defined business chain is an ordered set of all business cycles required for the device to complete a full production or testing process. Each business cycle corresponds to a specific operation step of the device, and clear triggering conditions and execution order are set between business cycles. The completion status of the previous business cycle is the triggering condition for starting the next business cycle. After determining the status of the current business cycle, the main application verifies whether all processing operations of the current business cycle have been completed. If the current business cycle is completed, it determines the next business cycle based on the order of the pre-defined business chain. At the same time, according to the execution requirements of the next business cycle, it generates corresponding business processing instructions. These business processing instructions include, but are not limited to, at least one of the following: motion control instructions, IO event notification module control instructions, and parameter configuration instructions.

[0080] Specifically, after the main application generates the corresponding business processing instruction, it calls the corresponding underlying driver interface based on the instruction type to transmit the instruction to the corresponding board for execution. Motion control-related instructions are transmitted to the motion control board via the underlying operation control driver interface. I / O event notification module control instructions are transmitted to the I / O control board via the I / O control driver interface. Upon receiving the business processing instruction, the board immediately parses the instruction content, executes the corresponding hardware control action, and simultaneously feeds back the execution result and status update data to the monitoring terminal via the underlying driver interface. The monitoring terminal then collects the board's operating status update data in the next acquisition cycle.

[0081] The third aspect of this application provides a monitoring terminal, such as... Figure 7 As shown, it includes: The acquisition module 100 is used to acquire board operating status data collected according to a preset cycle, and determine whether the operating status of the board has changed based on the current cycle board operating status data and the previous cycle board operating status data. If so, it generates board operating status change data. The shared data module 200 is used to write the board's operating status change data into a preset shared data memory; The event notification module 300 is used to send an event notification signal to the main application based on the current period board operating status data, so that the main application can read the current period board operating status data in the shared data memory and perform corresponding business processing in response to the received event notification signal.

[0082] The fourth aspect of this application provides a main program terminal, including: The main application module is used to receive event notification signals transmitted by the monitoring terminal, read the current period board operating status data in the shared data memory, and execute corresponding business processing. The event notification signal is obtained by the monitoring terminal from board operating status data collected according to a preset period. Based on the current period board operating status data and the previous period board operating status data, it is determined whether the board operating status has changed. If so, board operating status change data is generated; the board operating status change data is written into the preset shared data memory, which is based on the current period board operating status data.

[0083] The fifth aspect of this application provides a board status monitoring and event-driven system, such as... Figure 8 As shown, it includes a monitoring terminal 400, a main program terminal 500, and a board 600; The monitoring terminal 400 acquires board operation status data collected according to a preset cycle. Based on the current cycle board operation status data and the previous cycle board operation status data, it determines whether the operation status of the board 600 has changed. If so, it generates board operation status change data, writes the board operation status change data into a preset shared data memory, and sends an event notification signal to the main application of the main program terminal 500 based on the current cycle board operation status data. This enables the main application to read the board operation status change data in the shared data memory in response to the received event notification signal and execute the corresponding business processing.

[0084] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0085] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A board status monitoring and event-driven method, characterized in that, include: Acquire board operating status data collected according to a preset cycle, determine whether the board's operating status has changed based on the current cycle's board operating status data and the previous cycle's board operating status data, and if so, generate board operating status change data. Write the board's operating status change data to the preset shared data memory; Based on the current cycle board operating status data, an event notification signal is sent to the main application, so that the main application can read the current cycle board operating status data in the shared data memory in response to the received event notification signal and execute the corresponding business processing.

2. The board status monitoring and event-driven method according to claim 1, characterized in that, The shared data memory includes a status flag bit and a shared data area. The generation of board operating status change data includes: An operating status identifier is generated based on the change in the board's operating status, and the operating status identifier and the current period's board operating status data are used as the board operating status change data; The step of writing the board's operating status change data into a preset shared data memory includes: Update the status flag bit in the shared data memory based on the running status flag; Write the current cycle board operating status data into the shared data area of ​​the shared data memory.

3. The board status monitoring and event-driven method according to claim 1, characterized in that, The board includes a motion control board and an I / O control board. The step of acquiring the board's operating status data collected according to a preset period includes: A data acquisition command is generated by triggering a periodic timer according to a preset cycle. In response to the acquisition command, the device operating status data of the motion control board is read through the underlying operation control driver interface; The input / output status data of the IO control board is read through the underlying IO driver interface. Based on the read device operating status data and input / output status data, board operating status data is generated and temporarily stored in the local cache.

4. The board status monitoring and event-driven method according to claim 1, characterized in that, The method further includes: If the operating state of the board changes, determine whether the reason for the change in the operating state of the board is a system fault. If so, determine whether the fault type of the system fault is an acute basic fault. If it is an acute basic fault, determine the corresponding fault troubleshooting instruction and transmit it to the corresponding board for execution to eliminate the acute basic faults of all boards; otherwise, continue to execute the step of sending an event notification signal to the main application. If the acute basic fault still exists after a preset time period, an acute fault event notification signal is sent to the main application so that the main application can match the preset fault handling logic based on the received acute fault event notification signal.

5. The board status monitoring and event-driven method according to claim 1, characterized in that, The method further includes: At each preset time interval, determine whether board operation status change data is generated. If not, read board operation status data within multiple consecutive collection cycles, verify the values ​​of all data items, and confirm the stagnation type corresponding to the absence of board operation status change data. Based on the confirmed stall type, perform the corresponding hardware link verification and generate the corresponding hardware link verification result. Based on the hardware link verification results, stagnation fault information data is generated, written to the fault storage partition of the shared data area, and the fault status flag is updated so that the main application can match the preset fault handling logic based on the received stagnation fault event notification signal.

6. A board status monitoring and event-driven method, characterized in that, include: The system receives event notification signals transmitted from the monitoring terminal, reads the board operating status change data from the shared data memory, and executes corresponding business processing. The event notification signal is generated by the monitoring terminal acquiring board operating status data collected according to a preset period. Based on the current period's board operating status data and the previous period's board operating status data, the system determines whether the board's operating status has changed. If so, it generates board operating status change data and writes the board operating status change data into the preset shared data memory, based on the current period's board operating status data.

7. The board status monitoring and event-driven method according to claim 6, characterized in that, The step of reading the board operating status change data in the shared data memory and executing the corresponding business processing includes: Obtain the running status identifier from the status identifier bits of the shared data memory, and verify whether the running status identifier has been updated; If so, obtain the current cycle board running status data from the shared data area of ​​the shared data memory to determine the current service cycle status; If the current business cycle is completed, the next business cycle is determined based on the preset business chain, and the corresponding business processing instructions are generated and transmitted to the corresponding board for execution.

8. A monitoring terminal, characterized in that, include: The acquisition module is used to acquire board operating status data collected according to a preset cycle, and determine whether the operating status of the board has changed based on the current cycle board operating status data and the previous cycle board operating status data. If so, it generates board operating status change data. The shared data module is used to write the board's operating status change data into the preset shared data memory; The event notification module is used to send an event notification signal to the main application based on the current cycle board operating status data, so that the main application can read the current cycle board operating status data in the shared data memory and execute the corresponding business processing in response to the received event notification signal.

9. A main program terminal, characterized in that, include: The main application module is used to receive event notification signals transmitted by the monitoring terminal, read the current period board operating status data in the shared data memory, and execute corresponding business processing. The event notification signal is obtained by the monitoring terminal from board operating status data collected according to a preset period. Based on the current period board operating status data and the previous period board operating status data, it is determined whether the board operating status has changed. If so, board operating status change data is generated; the board operating status change data is written into the preset shared data memory, which is based on the current period board operating status data.

10. A board status monitoring and event-driven system, characterized in that, Includes monitoring terminals, main program terminals, and circuit boards; The monitoring terminal acquires board operation status data collected according to a preset cycle. Based on the current cycle's board operation status data and the previous cycle's board operation status data, it determines whether the board's operation status has changed. If so, it generates board operation status change data, writes the board operation status change data into a preset shared data memory, and sends an event notification signal to the main application of the main program terminal based on the current cycle's board operation status data. This causes the main application to respond to the received event notification signal, read the board operation status change data in the shared data memory, and execute the corresponding business processing.

Images