A bus communication inspection method and related equipment based on master-slave communication mode

Abstract

This invention discloses a bus communication inspection method and related equipment based on a master-slave communication mode, relating to the field of communication. The method includes: determining a starting slave from multiple slave devices; generating an inspection command frame based on the address of the starting slave, where the receiving address is the address of the starting slave and the sending address is the address of the master; after sending the inspection command frame to the bus, monitoring the data transmitted on the bus to obtain starting slave response data, where the target address of the slave in the starting slave response data is the address of the next slave to be inspected; after receiving the starting slave response data, continuously monitoring the data transmitted on the bus to obtain current slave response data, where the target address of the slave in the current slave response data is the address of the next target slave to be inspected after the current slave. This invention enables more efficient and real-time bus communication inspection, alleviating the problem of slow master inspection response.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a bus communication inspection method and related equipment based on master-slave communication mode. Background Technology

[0002] In the field of bus communication, many communication systems, limited by bus hardware characteristics, typically employ a master-slave half-duplex communication mode. In this mode, usually only one device on the bus acts as the master, and the rest act as slaves. Each slave is assigned a unique communication address. To avoid data collisions, at any given time, only one device on the bus is allowed to be in the transmitting state, while the others are in the receiving state. Generally, if the master is in the transmitting state, the slaves are in the receiving state; if one slave is in the transmitting state, then the remaining slaves and the master are in the receiving state.

[0003] The master unit, based on system logic requirements and following a specified communication protocol, polls and checks each slave unit sequentially. Specifically, the master sends a communication command to the target slave unit, then switches to receive mode, waiting for feedback from the selected slave. All slave units on the bus receive information from the master, but only when the address information sent by the master matches its own address is the slave unit identified as being inspected. The inspected slave unit then judges the command sent by the master, switches to transmit mode, sends relevant information or data to the bus, and then switches back to receive mode. After receiving and processing the data from the current slave unit, the master continues to poll other slave units in the same manner. The characteristic of this communication mode is "respond only when asked, do not respond otherwise."

[0004] However, when the number of slave devices connected to the bus is large, the time required for the master to complete a round of polling all slave devices increases significantly. This results in the master being unable to obtain the status or data information of the slave devices in a timely manner, making the master appear "slow to react" during inspections and seriously affecting the real-time performance of the system. Summary of the Invention

[0005] To address the aforementioned technical problems and deficiencies, the purpose of this invention is to provide a bus communication inspection method and related equipment based on a master-slave communication mode, which can provide more efficient and real-time bus communication inspection and alleviate the problem of slow response of the master inspection.

[0006] To achieve the above objectives, in a first aspect, the present invention provides a bus communication inspection method based on a master-slave communication mode, applied to a master in a bus communication system. The bus communication system also includes a bus and multiple slaves, with both the master and slaves connected to the bus. The method includes: determining a starting slave from among the multiple slaves; generating an inspection command frame based on the address of the starting slave, the inspection command frame including a receiving address, a sending address, and a command code, wherein the receiving address in the inspection command frame is the address of the starting slave, and the sending address is the address of the master; after sending the inspection command frame to the bus, monitoring the data transmitted on the bus to obtain starting slave response data from the starting slave, wherein the receiving address of the starting slave response data is the address of the master, the sending address is the address of the starting slave, and the slave target address is the address of the next slave to be inspected; after receiving the starting slave response data, continuously monitoring the data transmitted on the bus to obtain current slave response data from the current slave, wherein the receiving address of the current slave response data is the address of the master, the sending address is the address of the current slave, and the slave target address is the address of the next target slave to be inspected after the current slave.

[0007] The method of this invention innovatively designs the inspection command frame and response data structure, pre-carrying the address of the next slave to be inspected in the response data of each slave, so that the master can know the inspection sequence in advance. The slave to be inspected receives the response data sent by the previous slave and automatically triggers the chain response, thereby significantly reducing the polling waiting time and avoiding the system response delay problem caused by the one-by-one calling in the traditional master-slave communication mode. It realizes a more efficient and real-time bus communication inspection mechanism, effectively improving the communication performance and communication timeliness of multi-slave system. Especially in complex communication scenarios with a large number of slaves, it can significantly shorten the inspection cycle and improve the real-time response capability of the system.

[0008] Secondly, the present invention also provides a bus communication inspection method based on a master-slave communication mode, applied to a slave device in a bus communication system. The bus communication system further includes a master and a bus, and the slave device and the master are both connected to the bus. The method includes: when designated as the current inspection slave device, receiving an inspection command frame from the master or response data from the previous slave device, wherein the inspection command frame or the response data from the previous slave device includes the address of the current inspection slave device; determining the address of the next slave device to be inspected according to a preset inspection order based on the inspection command frame or the response data from the previous slave device; generating new slave response data according to the address of the next slave device to be inspected, wherein the new slave response data includes the address of the current inspection slave device, the address of the master, and the address of the next slave device to be inspected as the target address of the slave device; and sending the new slave response data to the bus for reception by the master and the next slave device to be inspected.

[0009] The beneficial effects of the method provided in the second aspect of the present invention can be referred to the first aspect, and will not be repeated here.

[0010] Thirdly, embodiments of the present invention provide a monitoring device, the monitoring device comprising: one or more processors and a memory; the memory being coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the monitoring device to perform the method as described in the first aspect and any possible implementation thereof.

[0011] Fourthly, the present invention provides a computer-readable storage medium including instructions that, when executed on a monitoring device, cause the monitoring device to perform the method described in the first aspect and any possible implementation thereof.

[0012] Fifthly, the present invention provides a computer program product containing instructions that, when the computer program product is run on a monitoring device, cause the monitoring device to perform the method described in the first aspect and any possible implementation thereof.

[0013] Understandably, the electronic device provided in the third aspect, the storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect are all used to execute the method provided by this invention. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0014] Figure 1 This is an architecture diagram of a bus communication system according to an embodiment of the present invention;

[0015] Figure 2 This is a flowchart illustrating a bus communication inspection method based on a master-slave communication mode according to an embodiment of the present invention.

[0016] Figure 3 This is a schematic diagram of the communication logic between the host and slave devices based on a shared bus in an embodiment of the present invention;

[0017] Figure 4 This is a timing diagram of data interaction between the host and slave in an embodiment of the present invention;

[0018] Figure 5 This is a schematic diagram of host data storage in an embodiment of the present invention;

[0019] Figure 6 This is a bus data transmission and reception timing logic diagram in an embodiment of the present invention;

[0020] Figure 7 This is a schematic diagram of the communication process and state switching in an embodiment of the present invention;

[0021] Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0022] This invention provides a bus communication system, such as... Figure 1 As shown, it includes a master (e.g., address 0x00), a bus, and multiple slave devices (e.g., addresses including 0x01, 0x02...0x0n), with the master and slave devices all connected to the bus.

[0023] As the core control unit of the bus communication system, the host is equipped with a high-performance microprocessor or dedicated controller and integrates advanced communication interface circuits, data processing modules, and registers. In this embodiment, the host has the ability to parse specific fields in the data, quickly identify and extract the "slave target address" contained in the slave response, and optimize its subsequent listening and data processing flow accordingly. This enables uninterrupted chain-like inspection, reduces the waiting time of addressing each slave individually in the traditional mode, and improves data processing efficiency and system response speed.

[0024] As a controlled terminal device in a bus communication system, a slave device typically consists of an embedded microcontroller, a bus transceiver, and a data storage unit. Besides receiving commands from the bus, executing corresponding operations, and sending its own data, its internal firmware or dedicated hardware logic is designed to automatically or according to preset rules embed the "address of the next slave device to be inspected" as the "slave target address" into its response frame when generating response data. The slave device has the ability to store or dynamically generate this address and encapsulate it along with its own data, thereby providing "relay" information to the master and achieving automated and efficient continuous bus inspection.

[0025] This invention also provides a bus communication inspection method based on a master-slave communication mode, applied to the host of the aforementioned bus communication system. For example... Figure 2 As shown, the method includes the following steps:

[0026] Step 201: Determine the starting slave from among multiple slaves.

[0027] As the master controller of the entire system, the host first needs to determine the starting point of its inspection chain, namely the "starting slave," before executing the inspection task. This determination process is not random for the host, but is based on a preset strategy or the system's initialization configuration.

[0028] Specifically, the host may determine the starting slave in several ways: a common method is that the system's physical or logical address order is defined at the initial design stage. For example, the slave with the smallest address (such as slave ID 0x01) is designated as the starting slave. In this case, the host's internal firmware or software logic will directly load and use this preset starting address.

[0029] Another more dynamic approach is that, during system power-on or initialization, the host may perform a "slave discovery" or "address allocation" process. This involves broadcasting a query command, to which all online slaves reply with their addresses. The host collects these addresses and builds a slave list. Subsequently, the host can select the first slave from this list as the starting slave based on some sorting rule (such as address size, connection order, or specific function priority).

[0030] Furthermore, in some complex application scenarios, the starting slave can even be manually configured by the operator through the human-machine interface, or dynamically selected by the intelligent algorithm inside the host according to the current system operating status and task requirements. For example, the nearest, highest priority, or next slave when the last inspection was interrupted can be selected as the starting point.

