Secondary equipment interface communication detection method and device

Abstract

The invention provides a secondary equipment interface communication detection method and device, and relates to the technical field of power and electricity. The method comprises the following steps: acquiring a detection request instruction input by a user for secondary equipment interface communication detection, and analyzing the detection request instruction to determine the type of an interface to be detected; wherein the type of the interface comprises a serial port and a network port; when the type of the to-be-detected interface is a serial port, displaying a text input box of test data, and starting a serial port detection process; when the type of the to-be-detected interface is a network port, displaying a text input box of a target IP address, and starting a network port detection process; and determining a detection result of the to-be-detected interface according to an analysis result of the received data in the detection process, and outputting the detection result to a display interface. According to the invention, the secondary equipment interface communication detection efficiency can be improved.

Description

Technical Field

[0001] This invention relates to the field of power and electrical technology, and in particular to a method and apparatus for detecting interface communication of secondary equipment. Background Technology

[0002] As a vital component of national infrastructure and the lifeline of the national economy, the safe and stable operation of the power system is crucial to national economic development and people's livelihoods. Within the power system, the safe and stable operation of secondary equipment ensures the stable operation of the power grid, encompassing multiple key areas such as relay protection, automation control, data monitoring, and communication transmission. With the widespread adoption of information technology, smart grids have emerged, requiring information exchange and transmission between secondary equipment to rely more heavily on high-speed and reliable communication networks. However, communication outages can not only lead to the loss of localized functions but may also trigger the collapse of the entire power grid system, potentially causing significant social impact.

[0003] If communication with secondary equipment is interrupted, the protection device will be unable to receive fault information from adjacent areas, leading to protection logic failure. Furthermore, communication interruptions in secondary equipment may disrupt the coordination of the Wide Area Measurement System (WAMS). For example, when low-frequency oscillations occur in the power grid, if the data from the phasor measurement unit (PMU) cannot be transmitted to the control center, the system cannot activate the stabilization and control devices in a timely manner, potentially leading to an expansion of the oscillation range or even causing the entire network to lose synchronization and disconnect. Therefore, the reliability of secondary equipment network communication is extremely important. With economic development, the structure of power systems has become increasingly complex. When network communication failures occur in secondary equipment, accurately and quickly locating the fault within the complex power system becomes crucial. This is of great significance for improving the stability and security of the power system.

[0004] Accurately diagnosing communication faults in secondary equipment relies heavily on the experience of professional maintenance personnel, as these faults are often hidden and difficult to detect. Different equipment models require different tools for troubleshooting, necessitating maintenance personnel to have an accurate understanding of the equipment in each substation. There is a lack of solutions to improve the efficiency of secondary equipment interface communication testing. Summary of the Invention

[0005] This invention provides a method and apparatus for detecting interface communication of secondary devices, in order to solve the problem of low efficiency caused by traditional detection schemes that rely on manual experience.

[0006] In a first aspect, embodiments of the present invention provide a method for detecting communication at a secondary device interface. The system acquires a user-inputted detection request command for secondary device interface communication detection, and parses the detection request command to determine the type of the interface to be detected; wherein, the interface type includes serial port and network port. When the type of the interface to be tested is a serial port, a text input box for the test data is displayed, and the serial port testing process is started; when the type of the interface to be tested is a network port, a text input box for the target IP address is displayed, and the network port testing process is started. The detection result of the interface to be tested is determined based on the parsing result of the data received in the detection process, and the detection result is output to the display interface.

[0007] In one possible implementation, the serial port detection process includes: Initialize and configure the baud rate and data frame format of the Universal Synchronous / Asynchronous Receiver / Transmitter (USART); Obtain the test data input by the user, send the formatted test data to the interface to be tested, and append an end flag to the end of the data frame; Response data is received via interrupt and stored in a buffer; The start flag and instruction type in the response data are parsed to determine the serial communication status.

[0008] In one possible implementation, sending formatted test data to the interface to be tested and appending an end marker to the end of the data frame includes: The test data is formatted into a data frame conforming to the serial communication protocol and written into the transmission buffer; After the complete data frame is sent, append at least three 0xFF bytes as an end marker.

[0009] In one possible implementation, the step of parsing the start flag and instruction type in the response data to determine the serial communication status includes: The system searches for the start flag in the data buffer. If the start flag is the first preset value, it executes a page-turning command. If the start flag is the second preset value, it parses the RS-485 communication data. The first preset value is 0x65, and the second preset value is 0x55. The display interface is updated based on the parsing results to indicate whether the communication was successful or failed.

[0010] In one possible implementation, the network port detection process includes: Initialize the network communication module; the network communication module is ATK-MO395Q. Obtain the IP address entered by the user, send a PING request to the entered IP address, determine the network interface connectivity based on the response result, and display the connectivity result on the interface; where the connectivity result is PING successful or PING error.

