Method, system, device and medium for address conflict identification

Abstract

The invention provides a method, a system, a device and a medium for address conflict identification. The method comprises the steps that a first device sends a request to a second device through the bus, and the second device is provided with a first address; after the second equipment receives the request of the first equipment, the second equipment monitors on the bus to detect whether address conflicts exist or not; under the condition that the address conflict is detected, the second equipment changes an address into a second address, and the second address is different from the first address; and the first equipment queries the second address to identify the address conflict. Based on the method, system and device for address conflict identification and the medium provided by the invention, the address conflict in the bus can be automatically identified, and the stability and intelligence of the system are improved.

Description

Technical Field

[0001] The present invention relates to industrial communication control technology, and more particularly, to a method, system, device and medium for address conflict identification. Background Art

[0002] The Modbus Remote Terminal Unit (RTU) communication protocol is a fieldbus standard widely used in the field of power distribution. Equipment from different manufacturers can easily support this standard. Through the Modbus RTU bus, control equipment produced by different manufacturers can be easily connected to an industrial network for centralized monitoring.

[0003] Generally, the Modbus RTU bus communicates in a master-slave mode, wherein there is a master device in a system and multiple slave devices communicating with the master device via the Modbus RTU bus. In addition, the addressing of the slave device relies on a unique Modbus address.

[0004] The Modbus RTU bus requires that the slave device address is unique. If two slave devices have the same address, the communication between the master device and the two slave devices will be unstable, and a series of communication failures will occur. In industrial communication control, due to the connection of a variety of devices or human misconfiguration, address conflicts will inevitably occur, affecting the stable operation of the entire digital system.

[0005] In most cases, the master device needs to perform a heartbeat mechanism to maintain and identify communication failures of the slave device, including communication failures caused by address conflicts. However, the current communication fault detection method has the following disadvantages: after identifying the communication failure, it is necessary to manually troubleshoot the cause to identify whether the failure is caused by the disconnection of the communication line or the communication parameter setting (including the address); and after identifying the address conflict failure, it is necessary to manually reset the address of the slave device. Since the communication channel itself is blocked, it is also necessary to use the buttons supported by the slave device to set the address, which is very inconvenient for the equipment already installed on site. Summary of the invention

[0006] The present disclosure provides a method, system, device and medium for address conflict identification to automatically identify communication failures caused by address conflicts on a Modbus RTU bus, thereby improving the overall stability and intelligence of a digital system.

[0007] For example, at least one embodiment of the present disclosure provides a method for identifying address conflicts on a bus, the method comprising: a first device sends a request to a second device via a bus, wherein the second device has a first address; after the second device receives the request from the first device, the second device monitors the bus to detect whether there is an address conflict; when an address conflict is detected, the second device changes the address to a second address, wherein the second address is different from the first address; and the address conflict is identified by the first device querying the second address.

[0008] For example, in a method for address conflict identification on a bus according to at least one embodiment of the present disclosure, after the second device receives a request from the first device on the bus, the second device determines whether the request is a retransmission request.

[0009] For example, in a method for identifying address conflicts on a bus according to at least one embodiment of the present disclosure, a second device monitors the bus to detect whether there is an address conflict, including: when it is determined that the request is a retransmission request, the second device monitors the bus within a first random time period to detect whether there is an address conflict; and wherein the first random time period is determined based on a device serial number of the second device.

[0010] For example, according to at least one embodiment of the present disclosure, the method for identifying address conflicts on a bus also includes: when no address conflict is detected within a first random time period, the second device replies to the first device; and after the reply, the second device listens on the bus to detect whether there is an address conflict until a new request is received from the first device or until a predetermined timeout period set by the first device.

[0011] For example, in a method for identifying address conflicts on a bus according to at least one embodiment of the present disclosure, a second device monitors the bus to detect whether an address conflict exists, including: when it is determined that the request is not a retransmission request, the second device monitors the bus to detect whether an address conflict exists until a predetermined timeout period set by the first device.

[0012] For example, in a method for identifying address conflicts on a bus according to at least one embodiment of the present disclosure, a second device monitors the bus to detect whether an address conflict exists, including: the second device monitors a data packet on the bus to detect whether the data packet has an address identical to a first address.

[0013] For example, in a method for address conflict identification on a bus according to at least one embodiment of the present disclosure, the second address is preconfigured by the first device.

[0014] For example, in a method for identifying address conflicts on a bus according to at least one embodiment of the present disclosure, an address conflict is identified by querying a second address by a first device, including: the first device sends multiple query commands to the second address, wherein each of the multiple query commands includes a device serial number of one of a plurality of devices that communicate with the first device via the bus.