[0031] Regardless of the method used to determine this, the core principle is that the host must logically identify the first slave device it needs to communicate with and its unique bus address. This is the basis for generating subsequent inspection command frames and the crucial first step in initiating the entire chain inspection process. The host is responsible for maintaining the address information of this initial slave device so that it can be invoked at the appropriate time.

[0032] Step 202: Generate an inspection command frame based on the address of the starting slave device.

[0033] The inspection command frame includes a receiving address, a sending address, and a command code. In the inspection command frame, the receiving address is the address of the starting slave device, and the sending address is the address of the master device.

[0034] The generation of inspection command frames strictly follows a predefined communication protocol format to ensure that they can be correctly parsed by all devices on the bus and ultimately received and processed by the target slave device.

[0035] Specifically, the host's internal communication protocol stack fills in the key fields of the command frame according to the following specifications: First is the "receive address" field, where the host writes the unique address of the previously determined starting slave device. This address is the "address" that indicates the final recipient of the command frame when it is transmitted on the bus; only the slave device with the matching address will receive and process the frame.

[0036] Secondly, there is the "sender address" field, where the host fills in its own unique address (i.e., the host's bus address). This allows the initial slave receiving the command frame to clearly know the source of the command, which is crucial for the slave to subsequently generate correct response data, because the slave needs to set the receive address of the response to this sender address to ensure that the response can be accurately sent back to the host.

[0037] Finally, there is the "Command Code" field, where the host writes a specific command code indicating the purpose of this communication: "inspection" or "data request." This command code triggers the initial slave to execute its internal inspection response logic, including collecting its own status data, preparing a response, and, as designed in this embodiment, including the address of the next slave to be inspected in the response.

[0038] The entire process of generating the inspection command frame involves data encapsulation, checksum calculation (such as CRC check), and the addition of frame headers and trailers to ensure the integrity and reliability of data transmission. Once the inspection command frame is completely and correctly constructed, it can be sent to the physical bus through the host's bus interface, thereby officially starting the entire chain bus inspection process.

[0039] Step 203: After sending the inspection command frame to the bus, listen to the data transmitted on the bus and obtain the start slave response data from the start slave.

[0040] In this context, the receiving address of the initial slave response data is the address of the master, the sending address is the address of the initial slave, and the slave target address is the address of the next slave to be inspected.

[0041] After the master successfully constructs the inspection command frame for the initial slave, its next crucial action is to send it onto the physical bus and then enter a listening state. The transmission process involves the master's internal bus interface controller converting the digitized command frame data into electrical signals suitable for bus transmission, and then driving these signals onto the shared bus medium via the bus driver. Once the command frame is successfully sent, the master does not immediately send the next command; instead, it puts its bus interface into receive mode and begins "listening" to all data streams on the bus.

[0042] This monitoring is not a passive waiting process, but an active and efficient one: the host's internal protocol stack parses the header information of each incoming frame in real time, especially the "receive address" field. When the host recognizes that the "receive address" of an incoming frame matches its own address, it knows that the frame is intended for it and thus receives it completely into its internal buffer.

[0043] In this embodiment, the host expects to receive "starting slave response data" from the starting slave at this stage. When an incoming frame is identified as a valid response frame sent to the host itself, the host will further verify whether its "sending address" matches the address of the "starting slave" that previously sent the command, thereby confirming the correctness of the source of the response.

[0044] Once confirmed, the host will further analyze the valid data content of the response data. In this embodiment, the host not only obtains the status or data information of the initial slave device, but more importantly, it accurately extracts the "slave target address" field from the response data. This field contains the address information of the next slave device to be inspected. The host temporarily stores this extracted "slave target address" as part of its internal state, preparing for the next "chain-like" inspection.

[0045] Throughout the process, the host needs to obtain crucial "relay" information from the initial slave's response in a timely and accurate manner, thus laying the foundation for subsequent seamless inspections. If no response is received after the preset waiting time, the host will typically trigger a timeout mechanism and may attempt to resend the command or report a communication failure.

[0046] On the slave side, when the starting slave receives a patrol command frame from the master, it first parses the command frame, confirms whether the receiving address is its own address, and identifies the command code to determine the operation to be performed. Subsequently, the starting slave executes the corresponding task, such as reading its own sensor data or status information. A key action of the starting slave in preparing response data is to determine the address of the next slave to be patrolled based on a preset patrol sequence or internal logic, and embed this address as the slave target address into its own response frame. Finally, the starting slave sends a complete response frame containing its own data, the master address as the receiving address, its own address as the sending address, and the crucial "slave target address" to the bus, enabling the master and the next slave to be patrolled to receive it.

[0047] Step 204: After receiving the initial slave response data, continuously monitor the data transmitted on the bus to obtain the current slave response data from the current slave.

[0048] In this context, the receiving address of the current slave response data is the address of the master, the sending address is the address of the current slave, and the slave target address is the address of the next target slave to be inspected after the current slave.

[0049] After the host successfully receives and parses the response data from the starting slave and extracts the slave target address (i.e., the address of the next slave to be inspected in the chain), it does not immediately construct and send a new command frame to actively query this "next slave" as in traditional polling. Instead, the ingenuity of this embodiment lies in the fact that the host will continue to maintain its "listening" state established in step 203, that is, "continuously listening to the data transmitted on the bus". This means that the host is no longer an active initiator, but has transformed into an efficient receiver and chain manager.

[0050] First, during continuous listening, the host's communication module constantly scans the bus, waiting for the next expected data packet. This "next expected data packet" is the response from the slave (i.e., the "current slave") pointed to by the "slave target address" obtained from the initial slave response in the previous step. When the host receives a data frame and confirms that its receiving address is itself, and that its sending address matches the slave target address extracted from the initial slave response, the host recognizes that this is the current slave's response data. This matching mechanism is key to implementing chain-relay inspection: when a slave sends its response, it already includes the address of the next slave to be inspected and expects this next slave to respond automatically after receiving the response. By listening to and matching this address, the host achieves the perception and confirmation of the "relay" behavior between slaves.

[0051] Once the current slave response data is successfully received and verified, the master will perform the parsing operation again. It will extract the new slave target address from this "current slave response data". This new address points to the address of the next target slave to be inspected after the current slave, that is, the next slave in the chain. The master updates this new address into its internal state as the source of the next expected slave response.

[0052] This process forms an efficient loop: the master sends an initial command, and then passively and continuously receives responses from different slaves by continuously listening to the "slave target address" carried in the slave responses, without having to actively send a query command each time. This mechanism greatly reduces the time overhead of the master between two slave communications, significantly improving the efficiency of bus inspection and the real-time performance of communication.

[0053] The host will continue to listen and update the address until it receives a preset end flag (e.g., the "slave target address" in a slave's response indicates the end of the chain, or all known slaves have been inspected), or an abnormal situation such as a timeout occurs.

[0054] On the other hand, on the slave side, the actions and data processing of the current slave differ from those of the starting slave in step 203. The current slave does not directly respond to the master's commands. Instead, it listens to the data stream on the bus and, upon recognizing that the "slave target address" in the response data sent by the previous slave is its own address, triggers its own response mechanism. This means that the current slave receives and parses the response frames from other slaves and extracts the address information indicating that it has been selected as the next inspection target. Once confirmed, the current slave executes its own tasks (such as data acquisition and fault self-checking), then generates a response frame containing its own data, the master address as the receiving address, its own address as the sending address, and the address of the next target slave to be inspected, and sends it to the bus, thus completing the "relay" process of chain inspection.

[0055] This embodiment adopts the above method and steps, and significantly optimizes the polling mechanism in the traditional master-slave communication mode by innovatively including the "slave target address", that is, the address of the next slave to be inspected, in the slave response data.

[0056] In related technologies, when there are many slave devices on the bus, the master needs to call out each slave device one by one. After each call, the master needs to wait for the slave device to respond and calculate or determine the next slave device to be polled. This sequential and independent calling method leads to a significant extension of the bus polling cycle, which makes it difficult for the master to obtain slave device status or data information in a timely manner, thus exhibiting "slow response" and affecting the communication effect of the system.

[0057] This embodiment addresses this pain point: once the host sends a command to the starting slave and receives its response, the response data clearly indicates the address of the next slave to be inspected in the chain. This means that the host does not need to spend extra time querying or calculating the address after each slave response, but can continuously listen for and receive responses from the next slave based on the "relay" information provided by the slave itself, without requiring the host to poll the slaves one by one.

[0058] This "chain" or "relay" inspection method greatly reduces the decision-making and waiting time of the master between two slave communications, thereby significantly shortening the entire bus inspection cycle, improving the real-time data acquisition and system response speed, effectively solving the problem of slow system response, and significantly improving the performance and communication efficiency of the multi-slave bus communication system.

[0059] The following is combined with Figure 3 The communication logic of the bus in this embodiment is introduced. It is assumed that under normal working conditions, one master and four slaves communicate based on a shared bus. Figure 3 In the diagram, a solid downward arrow represents the sender of the data, while a hollow upward arrow represents the receiver. Figure 3 The dashed lines in the diagram are key to understanding this communication mechanism. They represent the causal relationship in the communication; that is, the data frame sent in the previous communication step directly leads to the automatic response of the corresponding slave device in the next step. Furthermore, an important communication rule is that on the same bus, only one device is in the transmitting state at any given time, while all other devices are in the receiving state, ensuring the orderliness of communication and avoiding data collisions.

[0060] The entire communication process is divided into six steps. Step 1 is initiated by the master, which sends data to all slave devices on the bus. Upon receiving the master's command, in Step 2, slave device 1, as the target receiving slave, automatically responds and sends its data. At this point, the master and other slave devices are in receive mode. This chain-reply mechanism continues: in Step 3, slave device 2 responds and sends data; in Step 4, slave device 3 responds and sends data; and in Step 5, slave device 4 responds and sends data. In each step, only one designated device sends data, while the others are responsible for receiving. Finally, in Step 6, the master sends data again, marking the end of a complete polling cycle. This eliminates the need for the master to frequently send polling commands, improving system communication efficiency.

[0061] The implementation process of the method in this embodiment can also be referred to Figure 4 As shown, the details are as follows:

[0062] 1) Determining the starting slave: The master (0x00) first selects one of the multiple slaves connected to the bus (e.g., 0x01, 0x02, 0x03, 0x04) as the starting slave for inspection. The diagram shows the starting slave as 0x01. This selection process may be based on a preset configuration, bus scan, or a specific protocol.

[0063] 2) Generate and send inspection command frame: Based on the determined starting slave address (0x01), the host generates an inspection command frame. This command frame is the first inspection instruction issued by the host, and it contains:

