METHOD FOR RESOLVING AN ADDRESS CONFLICT FOR MODBUS RTU STANDARD PROTOCOL

Abstract

The invention relates to a method for a master-slave communication using the Modbus RTU (Modbus Remote Terminal Unit) standard protocol for resolving an address conflict based on identically set device addresses and for identifying a device connected to the Modbus having a device identification. The addressed device is uniquely identified by means of its device identification, which is transmitted by the request, and a new device address is being transmitted to this uniquely identified device by means of the sent request. The fundamental concept of the present invention is advantageously based on using only the standard way of communication, meaning the standardized master-slave communication, for the assignment of a unique device address on the bus and on using the inherently existing device identification, such as the serial number (see below), for uniquely identifying a device.

Claims

1. A method for a master-slave communication using the Modbus RTU standard protocol for resolving an address conflict based on identically set device addresses and for identifying a device connected to the Modbus having a device identification, comprising the following steps: sending a request comprising an address field for the device address, a field for a function code, a data field and a CRC check field from the master, wherein a starting register address for a starting register and a register number, which define a register area of registers directly succeeding each other starting from the starting register address, are indicated in the data field, wherein the device addressed by the device address indicated in the address field is uniquely identified by means of the device identification, which is transmitted by the request, and a new device address is transmitted to this uniquely identified device by means of the sent request.

2. The method according to claim 1, wherein the request comprises the Modbus RTU function code 0x10 for writing registers as a function code, the request comprises the device identification as a register content of the defined register area in the data field, the request comprises the new device address as an additional register content of the defined register area in the data field, and the device, of which the device address matches the device address indicated in the address field and of which the device identification matches the device identification, which is transmitted as a register content, takes over the device address as a new device address, said device address being transmitted as an additional register content.

3. The method according to claim 2, wherein a starting register content is defined as a selector, of which the selector value sets the function and processing of register contents of the defined register area, wherein the takeover of the new device address as a function to be performed in the identified device is assigned to a specified selector value.

4. The method according to claim 3, wherein the defined register area comprises the starting register having the selector value, N registers for the device identification and a register having the new device address to be assigned.

5. The method according to claim 1, wherein the device identification is a serial number.

6. The method according to claim 1, wherein each device addressed by the device address indicated in the address field replies to a request of the master for reading the device identification with a random delay time.

7. The method according to claim 6, wherein the random delay time as a multiple of a time slot duration is specified in such a manner that the replies of the devices occur without overlapping and in line with Modbus RTU.

8. The method according to claim 7, wherein the minimum time slot duration is specified in accordance with the N registers, which are occupied by the device identification.

9. The method according to claim 6, wherein in case the reply to the request for reading the device identification is received without a CRC error, the device address is assigned according to claims 1 to 5.

10. The method according to claim 6, wherein sending the request for reading the device identification and assigning a device address is executed in a cyclically repeated manner until a CRC error no longer occurs in the replies of the devices.

11. The method according to claim 3, wherein an additional selector value is provided, which, as a function to be performed, causes a signal display on the device identified by means of the device identification.

Description

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0045] Further advantageous embodiments can be derived from the following description and the drawings, which illustrate a preferred exemplary embodiment of the invention.

[0046] In the figures:

[0047] FIG. 1 a flowchart for a master-slave communication according to Modbus RTU standard protocol,

[0048] FIG. 2 structure and contents of a request for solving an address conflict according to the invention,

[0049] FIG. 3 a flowchart for resolving an address conflict according to the invention,

[0050] FIG. 4 structure and contents of a request for reading the device identification and

[0051] FIG. 5 a flowchart for reading the device identification, the reply having a random delay time.

DETAILED DESCRIPTION

[0052] FIG. 1 illustrates a flowchart for a master-slave communication according to Modbus RTU standard protocol. The Modbus RTU standard protocol is based on a bus structure, in which all communication between a master and the devices connected to the bus (slaves) is controlled by the master. The master sends a request 2 to a specific device address, wherein only the device having this device address sends a reply 4 back to the master. A broadcast request 6, which is sent to all connected devices without expecting a reply is in this case regarded as an exception. If a device address was assigned multiple times, multiple devices reply simultaneously and the master detects a transmission error (CRC error).

[0053] FIG. 2 illustrates the structure of a request according to Modbus RTU specification having a data assignment according to the invention for resolving an address conflict.

[0054] Besides the device address (slave address) of the device to be addressed, the request comprises the function code 0x10 (write multiple registers) which causes a writing of multiple registers in the address device. The data field comprises the information of a starting register, the number of registers or bytes, which the data filed comprises, and the contents of the registers, which are transmitted in the data field. Two bytes for CRC error detection form the end of the request.

[0055] The structure and content of a request are exemplary displayed having the following content:

[0056] Register assignment:

[0057] Register 5000 selector value

[0058] Register 5001/5002 serial number

[0059] Register 5003 new device address

[0060] This results in the Modbus RTU request for

[0061] Address: 0x64 address said to be assigned multiple times

[0062] Function code: 0x10 write multiple registers

[0063] Starting register: 0x1388 example: starting register 5000(=0x1388)

[0064] No. of registers: 4

[0065] No. of bytes: 8

[0066] Value 1.register: 0x0000 value register 5000, selector value 0000

[0067] Value 2.register: 0x1234 high-word of the serial number

[0068] Value 3.register: 0x5678 low-word of the serial number

[0069] Value 4.register: 0x50 new device address 80(=0x50)

[0070] All devices react to this request with the address 100 (0x64), but only the device with the device identification (serial number) 0x12345678 changes its device address to the new device address 80 (0x50).

[0071] FIG. 3 illustrates the corresponding flow for solving the address conflict according to the invention in a flowchart.

[0072] FIG. 4 illustrates the structure and content of a request for reading the device identification.

[0073] Reading the device identification in this case occurs according to Modbus RTU specification having the function code 0x03. The request and the reply of the device are in this case constructed as follows:

[0074] Register assignment: register 5001, 5002 serial number 0x12345678

[0075] Modbus RTU master request:

TABLE-US-00001 Address: 0x64 address said to be assigned multiple times Function code: 0x03 read multiple registers Starting register: 0x1389 example: starting register 5001 (= 0x1389) No. of registers: 2

[0076] Modbus RTU slave response:

[0077] Device (slave) determines a random time slot 0 . . . 19, e.g. 10

[0078] Device waits 1015 ms=150 ms and then sends:

[0079] Address: 0x64

[0080] Function code: 0x03

[0081] Register content 1: 0x1234 (high-word own serial number)

[0082] Register content 2: 0x5678 (low-word own serial number)

[0083] FIG. 5 illustrates a flowchart for reading the device identification, the reply having a random delay time.

[0084] It is illustrated how two devices having an identical device address but different device identifications reply to a request of the master for reading the device identification. It can initially be seen that both devices reply to the request of the master because they have the same addressed device address, however, they reply in different time slots. For the replies to be sent without overlapping and for no error message to occur, each device calculates an own random delay time for sending the respective reply.

[0085] The method for the assignment of a device address can therefore be repeatedly executed multiple times due to a further differentiation of a device by means of the unique device identification, resulting in all devices receiving a unique device address as bus users.

[0086] Despite an identical device address and an initially unknown device identification of the connected devices, this unique identification for each device can, however, be detected and the address conflict can subsequently be solved by addressing a new device address.

[0087] The method according to the invention is solely based on the standardized provided bus communication and refrains from using any additional auxiliary devices such as hardware for address setting (DIP switch, RFID, NFC, etc.) or additional signaling cables and is therefore particularly suitable for communication with devices such as sensors which are installed in an inaccessible manner.