[0011] In one possible implementation, the response result indicating normal network port connectivity also includes a Socket communication test; The Socket communication test includes: Configure the socket as a TCP client or UDP mode, and set the local port, target IP address, and port number; Data transmission is tested by handling communication events or data through Socket callback functions.

[0012] In one possible implementation, before obtaining the user input detection request instruction for secondary device interface communication detection, the method further includes: The system performs hardware layer initialization and application layer initialization; wherein, the hardware layer initialization includes clock initialization and peripheral initialization; the peripheral initialization includes: peripheral device initialization, motion controller initialization and network module initialization.

[0013] In one possible implementation, when receiving data during the detection process, the data is received through an interrupt handler, and the data protocol header is parsed to determine the type of communication data. When receiving data during the detection process, Process_Data_Reception() is used for corresponding interrupt handling, Parse_Protocol() is used for data parsing, and Process_Data_Reception() is used to determine the data type of the communication.

[0014] In one possible implementation, after outputting the detection result to the display interface, the method further includes: A detection log is generated based on the detection results and stored in a non-volatile memory; Among them, a detection log is generated based on the detection time, detection type, and detection result.

[0015] Secondly, embodiments of the present invention provide a secondary device interface communication detection device, characterized in that it includes: a processing unit based on STM32F103, an interface module for connecting to an RS-485 serial port, a network module for connecting to an RJ-45 network port, a human-machine interface, and a memory for storing computer programs and detection results. When the computer program is executed, it is used to implement the method in the first aspect or any possible implementation of the first aspect as described above.

[0016] In this embodiment of the invention, by first acquiring and parsing the user's detection request instruction to clarify the type of interface to be detected, then providing corresponding input boxes for serial ports and network ports respectively and starting a dedicated detection process, and finally parsing the data to obtain the detection results and outputting them to the display interface, the integrated processing of serial port and network port communication detection is achieved. There is no need for maintenance personnel to prepare multiple detection tools. The operation process is simple and intuitive, which can quickly locate secondary device interface communication faults and effectively improve the convenience and efficiency of maintenance work. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of a serial port network communication detection algorithm implementation tool provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a network port detection application case provided by an embodiment of the present invention; Figure 3 This is a schematic diagram of a serial port detection application example provided by an embodiment of the present invention; Figure 4 This is a flowchart illustrating the implementation of a secondary device interface communication detection method according to an embodiment of the present invention. Figure 5 This is a flowchart illustrating the implementation of a secondary device interface communication detection method according to another embodiment of the present invention. Detailed Implementation

[0018] Substation protection and control devices communicate with backend and substation systems via RS-485 serial ports or RJ-45 network ports. Currently, older protection and control devices mostly use RS-485 serial communication, which is essentially a half-duplex communication protocol based on differential signal transmission. However, some newer protection and control devices lack status indicator lights on their network ports, making it difficult for maintenance personnel to visually determine whether the port has a physical connection. This makes it difficult to intuitively and accurately determine whether the serial or network port is damaged, especially given the frequent communication interruptions that occur during the operation of protection and control devices. Furthermore, the lack of standardized equipment for checking serial and network ports severely impacts troubleshooting efficiency.

[0019] This invention addresses the aforementioned technical pain points by designing and developing a serial / network communication detection algorithm based on the STM32F103 microcontroller. It integrates a dual-mode detection module for RS-485 and RJ-45, automatically selecting and identifying the interface type and switching test modes. Unlike traditional signal detection methods, this system requires no configuration and utilizes different signal analysis algorithms for automatic detection and analysis. Through a signal acquisition system and signal analysis algorithms, it automatically analyzes the signals received at the port and provides results. This achieves the goal of automatically and quickly locating faults and automatically detecting communication status, while also addressing the lack of tools for automatically detecting serial / network port status.

[0020] To achieve automatic signal analysis, this invention incorporates the necessary configurations into the program during development and implements the algorithm corresponding to this secondary device interface communication detection method. This algorithm is then encapsulated in a compact and convenient housing, greatly facilitating its use by maintenance personnel. When performing secondary device communication maintenance, this invention solves the problems of maintenance personnel lacking practical communication testing and diagnostic tools, requiring different maintenance devices for devices with various interfaces, and the complexity of the maintenance process, which hinders effective and rapid fault location.

[0021] like Figure 1 The diagram shows the principle of the serial port / network port communication detection algorithm implementation tool provided in this embodiment of the invention. The software development of this invention is based on the LINUX platform, using the C programming language and a compiled language to write the program. The source code is open, allowing for expansion of tripping nodes in subsequent protection devices. The Keil uVision4 integrated development environment is used, including a C compiler, macro assembler, linker, library manager, and simulator / debugger. The algorithm module is also designed with a handheld appearance, serving as a dedicated handheld detection tool for communication interruptions in substation protection devices, facilitating intuitive operation by protection personnel.