[0064] Receive address: The address of the starting slave device 0x01.

[0065] Source address: Address of host 0x00.

[0066] Command code: Indicates that this is an inspection command.

[0067] The host then sends this inspection command frame to the bus.

[0068] 3) Listening for and receiving the start slave response data: After sending the inspection command frame, the master begins listening to the bus. When the start slave 0x01 receives the inspection command for its address, it generates and sends "start slave response data". This response data contains the following key information:

[0069] Receive address: The address of host 0x00 (indicating that the data frame is sent to the host).

[0070] Sending address: The address of the starting slave device 0x01 (indicating that the data frame was sent by the slave device at address 0x01).

[0071] Slave Target Address: This is the key innovation of this solution. The response data will explicitly indicate the address of the next slave device to be inspected (e.g., 0x02). Once the master device successfully receives this response data, it knows which slave device is next to be inspected.

[0072] 4) Continuously listen for and receive subsequent slave response data: After receiving the response data from the initial slave 0x01, the master will continue to listen to the bus according to the "slave target address" (0x02) indicated therein. When slave 0x02 receives an implicit or explicit (if the master generates a new command based on the response information) inspection command for it (or when it is its turn to respond), it will send "slave (0x02) response data". This response data also includes:

[0073] Receive address: The address of host 0x00.

[0074] Sending address: The address of the current slave device 0x02.

[0075] Slave Target Address: Indicates the address of the next slave device to be inspected (e.g., 0x03).

[0076] This process continues, with the host automatically and in a chain-like manner guiding the slave to inspect the next slave on the bus through the "slave target address" carried in each slave response data received, until all slaves have been inspected or the preset inspection termination condition is met.

[0077] Through the above process, this embodiment realizes slave-driven chain inspection, which significantly improves the efficiency and flexibility of bus communication inspection, specifically in the following ways:

[0078] Simplified host inspection logic: In traditional inspections, the host needs to maintain a complete list of slave addresses and send commands one by one in sequence. In this solution, the host only needs to know the first starting slave, and the subsequent inspection order is "informed" to the host by the slave in its response data, which greatly reduces the burden on the host in managing slave addresses and inspection order.

[0079] Enhanced system scalability: When a slave device is added or removed from the bus, the master device does not need to modify its internal slave device list or inspection algorithm. As long as the new slave device can provide the address of the next slave device in its response according to the protocol, the entire inspection chain can automatically adapt to the change. This gives the system better plug-and-play characteristics and ease of maintenance when the number of slave devices changes.

[0080] Improve inspection efficiency: Chain inspection avoids the process of the host needing to recalculate or find the next slave address and inspect it before each inspection. The slave directly provides the next address, reducing the host's processing time and shortening the entire inspection cycle.

[0081] Reduce bus bandwidth usage (potential): If the master no longer needs to send a separate addressing command frame for each slave, but instead guides the process through slave responses, the number of command frames on the bus can theoretically be reduced, thereby optimizing bandwidth utilization.

[0082] In summary, this embodiment cleverly utilizes the "slave target address" field in the slave response data to delegate the sequence control of the inspection to the slave, making the bus inspection process more intelligent, automated, and adaptive. This has significant application value for building an efficient and scalable bus communication system.

[0083] In some implementations of this embodiment, both the inspection command frame and the slave response data follow a predefined format.

