How to: slave addressing

Hello!

I just finished reading "MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b3" and "MODBUS over Serial Line Specification and Implementation Guide V1.02". I was expecting to find something about my question, but I didn't.

I intend to build a system that has a client and several Modbus RTU servers on the same network.
Each of the servers would leave the production line with a fixed address (I'm not talking about data addressing).
How this could be handled by the client (several servers with the same address on the network)?

I couldn't find anything in the docs about this. Is there a common approach? Where can I read more about this?

A solution would be to use a dip switch in each server. This solution isn't ideal because the addressment is manual and it increases production costs.
Is there some way I could do this using Modbus (and still respect all protocol rules)?

Thanks!
 
If I understand correctly, you're designing the entire system (both the client and servers), and all servers leave the production line with the same fixed device address (say address 1 for example).

To my knowledge, there is no common approach to automatically set device addresses of Modbus servers. In most applications, this would not be beneficial anyway, since the client (and end user) needs to know which specific device it's writing/reading data to/from. For example, if you need to run a VFD (Modbus server) to control a fan in a specific room, you need to know the Modbus device address of the VFD, so you know which fan you're controlling. Every Modbus server device I've ever encountered has some way to set the device address, whether it be dip switches, a software utility, setting parameters from a keypad, or writing configuration registers over Modbus.

If your application does not need to uniquely interact with a specific Modbus server device, then it might work to automatically assign device addresses. Modbus allows User-Defined Function Codes (in the ranges 65 - 72 and 100 - 110). You could create a new function code (or multiple function codes) on both your client and server where you could implement some method of dynamically assigning a device address to each server. However, you would need to ensure that, since all server devices initially have the same device address, they do not all respond at the same time to the client's request. Modbus RTU does allow broadcast messages by targeting device address 0, where the server devices shall not respond. You may be able to use a combination of these two features to implement the behavior you're looking for.
 
Thanks for your reply @jschulze!

If I understand correctly, you're designing the entire system (both the client and servers), and all servers leave the production line with the same fixed device address (say address 1 for example).
Correct!
To my knowledge, there is no common approach to automatically set device addresses of Modbus servers. In most applications, this would not be beneficial anyway, since the client (and end user) needs to know which specific device it's writing/reading data to/from. For example, if you need to run a VFD (Modbus server) to control a fan in a specific room, you need to know the Modbus device address of the VFD, so you know which fan you're controlling. Every Modbus server device I've ever encountered has some way to set the device address, whether it be dip switches, a software utility, setting parameters from a keypad, or writing configuration registers over Modbus.
Since both the client and masters will be developed, I was trying to make the addressment to be the most transparent as possible to the end user.
If your application does not need to uniquely interact with a specific Modbus server device, then it might work to automatically assign device addresses. Modbus allows User-Defined Function Codes (in the ranges 65 - 72 and 100 - 110). You could create a new function code (or multiple function codes) on both your client and server where you could implement some method of dynamically assigning a device address to each server. However, you would need to ensure that, since all server devices initially have the same device address, they do not all respond at the same time to the client's request. Modbus RTU does allow broadcast messages by targeting device address 0, where the server devices shall not respond. You may be able to use a combination of these two features to implement the behavior you're looking for.
That's exactly what I'm looking for. I'm still thinking about the best way to do it.

Another way I found, is to use a particular hardware connection on the servers. By using a daisy-chain connecting the servers and the ability to them to cut their transmission line, I can "break" the bus. And by this, have only a single unaddressed server on the bus, making it easy to address all the servers. More info here. I'm not developing the hardware of the servers, so this is not my decision alone.

I'm still searching for the best decision.
 
Can you share the details of your application? I'm quite curious regarding what your devices are and what they do, since my colleagues and I cannot devise a real-world scenario where there would be no need to uniquely target individual devices.

Along these lines, we did think of one scenario where addressing does not matter. This would be an open-loop, bulk command-only application where all devices on the network are commanded with the same command (i.e. turn all fans on, turn all fans off, etc.). This scenario actually does not require device addressing at all, since all commands would be write requests targeted at the broadcast address of 0. Because, in this case, the master would never send a read request (and slaves don't respond to broadcast writes) it would not matter that all slaves have the same device address.
 
Can you share the details of your application? I'm quite curious regarding what your devices are and what they do, since my colleagues and I cannot devise a real-world scenario where there would be no need to uniquely target individual devices.
It's nothing special. A bunch of different sensors in a Modbus RTU network. The idea is that the client choses the server by its type. Each sensor server has a different type, returned by Modbus. There is a lot to study about it yet. Of course, address will matter for the system, but not for the client.
 
Thank you for the details. So the sensor type is always unique? There's no scenario where two of the same sensor type would be installed on the same Modbus network?

If that's the case, could you just enumerate all of the sensor types and each server's Modbus device address could be hard-coded to the sensor type number? The client would then attempt to read all server addresses (sensor types).

For example, say there are 10 different sensor types and you number them 1 - 10. Each sensor's Modbus device address would be its sensor type, so the devices would be at addresses 1 - 10. The client would always attempt to read registers from all devices (1 - 10).

If, on the other hand, there is a possibility of having two or more of the same sensor type on the same Modbus network, then you will need some way of uniquely distinguishing between the two sensors. The most common way of doing this is having the installer set a Modbus device address on the sensor (via dip switches, etc.).
 
Thank you for the details. So the sensor type is always unique? There's no scenario where two of the same sensor type would be installed on the same Modbus network?

If that's the case, could you just enumerate all of the sensor types and each server's Modbus device address could be hard-coded to the sensor type number? The client would then attempt to read all server addresses (sensor types).

For example, say there are 10 different sensor types and you number them 1 - 10. Each sensor's Modbus device address would be its sensor type, so the devices would be at addresses 1 - 10. The client would always attempt to read registers from all devices (1 - 10).

If, on the other hand, there is a possibility of having two or more of the same sensor type on the same Modbus network, then you will need some way of uniquely distinguishing between the two sensors. The most common way of doing this is having the installer set a Modbus device address on the sensor (via dip switches, etc.).
It will be possible to have more than one sensor of each type in the network.
I do prefer to use the approach I posted above (using the daisy-chain) over dip switches. They both impact of hardware, but using dip switches a manual action need to be performed by the installer. I'm pending for the daisy-chain solution.
 
I understand. I just want to make sure you've considered the point I'm trying to make.

If it is possible to have more than one sensor of the same type on the same network, how does the end user tell them apart? For example, if one sensor is giving an errant reading, how does the customer know which sensor has the issue? Do the sensors have some other unique ID that is accessible to the end user?

The dynamic daisy-chain approach you provided a link to is an interesting and novel approach. However, I get the feeling that this is more of a college/university proof-of-concept project, rather than a real-world-tested solution. While I have no doubts the solution would work, there are some concerns that need to be considered. The first, of course, is the added hardware cost of needing to have two separate RS-485 terminals on the server devices (an upstream and a downstream) and some type of relay to dynamically connect/disconnect the ports together. The second concern is troubleshooting. If a downstream device is no longer communicating, you now have additional points of failures: the relay hardware could be damaged or malfunctioning in an upstream device, the device may have been put into configuration mode by mistake, etc.
 
If it is possible to have more than one sensor of the same type on the same network, how does the end user tell them apart? For example, if one sensor is giving an errant reading, how does the customer know which sensor has the issue? Do the sensors have some other unique ID that is accessible to the end user?
I'm still thinking about this. Probably the user will assign indexes to each sensor through blinking an LED on the sensor. Something like this.
The dynamic daisy-chain approach you provided a link to is an interesting and novel approach. However, I get the feeling that this is more of a college/university proof-of-concept project, rather than a real-world-tested solution. While I have no doubts the solution would work, there are some concerns that need to be considered. The first, of course, is the added hardware cost of needing to have two separate RS-485 terminals on the server devices (an upstream and a downstream) and some type of relay to dynamically connect/disconnect the ports together. The second concern is troubleshooting. If a downstream device is no longer communicating, you now have additional points of failures: the relay hardware could be damaged or malfunctioning in an upstream device, the device may have been put into configuration mode by mistake, etc.
To the software/firmware point of view, this approach is perfect. But is has his down sides, for sure. But now you made me think that this serially flow of data can have catastrofic failures. I just don't want to implement something in the software that I don't like. Like random retransmission times in the servers (I already worked in a project that used this, but not in Modbus). I'll try harder to find a solution based on Modbus frames.
And man... Thanks for the help! Really!
 
You're very welcome. I understand how development goes, and it certainly always helps to get a different viewpoint on things. I hope that my feedback and opinions are helpful.

Probably the user will assign indexes to each sensor through blinking an LED on the sensor. Something like this.
I wanted to add my thoughts on this for your consideration. This certainly is a good idea and would work, but is this really easier for the end user than just having DIP switches? Is there any concern that this method may require two people to perform - one to initiate the LED blinking and another to look at all installed sensors of that type to find the problematic sensor?

If, instead, the user had manually assigned addresses using DIP switches, they would have been able to keep a record of the physical location of each address, so they would know exactly which sensor is having the issue immediately, instead of having to go look at all of the sensors of that type.

I'm not saying that you should use DIP switches, but I recommend that you compare the pros and cons of each approach to determine if it's really worth the extra effort to eliminate them and perform automatic addressing.
 
Top