[0015] For example, according to at least one embodiment of the present disclosure, the method for identifying address conflicts on a bus also includes: in the presence of a second device with a second address, the second device determines that the device serial number of the query command matches the device serial number of the second device; and based on the determination, the second device sends device information and fault information to the first device.

[0016] For example, according to at least one embodiment of the present disclosure, the method for identifying an address conflict on a bus further includes: after identifying the address conflict, the first device sets the address of the second device.

[0017] For example, in a method for address conflict identification on a bus according to at least one embodiment of the present disclosure, a first device sets an address for a second device, including: the first device sends an address setting request, wherein the address setting request includes a device serial number of the second device; and the second device sends a response to the first device based on the device serial number in the address setting request.

[0018] For example, in a method for address conflict identification on a bus according to at least one embodiment of the present disclosure, the bus is a Modbus remote terminal unit RTU bus.

[0019] For example, at least one embodiment of the present disclosure provides a system for identifying address conflicts on a bus, the system comprising: a first device; multiple devices that communicate with the first device via the bus, wherein the multiple devices include a second device; wherein the first device sends a request to the second device via the bus, wherein the second device has a first address; after the second device receives the request from the first device, the second device listens on the bus to detect whether there is an address conflict; when an address conflict is detected, the second device changes the address to a second address, wherein the second address is different from the first address; the first device queries the second address to identify the address conflict.

[0020] For example, at least one embodiment of the present disclosure provides a device for identifying address conflicts on a bus, the device comprising: a memory storing executable instructions; at least one processor, the at least one processor being coupled to the memory, wherein the at least one processor is configured to implement the method described in any one of the various embodiments of the present disclosure when executing the executable instructions.

[0021] For example, at least one embodiment of the present disclosure provides a non-transitory computer-readable medium storing executable instructions, wherein the executable instructions, when executed by a processor, cause the processor to implement the method described in any one of the various embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 An example of the architecture of a Modbus RTU bus is shown;

[0023] Figure 2 An example structure of a protocol message in a Modbus RTU bus is shown;

[0024] Figure 3A A schematic diagram showing communication in unicast mode in a Modbus RTU bus is shown;

[0025] Figure 3B A schematic diagram showing communication in a broadcast mode in a Modbus RTU bus is shown;

[0026] Figure 4 A method for address conflict identification in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown;

[0027] Figure 5 A flow chart for detecting address conflicts in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown;

[0028] Figure 6 A flowchart of a master device for identifying and eliminating address conflicts in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown;

[0029] Figure 7 A flowchart of a slave device for identifying and eliminating address conflicts in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown;

[0030] Fig. 8A and 8B A timing diagram of a method for address conflict identification in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown;

[0031] Fig. 9 An apparatus for address conflict identification in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0032] The following description with reference to the accompanying drawings is provided to facilitate a comprehensive understanding of the various embodiments of the present disclosure as defined by the claims and their equivalents. This description includes various specific details to facilitate understanding but should be considered as exemplary only. Therefore, one of ordinary skill in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of the present disclosure. In addition, for the sake of clarity and conciseness, descriptions of well-known functions and structures may be omitted.

[0033] The terms and expressions used in the following specification and claims are not limited to their dictionary meanings, but are merely used by the inventor to enable a clear and consistent understanding of the present disclosure. Therefore, it should be apparent to those skilled in the art that the following description of various embodiments of the present disclosure is provided for illustration purposes only and not for the purpose of limiting the present disclosure as defined in the appended claims and their equivalents.

[0034] It should be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more of such surfaces.

[0035] The term "include" or "may include" refers to the presence of the corresponding disclosed functions, operations or components that can be used in various embodiments of the present disclosure, rather than limiting the presence of one or more additional functions, operations or features. In addition, the term "include" or "have" may be interpreted as indicating certain characteristics, numbers, steps, operations, constituent elements, components or combinations thereof, but should not be interpreted as excluding the possibility of the presence of one or more other characteristics, numbers, steps, operations, constituent elements, components or combinations thereof.

[0036] The term "or" used in various embodiments of the present disclosure includes any of the listed terms and all combinations thereof. For example, "A or B" may include A, may include B, or may include both A and B.

[0037] Unless defined differently, all terms (including technical terms or scientific terms) used in the present disclosure have the same meanings as understood by those skilled in the art described in the present disclosure. Common terms as defined in dictionaries are interpreted as having meanings consistent with the context in the relevant technical field, and should not be interpreted ideally or overly formally unless clearly defined in the present disclosure.

