Is it true that the Modbus RTU protocol is designed for one master to communicate with multiple slaves?
If a microcontroller only has a single UART and must communicate with two distinct Modbus devices via the RS485 protocol, I understand that each Modbus device have a unique address.

It's theoretically question, Could you help me in understanding how the single master can connect with the two separate slave devices?

 

Is it true that the Modbus RTU protocol is designed for one master to communicate with multiple slaves?
If a microcontroller only has a single UART and must communicate with two distinct Modbus devices via the RS485 protocol, I understand that each Modbus device have a unique address.

It's theoretically question, Could you help me in understanding how the single master can connect with the two separate slave devices?"

Because RS485 is a multidrop bus, there can be up to 32 devices on the bus, and each of them can be either master or slave. Each one can communicate with any (or all) of the others.
There is a pretty good explanation on Wikipedia as to how the transaction takes place.

 

Is it true that the Modbus RTU protocol is designed for one master to communicate with multiple slaves?
If a microcontroller only has a single UART and must communicate with two distinct Modbus devices via the RS485 protocol, I understand that each Modbus device have a unique address.

It's theoretically question, Could you help me in understanding how the single master can connect with the two separate slave devices?"

All three devices are connected to the common RS-485 bus. Now it is true that everybody on the bus can "hear" the transmitter, and you have to provide a mechanism to decide who is allowed to "talk". That is what Modbus RTU actually does.

 

It's easy. In a Modbus system, every transaction is initiated by the master, and when it starts a new exchange, it specifies the address of the slave which it wants to accept data or to send a response.

If you really wanted to make an RS485 system work as Ian0 said, where "each of them can be either master or slave. Each one can communicate with any (or all) of the others" it would be much more complicated, because there would have to be a mechanism to decide which unit has the authority to be "master" and start a new transaction. You can't allow a situation where two or more units each start transmitting at once.

 

I am attaching a diagram for more clarity. In this setup, there are three devices, each connected with a TTL to RS485 converter. I would appreciate your help in understanding how these devices should be connected on the Modbus network.

 

I am attaching a diagram for more clarity. In this setup, there are three devices, each connected with a TTL to RS485 converter. I would appreciate your help in understanding how these devices should be connected on the Modbus network.

View attachment 313698

Assuming a SN75176 TTL-RS485 device. . .
https://www.ti.com/lit/ds/symlink/sn75176a.pdf
RXD from the processor goes to R on the 75176
TXD from the processor goes to D on the 75176
You need a third connection from the processor to DE and RE (which are connected together)
The third connection sets the direction - i.e whether it receives or transmits.
Your UART may (or may not) have an output that controls the direction. Look in the manual to see if your UART has an RS485 mode.
Then connect all the A terminals together and connect all the B terminals together.
Install a 120Ω termination resistor at each end of the line (you might manage without these for low baud rates, but for anything above about 20kbaud they will be required).
Makes sure that the grounds at all three nodes are somewhere near earth (within a few volts)

 

I am attaching a diagram for more clarity. In this setup, there are three devices, each connected with a TTL to RS485 converter. I would appreciate your help in understanding how these devices should be connected on the Modbus network.

This is all well documented in many places.

https://www.ti.com/lit/an/slla272d/slla272d.pdf

 

master has list of slaves and data related to each of them, including "name" (node address or macid), functionality and capability of each slave etc. macid or node address is just that - a unique number assigned to each of the slaves (if two or more slaves have same macid, there will be crosstalk with slaves responding at the same time)

then master works its way through the list and calls each of the slaves issuing commands.
called slave responds
and the cycle repeats ad nauseum...

the whole idea is on simple way of exchanging data between nodes. role "master" or "salve" is assigned. master initiates all communication and slaves only respond when spoken to. slaves cannot talk to each other but master can get data from one slave and send it to another slave.

this works well, it is simple and robust. there are special situations where more than one master can exist. normally this is done when it need to be ensured that system has high availability (does not stop), even if master has failed. then another node (standby master) can take over. such systems are obviously using more advanced strategy but underlying principle is still based on simple network as stated before.