Question about ModBus slave addresses

Hello! The ModBus spec papers sometimes don't clearly define things or don't define at all. We came to a point where we are not sure about the slave address handling. Perhaps someone from here can help.

ModBus is a protocol that can be used over many different lines. We only use USB or Ethernet, so our slave device has a point-to-point connection and the slave address doesn't matter and thus they all use the same. For a specific reason we restricted the use of the address in byte 0 of a ModBus RTU message to 0 and 1. Slave address 0 seems to be a no-go, though the spec only defines this for serial line as "it can't be zero". But how to deal with illegal addresses? That's why I have some questions:

ModBus RTU:
When a slave supports to put either 0 or 1 into the slave address byte, how it's supposed to react when there is a 2 or higher in the message? Shall it not react at all or shall it reply with an error message? If error message, what code? We couldn't find a suitable one.

ModBus TCP:
The unit identifier in the MBAP header, is it mandatory to accept any number between 0 and 255 or not? Since our slave is point-to-point only, it won't be addressed by that identifier, so it will ignore. In the same way we only accept to put 0 or 1 as address with RTU, we also defined to accept only 0 and 1 as identifier with TCP, just for the case that any ready-to-use ModBus library or software on the market would automatically put a 1 into that byte.

Thanks in advance.
 
Modbus RTU slave address 0 is reserved for broadcasts. If a slave receives a message targeted at address 0, it should process it, but not respond (since you don't want all slaves responding at the same time, causing bus contention). A master can send a write command to slave address 0 and all slaves on the bus should receive the command and set their corresponding registers/coils to the value sent by the master.

If a Modbus RTU slave receives a message targeted at an address other than its own, it should simply discard the packet (it must not send any type of error response, as the message was not intended for that device and responding with an error could cause bus contention when the slave that is actually targeted responds).

For Modbus/TCP, the Unit Identifier is really only useful for devices like routers or modular devices that consist of several "logical devices". For example, a Modbus/TCP to Modbus RTU router would use the Unit Identifier from the Modbus/TCP packet as the slave address in the Modbus RTU packet. As another example, a modular Modbus/TCP device may have multiple slots, each supporting an I/O card. Each slot could corresponding to a different Unit Identifier such that the registers are identical on each I/O card, just accessed using a different Unit Identifier.

For other Modbus/TCP devices, it is quite common to ignore the Unit Identifier and accept any Unit Identifier (echoing back the unit identifier received in the response). Other implementations accept only a specific Unit Identifier, such as 0, 1, or 255. I recommend simply ignoring the Unit Identifier and echoing it back in the response.

No matter how you choose to implement this, just make sure you document it in your product's user manual or other documentation.
 
We are aware of the topic with the 0. However, broadcast only exists with serial line. We don't use it, so our devices will never be connected to a gateway from USB/Ethernet to RS485.
The UID with ModBus TCP would, according to our own definitions, have to support 0 or 1, so should the end user have such a ModBus router which converts, let's say, from ModBus TCP to USB, the 0 or 1 gets copied to byte 0.
 
Yes, the concept of broadcast only exists with serial line and Modbus RTU. However, I assume when you mention USB, this would be a USB Virtual COM port, so it is emulating a serial connection and using Modbus RTU. Therefore, it's possible that a a Modbus master connected to your product via USB (perhaps through a USB to serial adapter?) could support sending broadcast messages on the serial line, and your product should be able to handle that.

On a related note, if this is the case, it is odd to have a slave device support only USB for Modbus RTU. The standard physical layer for Modbus RTU is RS-485. You would need to use an adapter with almost any Modbus master, unless it's always going to be a PC. But without knowing any details on your intended application, I can only provide general comments.

To address your other comment, yes if a user is using a Modbus/TCP to Modbus RTU over USB router (which again, I'm unsure if this even exists) the router would convert the Modbus/TCP Unit Identifier field to/from the Modbus RTU slave address field (byte 0).
 
"Serial line" here means a bus like RS485 where it's required to use addresses to distinguish target devices. USB is actually not a bus and it only uses serial communication and like RS232 it's point to point, so no address needed. Two systems that contradict about the need of an address. That's exactly the point where the ModBus spec paper "ModBus Application Protocol" freaks us out because it doesn't say that a slave shall not be have address 0. Due to that it was the easiest to use 0 for all units.
 
The concept of an Address is at the protocol level (Modbus RTU). The physical layer that the protocol is running on (USB, TTL, RS-232, RS-485, radio, etc.) has no concept of an address. Yes, there are physical layers that are inherently point-to-point (USB, TTL, RS-232) or multi-drop (RS-485), but the physical layer simply defines the signaling of each bit on the bus. Since you are using Modbus RTU at the protocol level, you have a slave address and must use it.

The use of address 0 for broadcasts is clearly explained in the spec (MODBUS over serial line specification and implementation guide V1.02) on page 7.
https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

In broadcast mode, the master can send a request to all slaves.
No response is returned to broadcast requests sent by the master. The broadcast requests are necessarily writing commands. All
devices must accept the broadcast for writing function
. The address 0 is reserved to identify a broadcast exchange.
 
I contradict. The address is used by a slave to listen and accept a message or not. Same as with an IP. In point-to-point only one slave will get the message and thus it would accept without checking if the message is for itself.

Again, because I already has a thread about this topic 2 years ago: there are two definitions for ModBus protocol, the one titled "ModBus over serial line" and the other titled "ModBus Application Protocol". We don't use serial line, so we stuck to the other. The other doesn't mention slave address use.

And last but not least: there is no broadcast in terms of ModBus over USB or Ethernet. So if you design a ModBus slave that isn't meant for bus use, i. e. serial line, you would of course not adhere this extra spec.
 
You're entitled to believe what you wish, but all I have done is presented you with the facts. Please remember, I am donating my valuable time to this forum and providing free engineering consultation to you for your product. I am not here to argue about semantics of serial or Ethernet communication and convince you that my statements are indeed factual.

I don't know what your intended meaning of "Modbus over USB" is, because there is no version of the Modbus protocol defined in the spec that is "Modbus USB". The most common use of USB is with serial protocols (such as Modbus RTU), where the USB connection is a virtual serial port. The only other use of USB for Modbus I can think of is a USB to Ethernet (USB LAN) adapter. In that case, since the network would be Ethernet, the protocol would be Modbus/TCP and your device or a computer is simply using the USB to Ethernet adapter to connect to the Ethernet network.
 
I hate this world. Every time, literally every time you only speak your mind it's considered as argument. Why? Am I not allowed to have my own opinion, my own understanding? I didn't even say you're wrong. I liked your posts. What else do you need? Do I have to fall on my knees and admire you? Geez, calm down. This is a discussion forum. We discuss here. Controversial sometimes, yes.

ModBus is a message protocol, nothing else. It's not a hardware or bus specification, though it has "Bus" in the name. You can transmit ModBus messages over any hardware communication line you can think of. Even stream it over Ethernet in small or large packets. What do you see in it? So today, by far most users use Ethernet, USB or RS232, though RS232 is dying like GPIB. All three are point to point. With point to point there is no need for addressing a slave by a slave address. The slave is addressed by the port used to communicate. Of course I cannot be sure, but that's most likely the reason why the people who invented the protocol, made three different types and four different specification papers for it. Only the one dealing with "serial line", i. e. bus use, speaks of a slave address and things like broadcast. How is anyone supposed to know that this extra "serial line" paper is mandatory to follow when making a ModBus compatible product? The confusing is started by the makers, not the users.

But thanks, I got my answers. We need to discuss it internally in our company, but different people have different opinions. I follow the consideration that messages/frames with the wrong ID shall be discarded, our programmer has a different sight.
 
Top