[0038] In the current solution for communication failures caused by address conflicts on the Modbus RTU bus, after the communication failure is identified, it is necessary to manually check whether the cause of the failure is an address conflict on the bus, and it is necessary to manually reset the address of the slave device.

[0039] At least one embodiment of the present disclosure provides a method, system, device and medium for automatically identifying address conflicts on a Modbus RTU bus. In addition, according to the method of at least one embodiment of the present disclosure, after identifying an address conflict on a Modbus RTU bus, the address of the slave device with the address conflict can be automatically reset so that communication can be self-recovered.

[0040] Exemplary embodiments of the present disclosure are further described below in conjunction with the accompanying drawings.

[0041] The text and drawings are provided as examples only to help readers understand the present disclosure. They are not intended and should not be interpreted as limiting the scope of the present disclosure in any way. Although certain embodiments and examples have been provided, it is obvious to those skilled in the art based on what is disclosed herein that the embodiments and examples shown may be changed without departing from the scope of the present disclosure.

[0042] Figure 1 An example of the architecture of a Modbus RTU bus is shown.

[0043] like Figure 1 As shown, in the Modbus RTU bus architecture, the Modbus RTU bus communicates in a master-slave mode, in which a master device communicates with multiple slave devices via the Modbus RTU bus. Each slave device has a unique Modbus address as its device address, and the master device communicates with each slave device based on the unique device address. Among them, the device address only represents the slave device address. For example, the device address can be defined as an 8-bit unsigned integer with a value range of 1 to 255. In addition, the master device can pre-configure the address to different address types. For example, the master device can configure 0 as a broadcast address, 1 to 247 as the address range available to the slave device, and 248 to 255 as a reserved address range.

[0044] In the Modbus RTU bus, the slave device address may appear as the first byte of a data packet (such as a protocol message) in data transmission or reception via the bus, for example, as follows according to Figure 2 The structure of the protocol messages described.

[0045] Figure 2 An example structure of a protocol message in a Modbus RTU bus is shown.

[0046] Figure 2The structure of the protocol message in the Modbus RTU bus is shown. The protocol message is the basic unit in the communication process, which may include an address field, a Modbus protocol data unit (PDU), and a check field. The address field can be used to indicate a Modbus address, for example, a Modbus address can be defined as an 8-bit binary number. For example, a Modbus address may include a slave device address, a broadcast address, and a reserved address. The check field may be, for example, a cyclic redundancy check (CRC) or a longitudinal redundancy check (LRC), but embodiments of the present disclosure are not limited thereto.

[0047] In addition, if Figure 2 As shown in the figure, the Modbus PDU part includes a function code field and data. Among them, the function code field can be used to indicate the purpose and operation type of the protocol message. In the Modbus bus protocol, the function code can be defined as an 8-bit unsigned integer with a value range of 1 to 255. According to the different values ​​of the function code, the protocol message can be divided into different types such as reading data, writing data, and controlling equipment.

[0048] Modbus RTU bus supports two communication modes: unicast and broadcast. Figure 3A and Figure 3B The schematic diagrams of communication in unicast mode and communication in broadcast mode in ModbusRTU bus are shown respectively. Figure 3A and Figure 3B In the example, the master device communicates with three slave devices via the bus, but it should be understood that Figure 3A and Figure 3B This is for example purposes only, and a master device may communicate with any number of slave devices via the bus.

[0049] exist Figure 3A In the example, the master device performs unicast communication with slave device 1. In this example, the master device sends a unicast request via the bus, for example, the unicast request can be sent in the form of a protocol message. The sent unicast request includes the device address of slave device 1, so only slave device 1 receives the unicast request, and slave device 1 replies to the master device according to the unicast request.