[0022] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0023] Figure 2 and Figure 3 This is a schematic diagram illustrating an application example of the secondary device interface communication detection method provided in an embodiment of the present invention.

[0024] like Figure 2 The diagram illustrates an application case of RJ-45 network port detection. It shows a connection between the network port module and the protection and control device's network port. The protection and control device queries its own IP address and manually inputs this IP address into the detection algorithm. The algorithm then uses the PING test function within its internal communication to diagnose the status of the protection and control device's network port. The diagnostic results are displayed intuitively on the screen, allowing maintenance personnel to quickly determine the network port's operational status and take timely emergency repair measures to ensure the stable operation of the power system.

[0025] like Figure 2 The diagram illustrates an RS-485 serial port detection application. The tool connects to the 485 serial port of the protection and control device via a 485 acquisition module. It sends specific data to the device and compares this data with the received data to diagnose any faults in the serial port. The diagnostic results are then displayed intuitively in the upper right corner of the screen, indicating whether the serial port is functioning correctly.

[0026] In practice, when checking the network connection status, turn on the settings switch and click the network port connection status button. If it shows success, the connection is normal; otherwise, it fails.

[0027] Setting Mode Buttons: 0 for TCP Server Mode; 1 for TCP Client Mode; 2 for UDP Server Mode; 3 for UDF Client Mode. If set to server mode, you need to configure the local IP address, subnet mask, gateway, and port number. If set to client mode, only the destination IP address and port number need to be configured. DHCP and port randomization are both enabled (1) and disabled (0). After setting the parameters, save, then execute and reset. When the setting switch is on, the device will temporarily not send messages to the server or client via the network port. Figure 4 This is a flowchart illustrating the implementation of a secondary device interface communication detection method according to an embodiment of the present invention, as shown below. Figure 4 As shown, it includes the following steps: S401: Obtain the user input of a detection request command for secondary device interface communication detection, and parse the detection request command to determine the type of the interface to be detected; wherein, the interface type includes serial port and network port.

[0028] In practice, maintenance personnel input a detection request command through the interactive interface of a handheld substation monitoring device to address communication faults in secondary equipment. This command must include the detection requirements for the target interface, such as "detection device RS-485 serial port" or "detection device RJ-45 network port".

[0029] The system extracts interface type information from the instructions through a preset instruction parsing module, accurately distinguishing whether the interface to be tested is a serial port or a network port, providing a basis for the subsequent targeted start-up of the testing process, and avoiding the cumbersome operation of manually switching tools or modes in traditional testing.

[0030] S402: When the type of the interface to be tested is serial port, display the text input box for test data and start the serial port testing process; when the type of the interface to be tested is network port, display the text input box for the target IP address and start the network port testing process.

[0031] Serial communication, also known as serial port communication, is one of the most basic forms of data transmission. During information exchange, it transmits information bit by bit in sequence. This communication method is simple, low-cost, and widely used for data exchange between microcontrollers, PCs, and embedded systems. In serial communication, data packets are transmitted from the sending device to the receiving device's RXD interface via its own TXD interface.

[0032] Network communication is a communication protocol used for data transmission. Common network communication protocols include Transmission Control Protocol (TCP) (reliable connection) and User Datagram Protocol (UDP) (connectionless). When communicating, an IP address and port need to be specified. The communication data frame format includes a frame header, length, data field, and stop bits. Compared to serial communication, network communication has a faster transmission rate, can be transmitted over local area networks (LANs) or wide area networks (WANs), and can cover longer distances. Network communication uses a network cable connection and requires network devices such as routers or switches for connection.

[0033] The system initiates the corresponding testing process based on the interface type specified in the testing request command. If the interface to be tested is determined to be a serial port, such as the RS-485 serial port commonly used in secondary equipment, the system automatically displays a text input box for test data on the interactive interface, allowing maintenance personnel to input test content conforming to the equipment's communication protocol, and then initiates the serial port testing process. If the interface to be tested is a network port, such as an RJ-45 network port, a text input box for the IP address is displayed, allowing maintenance personnel to input the network port IP address of the secondary equipment, and then initiates the network port testing process.

[0034] By binding "interface type - input box - testing process", the testing operation is ensured to be highly targeted, and maintenance personnel do not need to remember the testing steps for different interfaces.

[0035] S403 determines the detection result of the interface to be tested based on the parsing result of the data received in the detection process, and outputs the detection result to the display interface.

[0036] Regardless of whether the serial port or network port testing process is initiated, the system will determine the communication status of the interface under test based on the parsing results of the received data after the process is completed. For example, it will display "Serial communication normal" or "Network port connection failed," and output the result to the display interface in a combination of text and icons. Furthermore, to meet subsequent traceability needs, testing logs can be generated and stored.

