Modbus protocol broadcast address

Puzzle-solving class: Why did the new sensor “lose connection”? Maybe its "ID card" has been modified

In our daily technical support, we often encounter such a confusing scene: the customer received a new turbidity sensor and excitedly connected the software, only to find that the device was "silent" and unable to communicate. The first reaction of customers is often: "Is this new device broken?" After our in-depth investigation, we found that in most cases it is not a device failure, but a very simple reason - the Modbus communication address (ID) of the sensor has been modified. Today, let’s talk about this “identity recognition” issue.

In our daily technical support, we often encounter such a confusing scene: the customer received a new turbidity sensor and excitedly connected the software, only to find that the device was "silent" and unable to communicate. The first reaction of customers is often: "Is this new device broken?" After our in-depth investigation, we found that in most cases it is not a device failure, but a very simple reason - the Modbus communication address (ID) of the sensor has been modified. Today, let’s talk about this “identity recognition” issue.

1. Understanding Modbus ID: the “device ID card” in the network

Imagine being in a classroom and the teacher wants to ask students to answer questions by calling them by name. Each student has a unique student ID number. If the teacher calls "Student No. 3", the student with student number 3 will stand up and respond.

In a Modbus network, the principle is exactly the same:

• The host (your software) is like the teacher.
• Slaves (our sensors) are like students in a classroom.
• Modbus ID is the student ID of each device, usually ranging from 1-247.

Please note: The factory default ID of our [turbidity sensor] is [3]. This means that the sensor will only respond when your software issues the command "Device with ID 3, please answer".

2. Question scene: Why no one answered the "roll call"?

So why doesn't a new sensor respond to the roll call of "No. 3"? The most common reasons are:

• Intentional modification: In order to connect multiple sensors to the same bus and avoid conflicts, the customer took the initiative to modify the IDs of some of them, but later forgot about them.
• Unintentional modification: While debugging other devices, an instruction to modify the ID was mistakenly sent to our sensor.
• Historical legacy: This sensor has been used by other projects, and the ID has been modified without the current user's knowledge.

The result is: when you call it with the default ID 03, it has "changed its name" and will naturally not answer. Communication failure also occurs.

3. Solution: Use the "broadcast" function to retrieve the device identity

What should you do when you suspect that the sensor ID has been modified but don’t know what it has been changed to? The Modbus protocol provides a very practical tool - broadcast address.

What is a broadcast address? The broadcast address is 0 (hex 0x00). When the host sends a command to address 0, all slave devices on the network will receive the command, but will not reply. It's like the teacher shouting in the classroom: "Everyone, listen to my instructions!" Everyone will execute it, but no one will stand up to answer alone, thus avoiding data conflicts.

How can we use broadcast to retrieve our sensor ID?

Our sensor has a dedicated register that stores its current Modbus ID. You can force all devices to "reveal" their identity by broadcasting a command.

Key information (taking remote sensing turbidity sensor as an example):

• Modbus ID register address: 0x0001
• Register length: 1 (i.e. 2 bytes)
• Data type: UINT16 (unsigned 16-bit integer)
• Allowed range: 1 – 247

Operation steps:

• Construct a broadcast read instruction: Use function code 03 (read holding register) to read the value at address 0x0001. Field Broadcast address Function code Starting address high bit Starting address low bit Number of registers high bit Number of registers low bit CRC check Value 00 03 00 01 00 01 84 0A Explanation Call to everyone Read data The register address to be read is 0x0001 1 register to be read Check code Complete example command (hexadecimal): 00 03 00 01 00 01 84 0A

Complete example command (hex): 00 03 00 01 00 01 84 0A

• Send and listen for responses: Response example for successful communication (assuming the sensor's current ID is 5): 05 03 02 00 05 F9 C9 05: This is the sensor's current Modbus ID! 03: Function code 02: Number of bytes returned 00 05: Value of register 0x0001, that is, 5 (hexadecimal 0x0005) F9 C9: CRC check code

Response example for successful communication (assuming the sensor's current ID is 5): 05 03 02 00 05 F9 C9

• 05 : This is the current Modbus ID of the sensor!
• 03: Function code
• 02: Number of bytes returned
• 00 05: The value of register 0x0001, which is 5 (hexadecimal 0x0005)
• F9 C9: CRC check code

Congratulations! You have successfully recovered the identity of this "lost" sensor.

4. Important tips and follow-up operations

• Safety first: When using broadcast instructions, please ensure that there are no other devices on the bus that are performing critical tasks, because broadcast instructions will be executed by all devices.
• Modify back to default value: Once you have retrieved the device's ID, you can use function code 10 (hex 0x10, write multiple registers) to write the value 3 to the starting address 0x0001 to restore its ID to the factory default settings. Example command (change the ID of the device with current ID 5 back to 3): 05 10 00 01 00 01 02 00 03 <CRC> 05: Current address of the sensor (take 5 as an example here) 10: Function code (write multiple registers) 00 01: Starting register address (0x0001, which is the ID storage address) 00 01: The number of registers to be written (1) 02: The number of bytes to be sent next (2 bytes) 00 03: The data to be written (hexadecimal value 0x0003, that is, decimal 3) <CRC>: CRC check code (needs to be calculated according to the specific instruction) A calculated complete instruction example (change address 5 to 3): 05 10 00 01 00 01 02 00 03 The 37 8F sensor will reply with a confirmation message, usually in the format: 05 10 00 01 00 01 12 98 (the CRC of the reply is 12 98), indicating that the writing is successful. After that, the sensor's address changes back to 3, and you need to use the new address 3 to continue communicating with it.
• Example command (change the ID of the device with current ID 5 back to 3): 05 10 00 01 00 01 02 00 03 <CRC> 05: Current address of the sensor (take 5 as an example here) 10: Function code (write multiple registers) 00 01: Starting register address (0x0001, which is the ID storage address) 00 01: Number of registers to be written (1) 02: Number of bytes to be sent next (2 bytes) 00 03: Data to be written (hexadecimal value 0x0003, i.e. decimal 3) <CRC>: CRC check code (needs to be calculated according to specific instructions)
• 05: Current address of the sensor (take 5 as an example here)
• 10: Function code (write multiple registers)
• 00 01: Starting register address (0x0001, ID storage address)
• 00 01: Number of registers to be written (1)
• 02: Number of bytes to be sent next (2 bytes)
• 00 03: Data to be written (hex value 0x0003, i.e. decimal 3)
• <CRC>: CRC check code (needs to be calculated according to specific instructions)

An example of a calculated complete instruction (change address 5 to 3): 05 10 00 01 00 01 02 00 03 37 8F

The sensor will reply with a confirmation message, usually in the format: 05 10 00 01 00 01 12 98 (the CRC of the reply is 12 98), indicating that the writing is successful. After that, the sensor's address changes back to 3, and you need to use the new address 3 to continue communicating with it.

• Make good records: It is recommended to record the modified ID with a label on the sensor body or manual to avoid "lost contact" again.

Conclusion

Communication connection problems often stem from these basic "identity" and "rules" settings. We hope this popular science article can help you understand the importance of Modbus ID and master practical tips for quickly retrieving device identity.

As your reliable partner, YuanGan Technology not only provides high-performance, high-stability sensor products, but is also committed to empowering every user through knowledge sharing, making the data collection journey smoother.

—— YuanGan Technology, explore the world of accurate data with you