[0050] exist Figure 3B In this example, the master device performs broadcast communication. In this example, the master device sends a broadcast request via the bus. For example, the broadcast request can be sent in the form of a protocol message. The broadcast request sent includes a broadcast address (for example, address 0). At this time, all slave devices (for example, Figure 3B Slave device 1, slave device 2, and slave device 3 in the master device will receive the broadcast request. In addition, for the broadcast request, there is no need to reply to the master device.

[0051] For the Modbus RTU bus, the address of the slave device is required to be unique, otherwise the communication between the master device and the two slave devices will be unstable and cause a series of communication failures. In order to solve the address conflict identification on the Modbus RTU bus and ensure the stability of the system, a method for address conflict identification in the Modbus RTU bus is provided according to at least one embodiment of the present disclosure.

[0052] Figure 4 A method for address conflict identification in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown, and the method includes steps S410-S440.

[0053] In step S410, a first device sends a request to a second device via a bus, wherein the second device has a first address.

[0054] According to at least one embodiment of the present disclosure, a first device may communicate with a second device via a Modbus RTU bus by addressing a first address. For example, the first device may be a master device, and the second device may be a slave device. Furthermore, the first address may be a unique Modbus address configured by the first device to the second device.

[0055] In step S420, after the second device receives the request from the first device, the second device monitors on the bus to detect whether there is an address conflict.

[0056] According to at least one embodiment of the present disclosure, the second device may monitor a data packet (such as a Modbus RTU protocol message) on a Modbus RTU bus to detect whether there is an address conflict. For example, the second device may obtain an address field in the data packet by monitoring the data packet on the bus, and determine whether there is an address conflict based on determining whether the address indicated by the address field is the same as the first address. For example, when the address indicated by the address field included in the data packet monitored by the second device is the same as the first address, the second device may determine that there is an address conflict.

[0057] According to at least one embodiment of the present disclosure, after the second device receives the request of the first device, the second device may process the request, for example, the processing may include but is not limited to determining whether the request is a retransmission request. For example, the second device may determine whether the request is a retransmission request based on whether the received request is sent by the same request frame within a given time. According to at least one embodiment of the present disclosure, the second device may monitor the bus in different ways based on the processing result of the request. For example, in the case where it is determined that the received request is a retransmission request, the second device may first monitor the data packet on the bus within a first time period. In at least one embodiment of the present disclosure, the first time period may be determined based on the device serial number of the second device, for example, the first time period may be determined by calculating a random number using the device serial number of the second device as a seed, but the embodiments of the present disclosure are not limited thereto. After the first time period expires, the second device may send a reply to the first device, and continue to monitor after the reply ends, for example, the second device may continue to monitor on the bus until any new request from the first device is received, or until a predetermined timeout period (for example, the predetermined timeout period may be pre-set by the first device).

[0058] According to at least one embodiment of the present disclosure, when it is determined that the received request is not a retransmission request, the second device may, starting from receiving the request from the main device, continue to listen to the data packet until a predetermined timeout period (for example, the predetermined timeout period may be pre-set by the first device). For example, the predetermined timeout period may be 1 second, but the embodiments of the present disclosure are not limited to this.

[0059] In step S430, in case an address conflict is detected, the second device changes the address to a second address, wherein the second address is different from the first address.

[0060] According to at least one embodiment of the present disclosure, in the event of an address conflict being detected, the second device may change its device to a second address, for example, the second address may be a reserved address (for example, for a Modbus RTU bus, the reserved address may be 247). According to at least one embodiment of the present disclosure, the reserved address may be preconfigured by the first device.

[0061] In step S440, the first device queries the second address to identify an address conflict.

[0062] According to at least one embodiment of the present disclosure, the first device may identify an address conflict by querying the second address. For example, the first device may send an error query command to the second address, and if the first device receives a reply after sending the error query command, the first device may determine that an address conflict has occurred. For example, the reply may include but is not limited to an error code, device information, fault information, etc.

[0063] Additionally, according to at least one embodiment of the present disclosure, the first device may send multiple error query commands to the second address, for example, in a unicast polling manner, wherein each of the multiple error query commands includes a device serial number of one of the multiple devices communicating with the first device via the bus. For example, when there may be multiple address conflicts, at this time, there may be multiple devices with the second address, and the multiple devices may determine whether to send a reply to the first device based on whether the device serial number in the received error query command matches (for example, whether they are the same as) their device serial numbers.

[0064] Figure 4 A method for identifying address conflicts in a Modbus RTU bus is provided. The method can automatically identify address conflict faults in the Modbus RTU bus, and does not require manual identification and troubleshooting when a fault occurs, thereby improving the stability and intelligence of the system.

[0065] Combine the following Figures 5 to 7 A method for address conflict identification and self-recovery in a Modbus RTU bus according to at least one embodiment of the present disclosure is described. Figure 4 The first device described may be a master device in a Modbus RTU bus, and, as Figure 4 The described second device may be a slave device in a Modbus RTU bus.

[0066] Figure 5 A flow chart for detecting address conflicts in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown.

[0067] According to at least one embodiment of the present disclosure, a slave device on a Modbus RTU bus can detect an address conflict on the Modbus RTU bus. Figure 5 As shown in FIG. 1 , the slave device can receive the request sent by the master device and process the received request. Figure 5 As shown, after processing the request, the slave device can determine whether the received request is a retransmission unicast retransmission request. For example, the slave device can determine whether the request is a retransmission request based on whether the received request is sent by the same request frame within a given time.

[0068] like Figure 5As shown, in the case where it is determined that the request is a unicast request, there may be a random delay mechanism for the reply of the slave device. For example, when the slave device receives the retransmission request from the master device, the slave device may wait for a random delay, such as 20-100ms, while monitoring whether there is a device on the bus that will reply. According to at least one embodiment of the present disclosure, the random delay time period may be determined by a random method. For example, the slave device may calculate a random number based on its device serial number as a seed, and use the random number as the random delay time.

[0069] like Figure 5 As shown, the slave device monitoring whether there is a reply on the bus may include monitoring any received data packets to detect address conflicts. For example, the slave device may obtain the address field in the data packet by monitoring the data packet on the bus, and determine whether there is an address conflict based on whether the address indicated by the address field is the same as the device address of the slave device (for example, the device address is set by the master device for the slave device). For example, when the address indicated by the address field included in the data packet monitored by the slave device is the same as the device address of the slave device, the slave device may determine that there is an address conflict. Figure 5 As shown, when the slave device detects an address conflict in the random delay time period, the slave device can fall back to the reserved address. According to an embodiment of the present disclosure, the reserved address can be pre-configured by the master device to each slave device, or the reserved address can be a fixed address set by the master device, for example, address 247, etc.

[0070] like Figure 5 As shown, when the slave device does not detect an address conflict in the random delay period, the slave device can reply a response to the master device after the random delay period ends. After the slave device replies to the master device, if it is determined that the request is a unicast retransmission request, the slave device continues to monitor on the bus and detect address conflicts. When an address conflict is detected, the slave device falls back to the reserved address. According to at least one embodiment of the present disclosure, Figure 5 As shown, the slave device may continue to keep listening until any new request (e.g., a request sent to other devices) is received from the master device. Alternatively, according to at least one embodiment of the present disclosure, the slave device may continue to keep listening until a predetermined timeout period, for example, the predetermined timeout period may be pre-set by the master device, such as 1 second.

[0071] like Figure 5As shown, when the slave device determines that the request is not a unicast retransmission request, the slave device can send a reply response to the master device, and after sending the reply response, wait to receive any new request from the master device. Alternatively, according to at least one embodiment of the present disclosure, when the request is not a unicast retransmission request, the slave device can also monitor on the bus and detect address conflicts. For example, when the request is not a unicast retransmission request, the slave device can start from receiving the request from the master device and continue to monitor until a predetermined timeout period, and end the monitoring when the predetermined timeout period expires.

[0072] like Figure 5 As shown, according to at least one embodiment of the present disclosure, in the case where the request is a retransmission request, a random delay mechanism is provided for the reply of the slave device. Through this random delay mechanism, the reply time periods of potential slave devices with the same address can be staggered, creating a time window for monitoring, in which the slave device can detect address conflict failures that may occur on the bus.

[0073] like Figure 5 The random delay method shown does not require that the reply window period must be exactly staggered every time, but it can be said that in most cases, there will be one difference in three times. If each retransmission cannot be staggered, then the request detection fails this time and waits for the next detection opportunity requested by the master device. So it can be seen that this method uses a simplified detection mechanism to cover most scenarios. It does not require that every conflict can be detected immediately, but it can be correctly detected under multiple conflict opportunities.

[0074] According to at least one embodiment of the present disclosure, after a slave device detects an address conflict, the slave device may fall back to a reserved address, the master device may identify the address conflict by sending an error query command to the reserved address, and the master device may eliminate the address conflict by resetting the address of the slave device that falls back to the reserved address. Figure 6 and Figure 7 Describe the process of identifying and resolving address conflicts.

[0075] Figure 6 A flowchart of a master device for identifying and eliminating address conflicts in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown.

[0076] like Figure 6 As shown, the master device can pre-set a reserved address for the slave device. For example, according to an embodiment of the present disclosure, the reserved address can be pre-configured by the master device to each slave device or the reserved address can be a fixed address set by the master device, such as address 247.

[0077] According to at least one embodiment of the present disclosure, the master device can periodically query the reserved address during communication intervals to determine whether a slave device has fallen back to the reserved address, and obtain the error code, device information, fault information, etc. of the slave device, thereby identifying that an address conflict has occurred on the bus.

[0078] For example, Figure 6 As shown, the master device may send multiple error query commands for each slave device to a reserved address (e.g., 247), for example, each of the multiple error query commands may include a device serial number of a slave device. According to at least one of the present disclosures, the slave device that falls back to the reserved address may determine whether to reply to the master device based on whether the device serial number in the received error query command matches its device serial number, for example, if the slave device that falls back to the reserved address determines that the device serial number in the received error query command is the same as its device serial number, then the slave device that falls back to the reserved address sends a reply to the master device. According to at least one embodiment of the present disclosure, the master device may support the situation where multiple address conflicts exist at the same time by sending multiple error query commands for each slave device to the reserved address (e.g., 247). For example, when there are multiple address conflicts, there may be multiple slave devices with reserved addresses, and the master device may obtain a reply from each slave device that falls back to the reserved address by sending multiple error query commands for each slave device to the reserved address (e.g., 247), thereby identifying multiple address conflicts.

[0079] like Figure 6 As shown, if the master device receives a reply from the slave device during the process of sending an error query command to the reserved address, the master device can determine that an address conflict has been identified. For example, the reply received by the master device may include an error code, device information, and fault information of the slave device. Further, according to at least one embodiment of the present disclosure, the master device may configure a new address for the slave device that sent the reply based on the information in the received reply. For example, the master device may send a corresponding request to configure a new address for the slave device. For example, according to at least one embodiment of the present disclosure, the request may include the device serial number of the slave device that sent the reply. And, as Figure 6 As shown, the master device can also perform a read operation (or other types of operations) on the new address to confirm that the new address configuration is successful. For example, the master device can retrieve the current available addresses (excluding the addresses that have been used by the slave device), set the address of the slave device that has fallen back to the reserved address, and after receiving a successful response from the slave device, confirm whether the new address setting of the slave device is successful through a unicast request for the new address.

[0080] After confirming that the new address configuration is successful, the master device continues the error query command until the error query for each slave device is completed.

[0081] According to at least one embodiment of the present disclosure, Figure 6 As shown, if the master device does not receive a response from the slave device during the process of sending an error query command to the reserved address, the master device ends the query after completing the error query for each slave device.

[0082] It should be understood that the present disclosure does not limit the command (or request) for error query, for example, the command (or request) type defined by function code 125 or other agreed function codes in Modbus can be used. In addition, the present disclosure does not limit the command (or request) for setting a new address, for example, the command (or request) type defined by function code 16 or other agreed function codes in Modbus can be used.

[0083] Figure 7 A flowchart of a slave device for identifying and eliminating address conflicts in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown.

[0084] like Figure 7 As shown, after the slave device falls back to the reserved address, the slave device can set an error code and wait for an error query from the master device.

[0085] According to at least one embodiment of the present disclosure, Figure 7 As shown, the slave device can receive the error query command sent by the master device, and determine whether the device serial number included in the received error query command matches (e.g., is the same as) its device serial number. If the device serial number included in the error query command does not match its device serial number, the slave device can discard the error query command and continue to receive error query commands.

[0086] like Figure 7 As shown, if the slave device determines that the device serial number included in the error query command matches its device serial number, the slave device can send a reply to the master device. For example, the reply can include an error code, device information, and fault information. After sending the reply, according to at least one embodiment of the present disclosure, the slave device can receive a request from the master device to configure a new address at the reserved address. For example, the master device can send a corresponding request to configure a new address for the slave device. According to at least one embodiment of the present disclosure, the request can include the device serial number of the slave device that sent the reply. Figure 7 As shown, after receiving a request for configuring a new address, the slave device can determine whether the device serial number in the received request matches its own device serial number. If it matches, the slave device can configure the new address; otherwise, the slave device can discard the request and continue to receive requests from the master device for configuring a new address at the reserved address.

[0087] Furthermore, after the slave device is configured at the new address, it can receive a request (eg, a read request) from the master device at the new address and reply a response to the master device.

[0088] according to Figure 6 and Figure 7 The process shown can automatically identify the address conflict fault on the bus through the cooperation of the master and slave devices, and can self-recover, thereby improving the stability and intelligence of the system.

[0089] Fig. 8A and 8B A timing diagram of a method for address conflict identification in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown.

[0090] exist Fig. 8A and Figure 8B In the illustrated embodiment, it is assumed that there are N (N is an integer greater than or equal to 2) slave devices (slave device 1, slave device 2, ... slave device N) connected to the master device via the Modbus RTU bus, and the addresses of slave device K and slave device P conflict. It should be understood that Fig. 8A and Figure 8B The illustrated embodiments are merely examples, and the embodiments of the present disclosure are not limited thereto.

[0091] like Fig. 8A As shown in FIG. 1 , the request sent by the master device is received by the slave device K and the slave device P, and the slave device K and the slave device P both reply to the master device, and a response conflict occurs. After the response conflict occurs, the master device sends a retransmission request. According to at least one embodiment of the present disclosure, after receiving the retransmission request sent by the master device, the slave device K performs a random delay, for example, Fig. 8A As shown, the slave device K may randomly delay for 80 ms, and the slave device K may keep monitoring the bus during the random delay period.

[0092] Similarly, after receiving the retransmission request sent by the master device, the slave device P performs a random delay, such as Fig. 8A As shown, the slave device P can randomly delay by 20 ms, and the slave device P can keep listening to the bus during the random delay period.

[0093] Furthermore, after the random delay period expires, the slave device P can reply a response to the master device. Since the slave device K is still in the random delay period at this time, the slave device K can monitor the response replied by the slave device P, and the slave device K determines that the device address of the slave device P is the same as its own device address based on the address segment in the response data packet, thereby detecting an address conflict.

[0094] like Fig. 8AAs shown, after detecting an address conflict, the slave device K can fall back to a reserved address, such as 247. And after falling back to the reserved address, the slave device K can set an error code and wait for an error query from the master device.

[0095] exist Figure 8B In the case of a master device making an erroneous query on a reserved address. Figure 8B As shown, the master device sends multiple error query commands to the reserved address, wherein each error query command may include a device serial number of one of the N slave devices. For example, the first serial number corresponds to the device serial number of slave device 1, the second serial number corresponds to the device serial number of slave device 2, and so on, and the Kth serial number corresponds to the device serial number of slave device K.

[0096] The slave device K receives the error query command sent by the master device. According to at least one embodiment of the present disclosure, the slave device K can determine whether the sequence number included in the received error query command matches (e.g., is the same as) its own sequence number. If it does not match, the slave device K discards the error query command and continues to receive error query commands.

[0097] like Figure 8B As shown, when slave device K receives an error query command with a Kth sequence number, slave device K can determine that the Kth sequence number matches its own sequence number, so slave device K sends a reply to the master device, for example, the reply may include an error code, device information, and fault information, etc. The master device receives the reply sent by slave device K, thereby identifying an address conflict.

[0098] like Figure 8B As shown, after identifying the address conflict, the master device sends a request to the slave device K based on the reply from the slave device K to configure a new address for the slave device K. According to at least one embodiment of the present disclosure, the request for configuring the new address sent to the slave device K may include the device serial number of the slave device K. The slave device K may determine whether the device serial number included in the request matches its own device serial number. If so, the slave device K may send an address setting success confirmation response to the master device and apply the new address.

[0099] like Figure 8B As shown, after receiving the confirmation response, the master device can make a unicast request for the new address (for example, perform a read operation) to confirm whether the new address setting of the slave device K is successful.

[0100] Fig. 9 An apparatus for address conflict identification in a Modbus RTU bus according to at least one embodiment of the present disclosure is shown.

[0101] Fig. 9The illustrated apparatus may include a memory 910 and at least one processor 920 , wherein the at least one processor 920 is coupled to the memory 910 .

[0102] The memory 910 may store executable instructions, which, when executed by the processor 920 , at least partially implement the above-mentioned method for identifying and eliminating address conflicts on a Modbus RTU bus.

[0103] like Fig. 9 The at least one processor 920 shown may include, but is not limited to, a central processing unit (CPU), an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a system on a chip (SoC), a programmable or non-programmable logic device or array, a digital circuit, a microprocessor, an application specific integrated circuit (ASIC), etc. The at least one processor 920 may be configured to execute the above-mentioned method for identifying and eliminating address conflicts on a Modbus RTU bus.

[0104] Additionally, according to at least one embodiment of the present disclosure, after identifying an address conflict fault on the Modbus RTU bus using a method according to at least one embodiment of the present disclosure, security log records can be made on the master and slave devices, and early warnings can be issued through the UI interface and communication interface.

[0105] According to at least one embodiment of the present disclosure, a method for automatically identifying and eliminating address conflicts on a Modbus RTU bus is provided. The method can automatically diagnose address conflict faults through the cooperation of master and slave devices, and can self-recover without the need for manual troubleshooting of the fault cause and manual resetting of the address, thereby improving the stability and intelligence of the system. In addition, the method does not require modification of existing device hardware and Modbus RTU bus connections, only software and interfaces need to be updated, and there are no requirements for the UI interface and buttons of the slave device.

[0106] Various embodiments of the present disclosure may be implemented as computer-readable codes embodied on a computer-readable recording medium from a specific perspective. A computer-readable recording medium is any data storage device that can store data readable by a computer system. Examples of computer-readable recording media may include read-only memory (ROM), random access memory (RAM), compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, optical data storage device, carrier wave (e.g., data transmission via the Internet), and the like. Computer-readable recording media may be distributed via a computer system connected via a network, and therefore computer-readable codes may be stored and executed in a distributed manner. Moreover, the functional programs, codes, and code segments for implementing the various embodiments of the present disclosure may be easily interpreted by a technician in the field of the embodiments of the present disclosure.

[0107] It will be understood that the embodiments of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software. Software may be stored as program instructions or computer-readable codes executable on a processor on a non-transient computer-readable medium. Examples of non-transient computer-readable recording media include magnetic storage media (e.g., ROM, floppy disk, hard disk, etc.) and optical recording media (e.g., CD-ROM, digital video disk (DVD), etc.). Non-transient computer-readable recording media may also be distributed on network-coupled computer systems so that computer-readable codes are stored and executed in a distributed manner. The medium may be read by a computer, stored in a memory, and executed by a processor. Various embodiments may be implemented by a computer or a portable terminal including a controller and a memory, and the memory may be an example of a non-transient computer-readable recording medium suitable for storing (multiple) programs having instructions for implementing embodiments of the present disclosure. The present disclosure may be implemented by a program having a code for specifically implementing the apparatus and method described in the claims, the program being stored in a machine (or computer) readable storage medium. The program may be electronically carried on any medium, such as a communication signal transmitted via a wired or wireless connection, and the present disclosure suitably includes its equivalents.

[0108] The above description is only a specific implementation of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any technician familiar with the technical field can make various changes or substitutions within the technical scope disclosed in the present disclosure, and these changes or substitutions should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.

Claims

1. A method for identifying an address conflict on a bus, the method comprising: The first device sends a request to the second device through the bus, wherein the second device has a first address; After the second device receives the request from the first device, the second device monitors the bus to detect whether there is an address conflict; In case the address conflict is detected, the second device changes the address to a second address, wherein the second address is different from the first address; The address conflict is identified by querying the second address by the first device.

2. The method according to claim 1, wherein: After the second device receives the request from the first device on the bus, the second device determines whether the request is a retransmission request.

3. The method according to claim 2, wherein: The second device monitors the bus to detect whether there is an address conflict, including: In the case where it is determined that the request is the retransmission request, the second device monitors the bus within a first random time period to detect whether there is the address conflict; and The first random time period is determined based on a device serial number of the second device.

4. The method according to claim 3, further comprising: If the address conflict is not detected within the first random time period, the second device replies to the first device; and After the reply is completed, the second device listens on the bus to detect whether the address conflict exists until a new request is received from the first device or until a predetermined timeout period set by the first device.

5. The method according to claim 2, wherein: The second device monitors the bus to detect whether there is an address conflict, including: In the case where it is determined that the request is not the retransmission request, the second device monitors the bus to detect whether there is the address conflict until a predetermined timeout period set by the first device.

6. The method according to claim 1, wherein: The second device monitors the bus to detect whether there is an address conflict, including: The second device monitors a data packet on the bus to detect whether the data packet has the same address as the first address.

7. The method according to claim 1, wherein: The second address is preconfigured by the first device.

8. The method according to claim 1, wherein: The step of querying the second address by the first device to identify the address conflict includes: A plurality of query commands are sent by the first device to the second address, wherein each of the plurality of query commands includes a device serial number of one of a plurality of devices communicating with the first device via the bus.

9. The method according to claim 8, further comprising: In the case that there is a second device having the second address, the second device determines that the device serial number of the query command matches the device serial number of the second device; and Based on the determination, the second device sends device information and fault information to the first device.

10. The method according to claim 1, further comprising: After identifying the address conflict, the first device sets the address of the second device.

11. The method according to claim 10, wherein: The first device sets an address for the second device, including: The first device sends an address setting request, wherein the address setting request includes a device serial number of the second device; and The second device sends a response to the first device according to the device serial number in the address setting request.

12. The method according to claim 1, wherein: The bus is a Modbus Remote Terminal Unit RTU bus.

13. A system for address conflict identification on a bus, the system comprising: First device; a plurality of devices communicating with the first device via a bus, wherein the plurality of devices includes a second device; in: The first device sends a request to the second device via the bus, wherein the second device has a first address; After the second device receives the request from the first device, the second device monitors the bus to detect whether there is an address conflict; In case the address conflict is detected, the second device changes the address to a second address, wherein the second address is different from the first address; The first device queries the second address to identify the address conflict.

14. A device for identifying address conflicts on a bus, the device comprising: A memory storing executable instructions; At least one processor is coupled to the memory, wherein the at least one processor is configured to implement the method according to any one of claims 1-12 when executing the executable instructions.

15. A non-transitory computer-readable medium storing executable instructions, wherein: The executable instructions, when executed by a processor, cause the processor to implement the method according to any one of claims 1-12.

Images