[0037] In this embodiment, by first acquiring and parsing the user's detection request instruction to clarify the type of interface to be detected, then providing corresponding input boxes for serial ports and network ports respectively, and starting a dedicated detection process, and finally parsing the data to obtain the detection results and outputting them to the display interface, the integrated processing of serial port and network port communication detection is realized. There is no need for maintenance personnel to prepare multiple detection tools. The operation process is simple and intuitive, and it can quickly locate secondary device interface communication faults, effectively improving the convenience and efficiency of maintenance work.

[0038] The above mainly summarizes the secondary device interface communication detection method, which can be used to automatically detect communication between serial ports and network ports. The following section elaborates on the serial port detection process and the network port detection process.

[0039] In one possible implementation, the serial port detection process includes: Initialize and configure the baud rate and data frame format of the general USART; Obtain the test data input by the user, send the formatted test data to the interface to be tested, and append an end marker to the end of the data frame; Response data is received via interrupt and stored in a buffer; The start flag and instruction type in the response data are parsed to determine the serial communication status.

[0040] The general-purpose USART parameter configuration needs to be adapted to the communication parameters of the serial port of the secondary device under test, including baud rate and data frame format (such as data bit length, parity bit type, and number of stop bits). This invention communicates with Human Machine Interface (HMI) devices via a general-purpose USART and processes commands and data from the HMI. Serial communication generally transmits data in frame format, with each frame containing a start signal, data information, stop information, and possibly parity information. USART provides specific specifications for these transmission parameters, but the parameter values ​​are not unique, greatly enhancing its compatibility.

[0041] After initialization, the USART module enters a ready state, establishing a stable physical communication link with the secondary device's serial port, avoiding "no response" or "data parsing error" caused by parameter mismatch. After maintenance personnel input test data through the text input box, the system first formats the test data into a standard data frame according to the serial communication protocol, ensuring that the secondary device can recognize and parse the data. Then, the formatted complete data frame is sent to the serial port under test, and a preset end flag is appended after transmission to clearly inform the secondary device that "data transmission is complete," preventing the secondary device from failing to respond due to not receiving complete data.

[0042] The USART module includes a transmit data output pin (TX), a receive data input pin (RX), a data receive pin (SW_RX), a request to transmit (nRTS), a clear to transmit (nCTS), and a transmitter clock output pin (SCLK). The USART data register (USART_DR) contains the transmitted or received data. USART_DR actually contains two registers: a dedicated writable transmit data register (TDR) for transmitting and a dedicated read data register (RDR) for receiving. When transmitting, data written to USART_DR is automatically stored in TDR; when reading, data read from USART_DR is automatically retrieved from RDR. During transmission, the contents of TDR are transferred to the transmit shift register, and then each bit of data in the shift register is transmitted. During reception, each bit of data received is sequentially stored in the receive shift register before being transferred to RDR. In addition, the USART has a dedicated transmitter for controlling transmission, a receiver for controlling reception, a wake-up unit, and interrupt control.

[0043] In practice, data is received via an interrupt handler. When the USART detects data input on the receive pin, it automatically triggers a receive interrupt, pausing the current non-core tasks and reading and storing the response data into a preset buffer. After data reception is complete, the interrupt releases the Central Processing Unit (CPU) resources, allowing other tasks to resume execution. Interrupt-based reception avoids wasting CPU resources while ensuring no response data is lost, making it particularly suitable for scenarios where secondary devices may experience "response delays."

[0044] After receiving the response data, the system calls the protocol parsing module to extract the response data from the buffer. It first searches for the start flag in the data, and then parses the data content according to the instruction type corresponding to the start flag. If the parsed data matches the expected response of the test data (e.g., the test instruction is "query device status" and the response is "status normal"), then the serial communication is considered normal. If no response data is received, the data parsing is incorrect, or the response is inconsistent with expectations, then the serial communication is considered faulty, and the result is displayed on the screen.

[0045] In this embodiment, the USART baud rate and data frame format are initialized to establish a unified standard for serial communication, ensuring communication compatibility. Then, user test data is acquired and formatted data is sent. At the same time, response data is received and stored in a timely manner via interrupt. Finally, the communication status is determined by parsing the start flag and instruction type of the response data. The entire process is interconnected, which not only ensures the standardization of data transmission but also ensures the timeliness of data reception and the relevance of parsing. It can accurately determine the serial communication status and reduce the false judgment rate of serial port detection.

[0046] In one possible implementation, formatted test data is sent to the interface to be tested, and an end marker is appended to the end of the data frame, including: The test data is formatted into data frames conforming to the serial communication protocol and written to the transmit buffer; After the complete data frame is sent, append at least three 0xFF bytes as an end marker.