[0084] The inspection command frame may specifically include: frame header M, receiving address (the address of the first slave device, such as 0x01), sending address (the address of the master device itself, such as 0x00), command code (indicating the data type of the slave device's response), spare information, checksum, and frame tail M.

[0085] The slave response data can specifically include: frame header S, receiving address (i.e., host address), sending address (i.e., its own address), slave target address, command code, data information, checksum, and frame trailer S.

[0086] In the inspection command frame, M represents the command frame issued by the master. In the slave response data frame, S represents the response data issued by the slave. The header / tail of the inspection command frame and the slave response data can be different (i.e., M and S represent different information), which allows the master / slave to quickly understand the source of the data.

[0087] refer to Figure 5This illustrates the data processing and storage structure when the host communicates with the slave device. The upper part shows the frame format of the "serial port receive buffer," which represents the standardized structure of data packets received by the host through the serial port. A complete communication frame contains multiple fields, such as a frame header, receive address, send address, destination address, command code, a variable-length data field (data 1 to data n), and high and low checksums and a frame trailer for data integrity verification. This structure ensures that the host can correctly parse any communication data from the bus. Figure 5 The lower half illustrates the "slave data storage area within the host," indicating that the host maintains a highly organized database for storing data related to different slave devices. This data is categorized and indexed based on "command codes" and "slave addresses."

[0088] For example, for command code 1, the host can store data blocks that are retrieved from slaves 0x01, 0x02, 0x03, 0x04, etc., or that need to be sent to them. Each data block also contains multiple data items. This means that the host can precisely access the corresponding data based on the specific command type and the target slave. Figure 4 It clearly demonstrates how the host exchanges data through standardized communication frames and effectively organizes and manages data with multiple slaves, providing a foundation for complex bus communication and device management.

[0089] The host's data processing and interaction demonstrate a combination of high intelligence and passive reception, acting as both a bus inspection initiator and manager. First, at the start of the inspection, the host constructs a standard inspection command frame according to a predefined format based on a preset inspection strategy (e.g., starting from the first slave address 0x01 on the bus). Once constructed, the host sends this command frame to the physical bus via its bus interface. After transmission, the host immediately switches its bus interface to receive mode, entering an efficient listening mode to await response data from the target slave.

[0090] During the listening process, the host continuously monitors the data flow on the bus. When data appears on the bus, the host first identifies the frame header (S) and frame trailer (S) to determine that it is a valid data frame sent by a slave device. Next, the host performs integrity checks on the received data, including checksum verification. If the check passes, the host further checks whether the receive address of the frame is its own address (0x00) to confirm that the response is addressed to itself. Simultaneously, the host records the sender address of the response frame, i.e., the address of the currently responding slave device. Most importantly, the host extracts the slave target address field from the slave response frame. This field indicates the slave address of the next response in the chain of checks. The host stores this slave target address as part of its internal state, but it does not immediately send a new command based on this address. Instead, the host maintains its receive state and continues listening to the bus.

[0091] In subsequent inspections, the master no longer actively sends inspection commands, but relies entirely on chained responses between slaves via the slave target address field. The master continuously listens to the bus, and when it receives a new slave response frame, it repeats the checksum and address matching process described above. If the receiving address is the master itself and the checksum is correct, the master parses the frame to obtain the data information and the new slave target address. The master updates this new slave target address as the source of the next expected response. This loop continues until the master receives a specific slave target address in a slave response indicating the end of the inspection (e.g., an invalid address or a specific end marker), or fails to receive any response within a preset timeout period. If a timeout occurs, the master can handle errors according to a preset strategy, such as resending the inspection command and attempting to skip currently unresponsive slaves, pointing the receiving address to the next slave address to ensure the continuity of the inspection chain. Through this mechanism, the master significantly reduces the frequency of actively sending commands, thereby improving bus utilization and overall inspection efficiency.

[0092] The data processing and interaction processes of slave devices during bus inspection demonstrate their high degree of autonomy and relay capability. Under normal operating conditions, all slave devices on the bus are in receive mode, continuously listening to the data stream. When the master sends an inspection command frame to the bus, all slave devices receive the command and store it in their respective receive buffers. Subsequently, each slave device performs a strict format and content check on the received command frame. The slave first checks if the frame header M and frame trailer M are correct to confirm that it is a complete master command. Next, a checksum verification is performed to ensure the integrity of data transmission. If the checksum passes, the slave checks the receive address field in the command frame. Only when the receive address completely matches the slave's own unique address is the slave identified as the target slave for this command and prepared to respond. Other slaves with mismatched receive addresses ignore the command and continue listening.

[0093] After confirming that it is the receiver, the selected target slave device determines the specific task to be performed based on the command code in the command frame, such as reading internal sensor data and status register information, and prepares the corresponding data information. A core action of the slave device in preparing the response data frame is determining its target address. According to the chain-like inspection mechanism of this invention, under normal circumstances, the slave device increments its own address by 1 to obtain the target address (e.g., if its own address is 0x01, then the target address is 0x02). This target address is crucial information for enabling relay between slave devices. The slave device encapsulates this information (frame header S, receiving address as host address 0x00, sending address as its own address, calculated target address, command code, prepared data information, checksum, and frame tail S) into a complete slave response data frame. After a short delay, the slave device switches its bus interface to transmit mode and sends the constructed response frame onto the bus. After transmission, the slave device immediately switches back to receive mode and continues listening to the bus.

[0094] In subsequent chain checks, the response logic of the slave (as the current slave) differs slightly. It no longer waits for active commands from the master but continuously listens to the bus. When it receives a response data frame from the previous slave (e.g., the slave with address 0x01), it verifies the frame header (S), frame trailer (S), and checksum, just as it would a master command. If the verification passes, it checks the slave target address field in the response frame. If this slave target address matches the current slave's own address, then the current slave knows it is the next responder in the chain check. It immediately executes its own data acquisition task and constructs a response frame containing its own data and the next slave target address as described above, sending it to the bus after a short delay.

[0095] This mechanism enables slave devices to automatically trigger responses based on the data flow on the bus, achieving efficient self-driven chain inspection and greatly reducing the burden on the master device. If all slave devices on the bus fail to meet the transmission conditions (e.g., the target slave device is offline or damaged), no slave device will respond, and the master device will handle the issue through a timeout mechanism.

[0096] In some embodiments, during step 204 of continuously monitoring the data transmitted on the bus, the method further includes:

[0097] S2041 If no response data is received from the target slave within the preset time period, the next slave to be inspected after the target slave will be identified as the new target slave.

[0098] The core of this step lies in introducing a timeout detection mechanism and a strategy to skip faulty slave devices. In a normal chain-link inspection process, after sending the initial inspection command, the master enters a passive listening state, expecting subsequent responses to be driven by the slave target address field between slave devices. However, if a slave device fails (e.g., device offline, internal program stuck, communication module damaged, etc.), it will be unable to receive the response frame sent by the previous slave device, or even if it does receive it, it will be unable to process it correctly and send its own response. In this case, the chain-link inspection will be interrupted, and no new slave response data will appear on the bus for a long time.

[0099] To prevent prolonged system downtime, the host needs to be able to detect such interruptions. This embodiment achieves this by setting a preset duration (i.e., timeout). When the host receives a response from the previous slave, it starts an internal timer. If, by the timer expires, the host has not received a response from the slave pointed to by the target address, the host determines that the target slave has failed or is unresponsive. At this point, to resume the inspection chain, the host no longer waits for the failed slave but logically skips it based on a known list of slave addresses or a preset inspection order, identifying the next valid slave after the failed slave as the new target slave. This process ensures the continuity of the inspection and prevents a single slave failure from paralyzing the entire system.

[0100] Assume the slave addresses on the bus are sequentially 0x01, 0x02, 0x03, and 0x04. The master initially sends a command to 0x01, which responds and indicates that the next target is 0x02. After receiving the response from 0x01, the master starts a timer, for example, 500 milliseconds, waiting for a response from 0x02. However, if slave 0x02 fails to respond for some reason (e.g., a power failure), the master will not receive any response from 0x02 during the 500-millisecond timeout. When the timer expires, the master determines that 0x02 failed to respond. At this point, based on its internal slave address list (0x01, 0x02, 0x03, 0x04), the master finds that the next slave after 0x02 is 0x03. Therefore, the master identifies 0x03 as the new target slave and prepares to actively intervene to resume the inspection.

[0101] S2042, Generate a new inspection command frame based on the address of the new target slave device.

[0102] Once the host identifies a new target slave in S2041, it needs to actively intervene and send a direct inspection command to this new target slave to reactivate the inspection chain. This step involves constructing this actively sent command frame. Similar to the initial inspection command frame, this new inspection command frame follows a standard command format, but its key difference lies in the receive address field. Here, the receive address is no longer the next address automatically passed by the slave in the chain inspection, but is explicitly set to the address of the new target slave identified in S2041. This means the host no longer relies on relaying between slaves, but directly names the new target slave for response. The command code, sending address (host itself), spare information, checksum, and frame header and trailer fields are generated in the same way as the initial command frame. In this way, the host can accurately send instructions to specific slaves after the skipped slaves, effectively bypassing fault points and restarting the inspection sequence.

[0103] Following the example of S2041, the host has already identified 0x03 as the new target slave. Now, the host needs to generate a command frame to wake up 0x03. It will construct a command frame, in which:

[0104] Frame header M: Fixed value;

[0105] Receive address: 0x03 (i.e., the address of the new target slave device);

[0106] Source address: 0x00 (host's own address);

[0107] Command code: The same code as the initial inspection command, indicating the data type that needs to be responded to at 0x03;

[0108] Backup information, checksum, frame tail M: This newly generated command frame will be specifically used to instruct slave 0x03 to respond, generated according to the standard.

[0109] S2043 sends a new inspection command frame to the bus so that the new target slave can receive and respond.

[0110] This is the final step in the host's proactive recovery of the inspection chain. After constructing the new inspection command frame in S2042, the host sends it to the physical bus via the bus interface. Since the receive address field of this command frame explicitly points to the new target slave, all slaves on the bus will perform address matching upon receiving the frame. Only the new target slave will recognize that the command is addressed to it, thus triggering its internal response logic. Once the new target slave receives and processes the command, it will generate a response frame containing its own data and the address of the next target slave (which could be its own address plus 1) according to the normal slave response process and send it to the bus. In this way, the inspection chain can be restarted from the new target slave, and subsequent slaves will continue to respond in a chain relay manner. After sending this new command frame, the host will switch back to the receive state, waiting for a response from the new target slave, thus restoring the normal passive listening mode. This step is the closed loop of the entire fault recovery mechanism, ensuring that even if some slaves fail, the system can still maintain normal inspection with normal devices.

[0111] Continuing with the S2042 example, the master has generated a command frame pointing to 0x03. Now, the master sends this command frame to the bus. Slave devices 0x01, 0x02, 0x03, and 0x04 will all receive this command frame. However, only slave device 0x03 will find that the "receive address" in the command frame is its own address (0x03). Slave device 0x03 then processes the command, reads its own data, and constructs a response frame, which includes:

[0112] Frame header S;

[0113] Receive address: 0x00 (host);

[0114] Source address: 0x03 (self);

[0115] Slave target address: 0x04 (the next slave after 0x03);

[0116] The slave device 0x03 sends this response frame to the bus, containing the command code, data information, checksum, and frame tail. Upon receiving the response from 0x03, the master device resumes the inspection chain from 0x03, continuing towards 0x04, thus successfully bypassing the fault at 0x02 and ensuring the continuity of the inspection.

[0117] In some embodiments, after step S2041, the method further includes:

[0118] S2044, determine whether the address of the new target slave exceeds the set maximum slave address;

[0119] Specifically, when the host detects that a slave device fails to respond and times out, it attempts to skip the failed slave and search for the "next slave device to be inspected" as the "new target slave device." However, if the currently unresponsive slave device is already the one with the largest address on the bus (or the last slave device in the preset inspection range), then the address of the "next slave device to be inspected" calculated by the host will exceed the maximum slave address range set by the system (for example, if the maximum slave address is 0x0F, the calculation result may be 0x10). When this happens, the host can clearly determine that the current round of inspection, starting from the initial slave device, has traversed all possible slave addresses. Even if a slave device fails to respond, it means that this round of inspection has tried all known slave devices and cannot continue searching. Therefore, the host marks this round of inspection as finished. This mechanism effectively avoids indefinite waiting or invalid address calculations caused by the failure of the last slave device after inspection, ensuring the integrity and logical closed loop of the inspection cycle.

[0120] For example, suppose the system sets the slave address range to 0x01 to 0x05, meaning the maximum slave address is 0x05. In a certain round of inspection, the master starts from 0x01 and inspects sequentially up to 0x04. Now it's slave 0x05's turn to respond, but slave 0x05 fails to respond for some reason, and the master does not receive its response within a preset time. According to the logic in S2041, the master will attempt to find the "next slave to be inspected" after 0x05. If the slave address list or inspection order maintained internally by the master indicates that 0x05 is the last slave, then the calculated "next" address (e.g., logically 0x06) will exceed the set maximum slave address 0x05. At this point, the master immediately determines that this round of inspection has reached its end, and all slaves (or at least up to 0x05) have been tried. Therefore, the master determines that the current round of inspection is over, no longer attempts to send a command to 0x06, and waits for the next inspection cycle to arrive.

[0121] S2045, if the address of the new target slave exceeds the set maximum slave address, then the current inspection cycle is determined to be over, and a new inspection command frame is generated based on the address of the starting slave when the next inspection cycle arrives.

[0122] This step describes how to smoothly transition from the end of one inspection cycle to the beginning of the next, thus achieving the periodic and automated operation of inspections.

[0123] Once the host determines that the current round of inspection has ended (whether all slaves have responded or the inspection terminated due to reaching the maximum address), it does not immediately begin a new round of inspection. Instead, the system enters a waiting state, awaiting a preset trigger condition for the "next round of inspection." This trigger condition can be a fixed time interval (e.g., inspecting every 5 minutes) or an external event. When this trigger condition is met, the host resets its internal inspection state, resetting the inspection start point to the address of the "starting slave" (usually the first slave on the bus, such as 0x01).

[0124] Then, the host will regenerate a standard inspection command frame based on the address of this "starting slave", with its "receive address" field pointing to this starting slave. Subsequently, the host will send this newly generated command frame to the bus, thereby initiating a new round of slave inspection process.

[0125] This mechanism ensures that the system can perform regular and comprehensive health checks and data collection on all slave devices on the bus. Even if a faulty slave device is encountered in the previous inspection, it can be retried in the new cycle, thus improving the robustness and maintainability of the system.

[0126] For example, continuing with the previous example, the host has determined that the current round of inspection ended after attempting slave 0x05. At this point, the host enters a waiting state. Assume the system is configured to perform a full inspection every 10 minutes. When the 10-minute interval arrives, the host will initiate a new round of inspection. It will construct a new inspection command frame based on the preset "starting slave" address (e.g., 0x01). The "receive address" of this command frame will be 0x01, the send address will be the host itself, and the command code and other information will be filled in according to the standard format. After construction, the host sends this command frame to the bus. After receiving this command, slave 0x01 will respond as before and instruct the next slave (0x02) to respond.

[0127] In this way, a new and complete inspection cycle starts again from 0x01. The system will try to traverse all slave devices again, including those that may have failed in the previous round, thereby achieving continuous monitoring of device status.

[0128] If the address of the new target slave does not exceed the set maximum slave address, the host will generate a new inspection command frame based on the address of the new target slave and send it to the bus so that the slave can receive and respond, thereby restoring the inspection chain.

[0129] In some implementations, the method of this embodiment may further include:

[0130] S301 verifies the current slave response data and obtains the data verification result.

[0131] This step aims to ensure that the data sent by the slave device has not been erroneous or tampered with during transmission. When the master (or, in a chain check, the previous slave) receives a response data frame from the "current slave," it does not immediately trust and process the information within. Instead, it first performs an integrity check on the entire data frame. This check is typically implemented using checksums (such as CRC cyclic redundancy check, XOR checksum, etc.).

[0132] At the data sending end, the slave device calculates a checksum based on the data content it intends to send and appends it to the end of the data frame. At the data receiving end, the master (or the next slave device) uses the same algorithm to recalculate a checksum based on the received data. The receiving end then compares its calculated checksum with the checksum extracted from the data frame. If they match perfectly, it indicates that no errors occurred during data transmission, and the data verification result is "correct"; otherwise, if they do not match, it indicates that the data may be corrupted, and the data verification result is "incorrect".

[0133] This verification process is automatic and fast. It can effectively filter out erroneous data caused by noise, interference or other transmission problems, thereby preventing the system from making judgments or performing operations based on inaccurate information and greatly improving the robustness of communication.

[0134] Suppose slave device 0x02 has completed data acquisition and is ready to send its response data (e.g., temperature value 25.5°C) to the master. Before sending, slave device 0x02 calculates a CRC checksum based on its data frame content (including frame header, address, data, etc.), assuming the calculation result is 0xABCD. It then appends 0xABCD to the end of the data frame and sends it out. Upon receiving this data frame, the master first parses the data portion and the appended checksum 0xABCD. Next, the master also independently performs a CRC calculation on the received data portion (i.e., temperature value 25.5°C, etc.). If the CRC result calculated by the master is also 0xABCD, then the S301 checksum is "correct," and the master will continue processing the response data. However, if due to electromagnetic interference on the bus, the temperature value in the data frame received by the master changes to 25.8°C, or the CRC checksum changes to 0xABCE, then the recalculated CRC value by the master will not match the received 0xABCD (or 0xABCE). At this point, the verification result of S301 is "error", indicating that the response data is unreliable and requires exception handling.

[0135] S302, if the data verification result is incorrect, a new inspection command frame is generated and sent to the bus. The slave target address of the new inspection command frame is the next slave to be inspected after the current slave.

[0136] Specifically, when the host detects a failure to verify the slave's response data, it means that although the slave may have sent a response, its content is unreliable, especially the "slave target address" information, which may be incorrect. In this situation, if the host continues to wait or attempt to obtain a valid response from the slave, it may cause the inspection chain to break or enter an infinite loop.

[0137] To avoid this situation, this embodiment employs a proactive skipping strategy: the host no longer waits for or re-requests a slave that failed to verify the current response data, but immediately determines that the slave is "abnormal" or "untrusted." To maintain the continuity of the inspection, the host will directly skip this abnormal slave and determine the address of the "next slave to be inspected" based on its internal slave address list or a preset inspection order. Then, the host proactively generates a new inspection command frame and sends the address of this "next slave to be inspected" as the "receive address" of the new command frame to the bus.

[0138] In this way, the problem of the slave device caused by data verification error can be effectively bypassed, the inspection chain can be reactivated, and the inspection process can continue, thereby improving the system's fault tolerance and inspection efficiency.

[0139] For example, continuing the example from the previous step, suppose the response data frame sent by slave 0x02 fails to pass verification when received by the master. The master determines that this response is incorrect and cannot extract reliable "slave destination address" information from it. At this point, the master will not wait for 0x02 to retransmit or attempt to retrieve data from 0x02. Instead, the master immediately determines, based on its internal slave address list (e.g., 0x01, 0x02, 0x03, 0x04, 0x05), that the next slave to be inspected after 0x02 is 0x03. The master then generates a completely new inspection command frame, in which the "receive address" field is set to 0x03, while the "sending address" remains the master itself (0x00), and the command code remains unchanged. The master sends this newly generated command frame onto the bus. After receiving this command, slave 0x03 will find that the command is addressed to itself and will initiate its own response process, sending a response frame containing its own data and the address of the next slave (0x04). In this way, even if there is a problem with the response data at 0x02, the inspection chain can continue smoothly from 0x03, avoiding the interruption of the entire inspection process.

[0140] If the data verification result is correct, the host processes and stores the current slave response data, and waits for or continues to inspect the next slave response data based on the slave target address carried in the slave response data.

[0141] In some implementations, the method of this embodiment may further include:

[0142] (1) Whenever no response data is received from the target slave within the preset time period, or the data verification result is incorrect, an abnormal situation is determined to have occurred, and the fault count is incremented by 1.

[0143] The purpose of this step is to identify and quantify two main types of communication failures: First, "timeout without response," which occurs when the host (or a slave responding according to the protocol) sends a command to a target slave but fails to receive any response data from that target slave within a preset waiting time. This usually indicates that the target slave is offline, busy, or the command was not received correctly. Second, "data verification error," which occurs when, although a response data is received from the target slave, verification (such as CRC check) reveals that the data has been corrupted or tampered with and is no longer reliable.

[0144] In either case, it indicates a communication problem with the target slave device. To distinguish between intermittent interference and persistent faults, the master maintains an independent "fault counter" for each slave device. Whenever any of the above-mentioned anomalies is detected, the slave device's fault counter increments by 1. This mechanism accumulates and reflects the frequency and persistence of specific slave device communication problems, providing a quantitative basis for subsequent fault diagnosis and early warning.

[0145] By maintaining independent fault counts for each slave device, the system can accurately track which slave device has a problem, as well as the frequency and duration of the problem, providing a quantitative basis for subsequent fault diagnosis and early warning.

[0146] (2) When the fault count reaches the set threshold, a fault warning is issued.

[0147] This step aims to transform accumulated communication anomaly information into actual fault warnings. Simply recording the number of faults is insufficient to guide operations; the host needs a mechanism to determine when the accumulated amount of these anomalies reaches a level requiring attention. Therefore, this embodiment sets a "fault count threshold" for each slave device. This threshold is a pre-set value representing the maximum number of communication anomalies the system can tolerate for a specific slave device before triggering a warning.

[0148] When the fault counter of a slave device reaches or exceeds a set threshold, the master device considers that the slave device is no longer experiencing an intermittent communication problem, but rather a persistent or more serious fault. At this time, the master device will immediately trigger a "fault warning," issuing a clear warning to the operator or upper-level system through various means such as audible and visual alarms, interface prompts, log recordings, SMS or email notifications, indicating that the slave device needs to be inspected or maintained.

[0149] This threshold-based early warning mechanism avoids false alarms caused by instantaneous communication fluctuations, ensuring that early warnings are only triggered when a problem truly affects system stability, thereby improving the accuracy of early warnings and the reliability of the system.

[0150] The following example illustrates this embodiment:

[0151] System composition: one master unit with address 0x00; four slave units with addresses 0x01, 0x02, 0x03, and 0x04 respectively, all of which are operating normally.

[0152] The host sends an inspection command C0, the data format of which is as described in step S2041, and the receiving address is 0x01.

[0153] Slave devices 0x01, 0x02, 0x03, and 0x04 simultaneously receive the inspection command C0 and analyze the C0 frame data. Slave device 0x01 meets the data judgment requirements and sends the response data C1 frame data after a delay, then clears its internal receive buffer. Slave devices 0x02, 0x03, and 0x04 do not meet the requirements of the C0 judgment data, so they do not respond to the bus, clear their internal receive buffers, and remain in the receiving state, waiting to receive new data on the bus.

[0154] Data frame C1, sent from address 0x01 to the bus, is simultaneously received by the master and slave devices 0x02, 0x03, and 0x04. The master transfers the C1 frame data to the memory area corresponding to the sending address 0x01, then clears the receive buffer, and continues to wait to receive new bus data.

[0155] Slave devices 0x02, 0x03, and 0x04 simultaneously receive data frame C1 sent to the bus from address 0x01 and perform data judgment on each. Only slave device 0x02 meets the judgment requirements. After a delay, slave device 0x02 automatically responds to the bus and sends data frame C2 to the bus. The other slave devices 0x03 and 0x04 clear their internal receive buffers and wait to receive new data on the bus.

[0156] The data frame C2 sent to the bus from address 0x02 is simultaneously received by the master and slave devices 0x01, 0x03, and 0x04. The master transfers the C2 frame data to the memory area corresponding to the sending address 0x02, then clears the receive buffer, and continues to wait to receive new bus data.

[0157] Slave devices 0x01, 0x03, and 0x04 simultaneously receive data frame C2 sent to the bus from address 0x02. They each perform data evaluation; only slave device 0x03 meets the evaluation criteria. After a delay, slave device 0x03 automatically acknowledges the bus and sends data frame C3 to the bus. The other slave devices 0x01 and 0x04 clear their internal receive buffers and wait to receive new data from the bus.

[0158] The data frame C3 sent to the bus from address 0x03 is simultaneously received by the master and slave devices 0x01, 0x02, and 0x04. The master transfers the C3 frame data to the memory area corresponding to the sending address 0x03, then clears the receive buffer, and continues to wait to receive new bus data.

[0159] Slave devices 0x01, 0x02, and 0x04 simultaneously receive data frame C3 sent to the bus from address 0x03. Each device performs a data evaluation; only slave device 0x04 meets the evaluation criteria. After a delay, slave device 0x04 automatically acknowledges the bus and sends data frame C4 to the bus. The other slave devices 0x01 and 0x02 clear their internal receive buffers and wait to receive new data from the bus.

[0160] Data frame C4, sent from address 0x04 to the bus, is simultaneously received by the master and slave devices 0x01, 0x02, and 0x03. The master transfers the C4 frame data to the memory area corresponding to the sending address 0x04, then clears the receive buffer, and continues to wait to receive new bus data.

[0161] Slave devices 0x01, 0x02, and 0x03 simultaneously receive data frame C4 sent to the bus from address 0x04. They each perform data judgment. If none of them meet the judgment requirements, the internal receive buffer is cleared, and the device waits to receive new data on the bus. In other words, there is no slave response bus.

[0162] If the master timeout fails to receive bus acknowledgment data, its internal JCQ register is already 0x04. It continues to increment by one. Since this exceeds the current total capacity of the slave devices, it is assigned a value of 0x01. The master then resends a new round of inspection commands, repeating the process described above.

[0163] After this round of inspection, the host only sent one inspection command, that is, it received the response data from the slave in sequence (0x01, 0x02, 0x03, 0x04), saving inspection time.

[0164] Taking a fire alarm system as an example, the bus communication rate is 2400bps, so one byte takes 4ms. If the master sends a frame of 8 bytes, the time to send one frame is 32ms; if the slave responds with a frame of 12 bytes, the time to respond is 48ms; and the master / slave transmission delay is 10ms.

[0165] Assuming the system has n slave machines and uses a master-slave communication method, the time required for one inspection cycle is:

[0166] (32+10+48+10)*n (unit: ms);

[0167] The time required to complete one inspection cycle using this patented method is 32 + (10 + 48) * n (in milliseconds).

[0168] For example, if n=20, the time for one inspection cycle is 2000ms using the main question-and-answer mode; using the method of this patent, it is 1192ms; saving up to 40.4% of the time.

[0169] For example, if n=40, the time for one inspection cycle is 4000ms using the main question-and-answer mode; using the method of this patent, it is 2352ms; saving up to 41.2% of the time.

[0170] For example, if n=80, the time for one inspection cycle is 8000ms using the main question-and-answer mode; using this patented method, it is 4672ms. This saves up to 41.6% of the time.

[0171] Clearly, the more slave devices there are, the more advantageous the method in this embodiment becomes, and the specific time saved is related to the communication protocol.

[0172] The method described in this embodiment is applicable to systems in half-duplex communication mode and employs a master-slave communication mechanism. It can be used for both wired and wireless communication systems. This method can be adopted for wired fire alarm systems, RS485 communication systems in industrial control, and point-to-point polling wireless communication systems to improve communication efficiency.

[0173] This embodiment also provides a method for implementing a predetermined time:

[0174] Each time the host MCU receives data via its serial port, a timer / counter T is initially set, with the initial value of T determined by the communication frame length. Under the control of the host MCU's internal timer, the timer / counter T counts down with high timing precision. When the count value reaches zero, an interrupt is triggered, indicating the end of the delay, thus achieving the predetermined time control.

[0175] The specific control process is as follows: Each time a data packet is received via a serial port interrupt, the timer / counter T is initialized. The duration of counter T is at least four times the interval between two serial port interrupts. During normal data reception, timer T is continuously initialized and will not trigger an interrupt when it decrements to zero. When the slave device is offline (i.e., there is no data on the bus), the input of the master serial port is in a static state. At the last serial data interrupt, counter T is initialized, and subsequent counters are decremented sequentially. When it decrements to zero, an interrupt is triggered, indicating that no serial port data has been received during the specified delay time. Afterward, the master device executes the corresponding program actions.

[0176] The scheduled time should be 2 to 4 serial port intervals longer than the slave device's delayed transmission time.

[0177] In this embodiment, the slave device has three states:

[0178] The first method involves sending data to a slave device on the bus. Since the slave device is in a transmitting state, it will not receive the data it sends, so it will not respond or need to perform any analysis.

[0179] The current target receiving slave determines that the frame header S, frame trailer S, and checksum are all correct, and that the target slave address for this bus reception is equal to the slave's own address. After a certain delay, the slave switches to transmit mode, acknowledges data to the bus, clears all contents of the data receive buffer, and waits to receive new data information on the bus.

[0180] The data format of this slave response bus is as follows: only the "sending address" is modified to the slave address of the current response bus, and the "target address slave" is modified to its own address + 1.

[0181] Other slave devices, upon determining that the target slave address is incorrect, do not respond, clear all contents of the data buffer, and wait for the next bus data reception.

[0182] The second type is the target receiving slave, which is the slave pointed to by the slave target address in the response data sent this time, that is, the next slave to automatically respond.

[0183] If the target slave device in this communication fails or is offline, then none of the slave devices will meet the aforementioned judgment conditions, and will not automatically continue to respond to the master, and the bus response will be in a "stopped" state.

[0184] After a predetermined delay, the host will resend the inspection command for the next slave address to trigger a new inspection process, thus ensuring the continuity of bus inspection.

[0185] The third type includes all other slave devices besides the two states mentioned above:

[0186] These slave devices are always in receive mode, receiving all communication data on the bus. They perform basic integrity checks on the received data, such as verifying the frame header, frame trailer, and checksum. However, since the destination address in the data frame is neither their own address nor designated by the previous slave as the next auto-acknowledgment target, they do not switch to transmit mode or perform any specific acknowledgment action. They simply continue listening to the bus, waiting to be directly addressed by the master or designated by the previous slave as the next acknowledgment target before taking appropriate action.

[0187] The reason for the delayed response at the local address is as follows:

[0188] Allow the master time to process the response data from the previous slave device, and ensure that only one device is in transmit mode on the bus at any given time, thus ensuring bus stability. This delay time can be set to 10ms, or at least four times the communication baud rate, to ensure that the master has sufficient time to process the data.

[0189] In some embodiments, reference Figure 6 The diagram visually illustrates the data transmission and reception timing and logical relationships between the master and multiple slave devices (slave devices 0x01 to 0x04) on the bus, presented in a timeline format. The legend clearly defines the meaning of each graphical element: solid-lined boxes represent data senders, while blank boxes in the same vertical column represent receivers, emphasizing the correspondence between sending and receiving in bus communication. Dashed lines connect senders and receivers, indicating a causal relationship between them—that is, a sending action by one device triggers a receiving or response from another device. Of particular note is… Figure 6 The open boxes in the diagram represent communication delays, with the red open boxes specifically indicating delays caused by the slave device itself. The diagonal lines within the white boxes in the master's row represent data received by the master from the slave.

[0190] from Figure 6 As can be seen, the master first issues the inspection command, and the slave device, after receiving the command from the master, begins to send its own data only after a certain delay (open box). For example, after the master sends a data frame, slave device 0x01 receives and processes it, then generates a delay caused by itself (red open box), before sending the data. The data sent by this slave device (white box with diagonal lines) is received by the master. Subsequently, the master waits for the next response from the slave device.

[0191] This pattern repeats during the communication processes of slave devices 0x02, 0x03, and 0x04. The entire timing diagram reveals the serial, one-to-one response characteristics of bus communication, as well as the unavoidable delays during data transmission. It emphasizes that the master, as the bus leader, polls or sequentially interacts with the slaves, and that each slave's response includes its inherent processing delay. This timing logic is crucial for understanding and optimizing bus communication performance, especially in systems with high real-time requirements.

[0192] In this embodiment, the master only needs to initiate one round of inspection. All slave devices receive the master's inspection command, and the corresponding slave device responds to the master. All other slave devices monitor the data on the bus currently responding to the master and automatically determine which slave device needs to automatically respond to the bus next, thus forming a continuous automatic response mechanism and forming an automatic and orderly response. This eliminates the need for the master to query each time other slave devices respond, while ensuring that only one device is sending data on the bus, avoiding data collisions on the bus, ensuring the stability of bus communication, saving master query time, and improving inspection efficiency.

[0193] For slave devices, their control logic is generally less. With the rapidly developing performance of microprocessors, the MCU resources are sufficient to handle the increased task of monitoring data sent to the bus by other slave devices, and the processing logic is clear and simple.

[0194] For the master unit, the resources required by its MCU have not increased, such as the bus receive buffer and slave data storage buffer. The bus receive data judgment logic has also not become more complex, but the number of inspection commands for each slave unit has been reduced, greatly saving the inspection cycle time. This allows the master unit to quickly obtain the relevant status / data of the slave units, resulting in a rapid response from the master unit and significantly improving the control effect of the system.

[0195] In some embodiments, for systems where all slave devices are in normal condition, the aforementioned method can greatly improve inspection efficiency. However, as the system runs, many slave devices may malfunction. Although the aforementioned method can still ensure the automatic inspection process of the system, the master device needs to restart the inspection process each time a missing slave device is encountered, which increases the inspection time. Of course, it is still more efficient than the solution in the background.

[0196] The following discussion focuses on improving the algorithm to achieve intelligent learning, thereby compensating for the increased inspection time caused by missing slave addresses.

[0197] Each time a slave device on the auto-responder bus sends data to the bus, it continues to monitor the next data frame that appears on the bus. If the next data frame is sent by the master, it means that the data from the slave's auto-responder was not transmitted to its "target slave address," meaning the "target slave address" did not complete the auto-responder process, prompting the master to resend the inspection command. At this point, the slave device on the auto-responder bus starts a communication fault counter for the "target slave address." When this counter accumulates n times, it confirms that the corresponding target slave has failed to complete the auto-responder communication. The slave device then increments its internal "target slave address" by 1 (note that the target address had already been incremented by 1 previously, and this is an additional increment), effectively skipping the "target slave address" that failed to respond. When the slave responds to the bus again, it directly points to the new "target slave address."

[0198] The system, through multiple rounds of iteration, reduces the process of the master repeatedly sending inspection commands due to missing slave addresses, and also ensures that the slaves automatically and continuously respond, further reducing the inspection cycle and improving inspection efficiency. In a complete polling cycle, assuming the number of slaves is n, and the time for the master to send one inspection command is t (including bus downtime), the method in this embodiment, compared to the traditional master-slave response mode, can save (n-1)×t time; the larger n is, the more significant the effect. The system's original communication hardware does not need to be changed; only the communication protocol needs modification.

[0199] Figure 7 It demonstrates the communication process between the master and slave devices and their state switching mechanism, with a polling-based communication model at its core. Figure 7 Arrows of different colors represent different processes, while arrows of the same color represent the same process.

[0200] Specifically, Figure 7 In the diagram, the red arrows indicate the process of the host initiating communication and sending inspection commands. It begins with the host system initialization, guides the host to send inspection commands, and passes these commands to the target slave on the bus or other slaves other than the host target, marking the start of the host actively addressing and initiating data exchange.

[0201] The cyan arrows represent the exception handling process when the target slave device does not respond or does not exist at all. In this case, the master device recognizes the communication failure, enters a predetermined delay state, and then regenerates and sends a new inspection command to skip the unresponsive slave device and continue polling on the bus.

[0202] The green arrows depict the process of a slave device responding normally and transmitting data to the master. This indicates that after the addressed slave device successfully receives the master command, it responds and sends data to the master. It also includes the path where other slave devices, after being addressed, become the target slave devices and respond, representing a crucial link in the data flow from slave to master.

[0203] The purple arrow indicates the process of the host receiving data and completing the current communication cycle. It guides the data sent by the slave to the host receiving module, and after the host successfully receives the data, it returns control to the host, causing it to enter a predetermined delay phase to prepare for the sending of the next inspection command. This reflects the host's receiving response.

[0204] The blue arrow specifically indicates the process of role (identity) switching for the slave device during communication. It bidirectionally connects the two states of "target slave device" and "slave device other than target slave device", indicating that the slave device becomes the target slave device when it is addressed and responded to by the master, and switches to other slave devices when it completes its task or is not addressed, reflecting the dynamic switching of the slave device's role to adapt to the master's polling mechanism.

[0205] This invention also provides a bus communication inspection method based on master-slave communication mode, applied to the slave device of the above system, specifically including the following steps:

[0206] S301, when designated as the current inspection slave, receives an inspection command frame from the host or response data from the previous slave, wherein the inspection command frame or the response data from the previous slave contains the address of the current inspection slave.

[0207] This step describes how a slave device is "wake up" or "activated" to participate in the inspection. When a slave device is designated as the current inspection slave, it receives a specific data packet via the bus. This data packet has two main forms:

[0208] The first type is the "inspection command frame" from the host. This typically occurs at the beginning of an inspection. The host (e.g., address 0x00) generates an inspection command frame whose "receive address" field explicitly specifies the first slave to be inspected (e.g., address 0x01). When this command frame is sent to the bus, all slaves connected to the bus listen for and parse the data stream on the bus. Only when a slave recognizes that the "receive address" in the command frame matches its own address does it consider itself to be the designated current inspection slave and begin processing the command.

[0209] The second scenario involves receiving response data from the previous slave device. This is the core of the chain-like inspection scheme in this embodiment. After the previous slave device (e.g., slave A) completes its response task, it includes the address of the next slave device to be inspected (e.g., slave B) as the "slave target address" in its response data. When slave A's response data is broadcast on the bus, slave B will listen and recognize that the "slave target address" in this response data is its own address. At this point, slave B will know that it has become the currently designated slave device to be inspected, and then slave B needs to respond, and so on.

[0210] Regardless of the method, the slave device needs to have the ability to listen to bus data, parse protocols, and identify addresses to ensure that it can capture inspection commands or chain trigger signals for itself in a timely and accurate manner.

[0211] S302, based on the inspection command frame or the response data of the previous slave device, determine the address of the next slave device to be inspected according to the preset inspection sequence.

[0212] Specifically, once a slave device successfully receives an inspection command frame for itself or a response data from the previous slave device, it needs to extract the necessary information from it and combine it with its own preset logic to determine which slave device will be inspected next.

[0213] If the slave device receives a patrol command frame from the master (usually the first patrol), it will look up the address of the next slave device based on its internally stored preset patrol order list (e.g., a list of slave devices sorted in ascending order of address, or a list of slave groups for a specific function). For example, if the current slave device is 0x01, and the preset order is 0x01, 0x02, 0x03..., then it will determine that 0x02 is the next target.

[0214] If the slave device receives a response from a previous slave device, even though that response already contains the "slave target address," the current slave device may still need to verify the validity of this address, or determine the "next slave device address to be inspected" based on more complex logic (e.g., skipping faulty slave devices, adjusting the order according to priority, etc.). This "preset inspection order" can be fixed at the factory, configured by the host during system initialization, or dynamically updated during runtime. The slave device needs to have corresponding storage units to store this order information and possess algorithms for finding and locating the next address.

[0215] This process ensures the continuity and logic of the inspection, enabling the slave device to autonomously guide the inspection chain without the need for frequent intervention from the master device.

[0216] S303, generate new slave response data based on the address of the next slave to be inspected. The new slave response data includes the address of the current slave to be inspected, the address of the master, and the address of the next slave to be inspected as the target address of the slave.

[0217] Specifically, after determining the address of the next slave device to be inspected, the current slave device will generate its own "slave response data." The slave response data is constructed according to the format specified in the bus communication protocol, and it contains at least the following core information: First, the address of the current slave device being inspected, indicating who is responding and letting the master know which slave device is currently being polled. Second, the address of the master, ensuring that the response data can be correctly sent back to the master that initiated the inspection. Most importantly, the address of the next slave device to be inspected, which serves as the target address. This field is the essence of this scheme's chained inspection mechanism; it explicitly informs the master of the next inspection target determined by the current slave device, and indirectly notifies all slave devices on the bus (especially the next target slave device).

[0218] In addition to address information, the response data usually includes the current operating status of the slave device, the collected data, fault information and other business data, which are necessary for the host to perform device management and status monitoring.

[0219] The slave device's internal communication module is responsible for encapsulating this information into data frames according to a specific protocol, and performing necessary verification and encoding to ensure the integrity and reliability of data transmission. This generation process is fast and automatic. Once the slave device has completed data acquisition and next address determination, the response data is immediately assembled, preparing for the next transmission.

[0220] S304, the new slave response data is sent to the bus for the master and the next slave to be inspected to receive.

[0221] Specifically, the current slave device will send this new slave response data onto the bus via its bus interface. This transmission process must adhere to the timing and rules of the bus protocol to ensure conflict-free data transmission. When the response data is sent onto the bus, all devices on the bus, including the master and all other slave devices, will listen for and receive this data.

[0222] For the host, receiving this response data means that it has successfully completed the inspection of the current slave device and has learned from the "slave target address" field in the response data which slave device will be inspected next. The host will then use this information to prepare for the next listening or command sending (if necessary).

[0223] For the next slave device to be inspected (e.g., slave B), when it listens to the bus, it will recognize that the "slave target address" in this response data is its own address. For slave B, this is as if it has received an implicit "it's your turn to respond" signal, thereby triggering it to enter its own inspection response process (i.e., return to the first step of this method).

[0224] In this way, the current slave device not only reports its own status to the master, but more importantly, it acts as a "messenger," passing the inspection baton to the next slave device. This chain-like transmission mechanism greatly simplifies the master's control logic, making the entire bus inspection process smoother, more efficient, and more adaptive.

[0225] This invention employs the aforementioned method and steps to describe a bus communication inspection method on the slave side, delegating some decision-making authority and information transmission responsibility in the inspection process to the slave. Upon receiving a command from the master or a response from a previous slave, the slave can autonomously determine and inform the address of the next slave to be inspected according to preset logic, and generate response data containing this information to send to the bus. This design greatly simplifies the master's inspection management logic; the master does not need to maintain a complex slave list or precise inspection order, but only needs to receive the slave's response to know the next inspection target, thereby reducing the master's computational and storage burden.

[0226] Meanwhile, this embodiment enhances the scalability and adaptability of the bus communication system. When the number of slave devices on the bus changes (such as adding or removing slave devices), as long as the inspection sequence inside the slave device can be adjusted accordingly, the entire inspection chain can automatically adapt without requiring large-scale modifications to the host software, achieving a "plug and play" effect.

[0227] Furthermore, the chain-like information transmission between slave devices reduces the need for the master to frequently send individual addressing commands, optimizes bus bandwidth utilization, and improves overall inspection efficiency. This slave-driven intelligent inspection mode makes the system more flexible and robust, effectively improving the automation level and ease of operation and maintenance of the bus communication system.

[0228] The methods provided in the above embodiments can be executed by a host or a slave device, both of which are composed of electronic devices. The electronic device in the embodiments of the present invention is described below from a hardware processing perspective; please refer to [link to relevant documentation]. Figure 8 This is a schematic diagram of the structure of an electronic device in an embodiment of the present invention.

[0229] It should be noted that, Figure 8 The structure of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0230] In this embodiment, the electronic device includes a processor and a memory; the memory is used to store computer program code, the computer program code including computer instructions, and the processor calls the computer instructions to cause the electronic device to execute the method provided in the above embodiment.

[0231] Specifically, the processor can be a general-purpose processor, digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, which can implement or execute the methods and steps disclosed in the embodiments of this application by running computer instructions. The general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly reflected as the hardware in the processor executing the steps of these methods, or the hardware and software modules in the processor combining to execute the steps of these methods.

[0232] The memory can be non-volatile memory, such as a hard disk (HD) or a solid-state drive (SSD), or it can be volatile memory, such as random-access memory (RAM). Memory is a device capable of carrying or storing computer program code in the form of computer instructions or data structures. In the embodiments of this application, the memory can also be a circuit or any other device capable of implementing storage functions, used to store programs, instructions, and / or data.

[0233] This invention also provides a computer-readable storage medium storing computer instructions thereon, which, when executed on an electronic device, cause the electronic device to perform the methods provided in the above embodiments.

[0234] The storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk drive (HDD), and solid state drive (SSD). Electronic devices can invoke computer instructions stored in the storage medium.

[0235] The methods provided in this application can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented entirely or partially in the form of a computer program product.

[0236] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on an electronic device, the electronic device performs the method provided in the above embodiments.

[0237] In this embodiment, the computer instructions in the computer program product can be stored in a computer-readable storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as an SSD.

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

Claims

1. A bus communication inspection method based on master-slave communication mode, characterized in that, A host computer is used in a bus communication system, the bus communication system further including a bus and multiple slave computers, wherein the host computer and the slave computers are both connected to the bus, and the method includes: Determine the starting slave from the plurality of slaves; A patrol command frame is generated based on the address of the starting slave device. The patrol command frame includes a receiving address, a sending address, and a command code. In the patrol command frame, the receiving address is the address of the starting slave device, and the sending address is the address of the master device. After sending the inspection command frame to the bus, the system listens to the data transmitted on the bus to obtain the start slave response data from the start slave. The receiving address of the start slave response data is the address of the master, the sending address is the address of the start slave, and the slave target address is the address of the next slave to be inspected. After receiving the initial slave response data, continuously monitor the data transmitted on the bus to obtain the current slave response data from the current slave. The receiving address of the current slave response data is the address of the master, the sending address is the address of the current slave, and the slave target address is the address of the next target slave to be inspected after the current slave. During the continuous monitoring of data transmitted on the bus, the method further includes: If no response data is received from the target slave device within a preset time period, the next slave device to be inspected after the target slave device will be identified as the new target slave device. A new inspection command frame is generated based on the address of the new target slave device; The new inspection command frame is sent to the bus so that the new target slave device receives and responds; The method further includes: After each slave device on the auto-responder bus sends data to the bus, it continues to monitor the next data frame that appears on the bus. If the next data frame is sent by the master device, the slave device starts a communication failure counter for the target slave address. When the communication failure counter accumulates n times, it is confirmed that the corresponding target slave has failed and cannot complete the auto-responder communication. The slave device increments its internal target slave address by 1 to skip the target slave address that has not responded. When the slave device responds to the bus again, it directly points to the new target slave address.

2. The method according to claim 1, characterized in that, After determining the next slave device to be inspected as the new target slave device if no response data is received from the target slave device within a preset time period, the method further includes: Determine whether the address of the new target slave device exceeds the set maximum slave device address; If so, the current inspection cycle is considered complete, and a new inspection command frame is generated based on the address of the starting slave device when the next inspection cycle arrives.

3. The method according to claim 1, characterized in that, The method further includes: The current slave response data is verified to obtain the data verification result; If the data verification result is incorrect, a new inspection command frame is generated and sent to the bus. The slave target address of the new inspection command frame is the next slave to be inspected after the current slave.

4. The method according to claim 3, characterized in that, The method further includes: Whenever no response data is received from the target slave device within a preset time period, or the data verification result is incorrect, an abnormal situation is determined to have occurred, and the fault count is incremented by 1; When the fault count reaches a set threshold, a fault warning is issued.

5. The method according to any one of claims 1-4, characterized in that, The inspection command frame specifically includes: frame header, receiving address, sending address, command code, spare information, checksum, and frame trailer; The slave device's response data specifically includes a frame header, receiving address, sending address, slave device target address, command code, data information, checksum, and frame trailer.

6. A bus communication inspection method based on master-slave communication mode, characterized in that, A slave device applied in a bus communication system, wherein the bus communication system further includes a master device and a bus, and both the slave device and the master device are connected to the bus, the method comprising: When designated as the current inspection slave, it receives an inspection command frame from the host or a response data from the previous slave, wherein the inspection command frame or the response data from the previous slave contains the address of the current inspection slave. Based on the inspection command frame or the response data of the previous slave device, the address of the next slave device to be inspected is determined according to the preset inspection sequence. New slave response data is generated based on the address of the next slave to be inspected. The new slave response data includes the address of the currently inspected slave, the address of the master, and the address of the next slave to be inspected, which serves as the target address of the slave. The new slave response data is sent to the bus for the master and the next slave to be inspected to receive; During the continuous monitoring of data transmitted on the bus, the method further includes: If the host does not receive a response data from the target slave within a preset time period, the host will identify the next slave to be inspected after the target slave as the new target slave; The host generates a new inspection command frame based on the address of the new target slave. The host sends the new inspection command frame to the bus so that the new target slave receives and responds; The method further includes: After each slave device on the auto-responder bus sends data to the bus, it continues to monitor the next data frame that appears on the bus. If the next data frame is sent by the master device, the slave device starts a communication failure counter for the target slave address. When the communication failure counter accumulates n times, it is confirmed that the corresponding target slave has failed and cannot complete the auto-responder communication. The slave device increments its internal target slave address by 1 to skip the target slave address that has not responded. When the slave device responds to the bus again, it directly points to the new target slave address.

7. An electronic device, characterized in that, Including processor and memory; The memory is used to store computer program code, the computer program code including computer instructions, and the processor invokes the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-6.

9. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-6.

Images