[0047] After acquiring the raw test data input by the maintenance personnel, the system calls a preset formatting function, such as `Formatstringtobuffer()`, to encapsulate the raw data into a standard data frame according to the communication protocol followed by the serial port of the secondary device under test. After completing the protocol-based formatting of the data frame, the system first writes the complete data frame into the USART's transmit buffer, and the USART module transmits it byte by byte at the initially configured baud rate. Once all data in the transmit buffer has been transmitted, the system automatically appends at least three 0xFF bytes as an end marker to the transmit link.

[0048] Choosing "at least three 0xFF bytes" instead of a single byte as the end marker is to avoid "pseudo-end bytes" caused by interference during transmission, which could lead to secondary devices misjudging the data frame boundary. For example, if the data frame itself contains a single 0xFF byte, the single end marker might be mistaken by the secondary device as "the data frame has not ended." However, multiple consecutive 0xFF bytes can form a clear "end of data frame" signal, ensuring that the secondary device can accurately determine when to stop receiving data and start parsing.

[0049] In this embodiment, the test data is formatted into a data frame conforming to the serial communication protocol and written into the transmission buffer to ensure that the data transmission conforms to the serial communication specification. After the complete data frame is sent, at least three 0xFF bytes are appended as an end marker so that the receiver can clearly identify the boundary of the data frame and avoid incomplete data reception or misinterpretation, thereby ensuring the accuracy and integrity of data transmission during the serial port detection process.

[0050] In one possible implementation, the start flag and instruction type in the response data are parsed to determine the serial communication status, including: The start flag in the data buffer is searched. If the start flag is the first preset value, the page turning instruction is executed. If the start flag is the second preset value, the RS-485 communication data is parsed. The display interface is updated based on the parsing results to indicate whether the communication was successful or failed.

[0051] After reading the response data from the buffer, a parsing function, such as HMI_Protocol_Analysis(), is called to traverse the data byte sequence to find the preset start flag. The start flag has two different preset values, each corresponding to a different type of response instruction. For example, when the secondary device receives an "interface control instruction," such as the "switch display page" instruction entered by a maintenance personnel, it will return response data with the first preset value as the start flag. When it receives a "function query instruction," such as the "query serial communication status" instruction, it will return response data with the second preset value as the start flag.

[0052] In this implementation, the instruction type is distinguished by a start flag to avoid misjudging "interface control response" as "communication status response".

[0053] In one possible implementation, the first preset value is 0x65; the second preset value is 0x55. In other embodiments, the first and second preset values ​​can be adjusted according to specific instructions.

[0054] If the starting flag is the second preset value, it indicates that the response data corresponds to RS-485 communication data, and the system further parses the data field content. After parsing, the system determines the serial port communication status based on the data field content, forming a judgment result of "communication normal" or "communication abnormal". Finally, the above communication status judgment result is converted into intuitive display information, such as "RS-485 serial port communication normal" or "RS-485 serial port communication abnormal", and the display update function, such as the update_hmi_interface() function, is called to update the result to the display interface in real time.

[0055] In other possible implementations, if the judgment result is abnormal, the interface can simultaneously display troubleshooting instructions such as "It is recommended to check the serial port wiring / device power supply" to further reduce the operational difficulty for maintenance personnel.

[0056] In this embodiment, the method achieves accurate differentiation and targeted processing of different types of instructions by finding the start flag in the data buffer and executing page-turning instructions and parsing RS-485 communication data according to the first preset value and the second preset value, respectively. Then, the display interface is updated in real time according to the parsing results, allowing maintenance personnel to intuitively obtain the status of serial communication success or failure, improving the timeliness and clarity of serial port detection result feedback, and facilitating maintenance personnel to quickly grasp the status of serial communication.

[0057] The above provides a general overview of the serial port detection process. The following section will explain the process using specific code examples to facilitate a clearer understanding of the serial port detection procedure.

[0058] In one specific embodiment, the code logic for communication between USART2 and the HMI device is as follows:

[0059] The HMI initialization process includes setting the serial port baud rate and data frame format:

[0060] Next, interrupts are enabled to wait for data to be sent. The data sending function needs to format the string:

[0061] First, the function `Formatstringtobuffer()` writes the data to be sent into the buffer and sends the formatted string via a string pointer. Second, the function `sendstring_to_HMI()` appends three 0xFF bytes as an end marker after the complete data frame has been sent. The main loop keeps the program running through an infinite loop. This design saves CPU resources and avoids busy waiting. When the USART receives data sent by the HMI device, a receive interrupt is triggered. At this time, the data is read and stored in the buffer, and then the `HMI_Protocol_Analysis()` function is called to parse the data.

[0062] The function HMI_Protocol_Analysis() searches for the start flag in the data buffer. If the flag is 0x65, it executes a page-turning instruction according to the instruction type. If the flag is 0x55, it processes the 485 serial communication data.

[0063] In one possible implementation, the network interface detection process includes: Initialize the network communication module; Obtain the IP address entered by the user, send a PING request to the entered IP address, determine the network interface connectivity based on the response result, and display the connectivity result on the interface; where the connectivity result is PING successful or PING error.

[0064] In one possible implementation, the network communication module is the ATK-MO395Q, which enables TCP protocol communication. The ATK-MO395Q module has a built-in PHY chip, enabling stable and efficient data transmission, supporting multiple transmission protocols, and providing a Socket interface to support multiple concurrent connections. Each interface can be independently configured in TCP client / server mode or UDP mode.

[0065] After initiating the network port detection process, the system first initializes and configures the integrated network communication module, completing the configuration of the module's hardware parameters and basic communication protocols. This ensures that the module can normally connect to the network environment where the secondary device is located, avoiding "no response" due to module incompatibility or parameter mismatch. During initialization, the system automatically verifies the module status. If initialization fails, an error message is generated and output to the display interface, reminding maintenance personnel to check the module connection or network environment.

[0066] After entering the network port IP address of the secondary device to be tested into the IP address text input box and verifying the validity of the entered IP address format, the maintenance personnel invoke the PING function of the network communication module to send a standard PING request data packet to that IP address. The PING request determines whether the network link between the network port and the secondary device is unobstructed by detecting the "send-receive-response" loop of the data packet. In essence, it verifies the basic connectivity between the two, such as whether the physical link is broken and whether the network route is reachable.

[0067] Finally, the network port connectivity is determined based on the PING response and the results are output. An interrupt is triggered upon receiving a PING response for rapid processing, obtaining feedback from the secondary device regarding the PING request. If the corresponding PING response data packet is received within a preset time, it indicates that the basic communication link between the network port and the secondary device is intact, and the system is deemed to have "normal network port connectivity." If no response is received within the timeout period, the received response data packet is corrupted, or packet loss occurs, the system is deemed to have "abnormal network port connectivity." The system converts the connectivity results into text or icon information and outputs it to the display interface.

[0068] In this embodiment, the network port detection process first initializes the ATK-MO395Q network communication module to provide stable hardware support for network port communication detection, then obtains the IP address input by the user and sends a PING request. Based on the response result, the network port connectivity is directly determined and displayed. There is no need for maintenance personnel to perform complex network configuration operations. It can quickly and intuitively provide feedback on whether the network port is connected normally, simplifying the operation steps of network port connectivity detection and improving the efficiency of preliminary network port detection.

[0069] The above network port testing process cannot determine whether the network port can transmit business data normally by relying solely on PING requests, and the comprehensiveness of the network port data transmission function testing needs to be improved.

[0070] In one possible implementation, when the response indicates that the network interface connectivity is normal, a Socket communication test is also included. Socket communication testing includes: Configure the socket as a TCP client or UDP mode, and set the local port, target IP address, and port number; Data transmission is tested by handling communication events or data through Socket callback functions.

[0071] After determining that "network port connectivity is normal," a Socket communication test is automatically triggered. If connectivity is abnormal, this step is skipped, and the abnormal result is output directly. Based on the communication protocol type of the secondary device's network port under test, the Socket configuration function is called to configure the system's Socket interface to the corresponding working mode. If the secondary device uses reliable data transmission, it is configured as a TCP client; if it uses efficient data broadcasting, such as real-time device status reporting, it is configured as a UDP mode. During the configuration process, the "local port number" and "secondary device target port number" are obtained, and the binding of the local port, target IP address, and target port number is completed using the Set_Socket_Destination() class function to ensure that the Socket communication link accurately points to the service network port of the secondary device under test.

[0072] The system calls the `Set_Socket_Callback()` class function to bind a dedicated callback function to the configured Socket interface. The core function of this callback function is to respond in real-time to various events during Socket communication, such as "connection successful," "data received," and "connection disconnected." When the Socket successfully establishes a connection with the secondary device's network port, the callback function triggers the "connection successful" event, pushing a notification to the display interface. When business data is received from the secondary device, the callback function triggers the "data received" event, temporarily storing the received data in a buffer and marking it as "to be parsed." When the connection is unexpectedly disconnected, the callback function triggers the "connection exception" event, recording the exception time and reason. This callback mechanism eliminates the need for the CPU to continuously poll the Socket status, saving system resources and ensuring real-time processing of communication events and data, avoiding data loss due to delays.

[0073] The system sends a preset "test service data frame" to the secondary device's network port through the configured Socket interface. If, within a preset time, the callback function detects a "data reception" event and the data in the parsed buffer is a "valid response to the test data frame," then the system determines that "the network port data transmission function is normal." If no response is received, the received response data is invalid, or the callback function triggers a "connection error" event, then the system determines that "the network port data transmission function is abnormal." The system merges the Socket test results with the connectivity results and outputs them together to the display interface.

[0074] In this embodiment, the Socket communication test adapts to the network port communication needs of different secondary devices by configuring the Socket as a TCP client or UDP mode and flexibly setting the local port, target IP address and port number. Then, the Socket callback function handles communication events or data in a timely manner to ensure the smooth progress of data transmission testing. It can comprehensively detect the data transmission function of the network port and make up for the limitation of detecting the network port connectivity by only using PING requests, thereby improving the comprehensiveness and reliability of network port detection.

[0075] In one specific embodiment, the core code logic for network interface communication is as follows:

[0076] First, the ATK-MO395Q module is initialized. If initialization fails, a 200ms delay is applied followed by an error return. Successful initialization involves configuring network parameters using the `configure_network_parameters()` function. User input is used to read the target IP address and pass it to the `Send_Ping_Request()` function. If the ping fails, the interface displays "Ping error" to initialize the PING function. If the ping succeeds, the `Ping_Callback()` function updates the display. To send data, the socket communication parameters are configured using `Configure_Socket_As_TCP_Client()`, and the local port, target IP address, and port number are set using `Set_Socket_Destination()`. Finally, `Set_Socket_Callback()` sets the socket's callback function. This callback function handles socket events or data, initiating socket communication and data transmission.

[0077] In one possible implementation, before obtaining the user input of a detection request instruction for secondary device interface communication detection, the method further includes: The system performs hardware layer initialization and application layer initialization; hardware layer initialization includes clock initialization and peripheral initialization; peripheral initialization includes: peripheral device initialization, motion controller initialization and network module initialization.

[0078] In one embodiment, the hardware layer initialization and application layer initialization code are as follows:

[0079] In this embodiment, the method first initializes the system hardware layer and application layer before acquiring the user's detection request instruction. The clock initialization and peripheral initialization at the hardware layer ensure the stable operation of the system hardware components, while the application layer initialization ensures the normal activation of relevant functional modules. This provides a stable operating foundation for subsequent parsing of detection requests, initiation of the interface detection process, and data reception and parsing, effectively avoiding detection process interruptions or abnormal detection results due to insufficient initialization, thus improving the stability and reliability of the entire detection method.

[0080] In one possible implementation, when receiving data during the detection process, the data is received through an interrupt handler, and the data protocol header is parsed to determine the type of communication data. When receiving data during the detection process, Process_Data_Reception() is used for corresponding interrupt handling, Parse_Protocol() is used for data parsing, and Process_Data_Reception() is used to determine the data type of the communication.

[0081] In this embodiment, the detection process uses an interrupt handler to receive data, which can respond to data reception events in a timely manner to avoid data loss. At the same time, interrupt handling is performed through Process_Data_Reception(), data parsing is performed with Parse_Protocol(), and the data type of communication is determined by Process_Data_Reception(). This forms a standardized and efficient data reception and parsing process, which improves the efficiency and accuracy of data processing and ensures that the detection process can proceed smoothly and quickly obtain detection results.

[0082] The above embodiments have discussed the system initialization, network port detection process, and serial port detection process, respectively. The following describes the overall process with pseudocode.

[0083] The main function is used to implement the overall flow logic. The pseudocode of the main function is as follows:

[0084] First, the system performs initialization, including hardware and application layer initialization. After initialization, it enters the main function. This is encapsulated in a C language file. User input is parsed using `Parse_User_Input()`, and data reception is handled using `Process_Data_Reception()` for appropriate interrupt processing. The pseudocode is as follows:

[0085] The function Process_Data_Reception() matches the type of communication data to be processed by the program, and then parses it using Parse_Protocol(). The pseudocode is as follows:

[0086] Data is read using Parse_Header(), and the parsed data is used to determine whether communication was successful. The interface is then updated and the display is refreshed to clearly present the results to the maintenance personnel.

[0087] In one possible implementation, after outputting the detection results to the display interface, the following is also included: A detection log is generated based on the detection results and stored in non-volatile memory; Among them, a detection log is generated based on the detection time, detection type, and detection result.

[0088] In this embodiment, after the test results are output to the display interface, a test log is generated based on the test time, test type, and test results and stored in a non-volatile memory. The non-volatile memory ensures that the log data will not be lost even if the test device is powered off, making it convenient for maintenance personnel to query historical test records and trace the test status of different times and different types of interfaces. This helps to analyze the fault occurrence pattern or reproduce the fault scenario. Maintenance personnel do not need to manually record test information, reducing the tediousness and error probability of manual recording, and improving the traceability of secondary equipment communication maintenance and the convenience of subsequent maintenance.

[0089] Figure 5 This is a flowchart illustrating the implementation of a secondary device interface communication detection method according to another embodiment of the present invention. Figure 5 As shown.

[0090] The system is initialized (e.g., LEDs, keys, Flash, I / O). After initialization, for serial port testing, text is input, data is sent, and the received data is parsed and displayed on the screen. For network port testing, the PING command is used, the IP address is entered, and the result is displayed on the screen. Finally, the results are automatically saved for later review by maintenance personnel.

[0091] 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 the present invention.

[0092] based on Figure 2 and Figure 3 As shown in the figure, practical experience has proven that the detection algorithm tool provided in this embodiment of the invention can intuitively and accurately locate the status of the device's RS-485 serial port or RJ-45 network port, reducing the communication interruption of the protection and control device from 65 minutes to 14 minutes, improving work efficiency by 3.643 times compared to the past, and achieving a test accuracy of 100%. At the same time, it avoids the drawbacks of relying on laptops with dedicated detection programs installed during the troubleshooting process, and reduces the risk of unauthorized external network security alarms.

[0093] This invention also provides a secondary device interface communication detection device, comprising: a processing unit based on STM32F103, an interface module for connecting to an RS-485 serial port, a network module for connecting to an RJ-45 network port, a human-machine interface, and a memory for storing computer programs and detection results. When the computer program is executed, it is used to implement the methods described in the above embodiments.

[0094] For the sake of simplicity and clarity, only the above-described functional modules / units are used as examples. In practical applications, the functions described above can be assigned to different functional modules / units as needed. These modules / units can be implemented in hardware, software, or a combination of both.

[0095] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not detailed or described in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Unless otherwise specified or in conflict with logic, the terminology and / or descriptions between different embodiments are consistent and can be referenced interchangeably. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0096] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention 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 the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for detecting communication at a secondary device interface, characterized in that, include: The system acquires a user-inputted detection request command for secondary device interface communication detection, and parses the detection request command to determine the type of the interface to be detected; wherein, the interface type includes serial port and network port. When the type of the interface to be tested is a serial port, a text input box for the test data is displayed, and the serial port testing process is started; when the type of the interface to be tested is a network port, a text input box for the target IP address is displayed, and the network port testing process is started. The detection result of the interface to be tested is determined based on the parsing result of the data received in the detection process, and the detection result is output to the display interface.

2. The secondary device interface communication detection method according to claim 1, characterized in that, The serial port detection process includes: Initialize and configure the baud rate and data frame format of the Universal Synchronous Asynchronous Receiver / Transmitter (USART); Obtain the test data input by the user, send the formatted test data to the interface to be tested, and append an end flag to the end of the data frame; Response data is received via interrupt and stored in a buffer; The start flag and instruction type in the response data are parsed to determine the serial communication status.

3. The secondary device interface communication detection method according to claim 2, characterized in that, The step of sending formatted test data to the interface to be tested and appending an end flag to the end of the data frame includes: The test data is formatted into a data frame conforming to the serial communication protocol and written into the transmission buffer; After the complete data frame is sent, append at least three 0xFF bytes as an end marker.

4. The secondary device interface communication detection method according to claim 2, characterized in that, The process of parsing the start flag and instruction type in the response data to determine the serial communication status includes: The start flag in the data buffer is searched. If the start flag is the first preset value, the page turning instruction is executed. If the start flag is the second preset value, the RS-485 communication data is parsed. The display interface is updated based on the parsing results to indicate whether the communication was successful or failed.

5. The secondary equipment interface communication detection method according to claim 1, characterized in that, The network port detection process includes: Initialize the network communication module; Obtain the IP address entered by the user, send a PING request to the IP address entered by the user, determine the network interface connectivity based on the response result, and display the connectivity result on the interface.

6. The secondary device interface communication detection method according to claim 5, characterized in that, The response result indicates that the network port connectivity is normal, and it also includes a Socket communication test; The Socket communication test includes: Configure the socket as a TCP client or UDP mode, and set the local port, target IP address, and port number; Data transmission is tested by handling communication events or data through Socket callback functions.

7. The secondary equipment interface communication detection method according to claim 1, characterized in that, Before obtaining the user-inputted detection request instruction for secondary device interface communication detection, the method further includes: The system performs hardware layer initialization and application layer initialization; wherein, the hardware layer initialization includes clock initialization and peripheral initialization; the peripheral initialization includes: peripheral device initialization, motion controller initialization and network module initialization.

8. The secondary equipment interface communication detection method according to claim 1, characterized in that, When receiving data during the detection process, the data is received through an interrupt handler, and the data protocol header is parsed to determine the type of communication data.

9. The secondary device interface communication detection method according to claim 1, characterized in that, After outputting the detection results to the display interface, the method further includes: A detection log is generated based on the detection results and stored in a non-volatile memory; Among them, a detection log is generated based on the detection time, detection type, and detection result.

10. A secondary device interface communication detection device, characterized in that, include: The system includes a processing unit based on the STM32F103, an interface module for connecting to the RS-485 serial port, a network module for connecting to the RJ-45 network port, a human-machine interface, and a memory for storing computer programs and test results. The computer program, when executed, is used to implement the method as described in any one of claims 1 to 9.

Images