Hello community!

I need a big help with a problemn than i think the most alright have experienced this too.

My problemn actually is, how i solve the latency when i have multiple slaves in a modbus rtu protocol?

I have a big project with more than 100 slaves needs constant read requisition of my CLP.

I need read the position return in address 0x10 and other read in address 0x14 and sometimes the operation of the equipment to send write commands in other address, example to open the valve, close the valve or stop the valve for just ONE equipment.

How i just got perfomance and not low reads and low writters?

I was thinking in this solution and i've 4 ideas that I don't know if they work, please analyze then and confirm if is the a good option or if have another option i don't know.

1 - Just read the especific equipment when i actually in the IHM Screen of the equipment showing.
2 - Branch my connection with more CLP's and i got more speed return.
3 - Buy connection cards attached in the CLP with modbus rtu protocol to branch my connection.
4 - Try the method the full-duplex RS485.

OBS: i can't change the protocol of the another because my equipment just have the modbus rtu protocol inside your eletronic.

I searched a lot experiences like this and not found nothing about it.

 

#1: I'm not sure what you're proposing.

#2: I don't know what a "CLP" is. maybe PLC? Obviously, additional PLC(s) can service each smaller group of slave devices faster than a master can service a larger group of slaves.

#3: Adding serial cards to a PLC is a typical approach for increasing throughput. Each serial card can service a smaller group of slave devices on its 485 bus more quickly than a serial with 2x or 3x the times of slave devices on its 485 bus. There will be hardware limitations at some point.

#4: Full duplex is not likely to buy you anything with Modbus software, where the master just waits for the slave reply, then goes on to the next transaction. The timing to initiate a next-transaction-send when the reply is first arriving back at the master gets down to some nitty gritty timing. Many slaves devices don't even have the hardware connections for full duplex RS-485.

 

#1: I'm not sure what you're proposing.

#2: I don't know what a "CLP" is. maybe PLC? Obviously, additional PLC(s) can service each smaller group of slave devices faster than a master can service a larger group of slaves.

#3: Adding serial cards to a PLC is a typical approach for increasing throughput. Each serial card can service a smaller group of slave devices on its 485 bus more quickly than a serial with 2x or 3x the times of slave devices on its 485 bus. There will be hardware limitations at some point.

#4: Full duplex is not likely to buy you anything with Modbus software, where the master just waits for the slave reply, then goes on to the next transaction. The timing to initiate a next-transaction-send when the reply is first arriving back at the master gets down to some nitty gritty timing. Many slaves devices don't even have the hardware connections for full duplex RS-485.

Thanks for the help.

Regarding the first topic.

Let’s assume I don’t need to monitor all my equipment at the same time, like in a SCADA system or on just one HMI screen. Instead, I would only need to read data from ONE single Modbus slave on ONE screen. This means I would only read data from that specific slave, without needing to read data from the other devices.

When I switch to another screen to monitor a different device, I would stop the previous reading and start reading data from the new slave. This way, I can implement a real-time monitoring solution without overloading the network by polling multiple devices simultaneously.

 

#2: I don't know what a "CLP" is. maybe PLC? Obviously, additional PLC(s) can service each smaller group of slave devices faster than a master can service a larger group of slaves.

#3: Adding serial cards to a PLC is a typical approach for increasing throughput. Each serial card can service a smaller group of slave devices on its 485 bus more quickly than a serial with 2x or 3x the times of slave devices on its 485 bus. There will be hardware limitations at some point.

Regarding these 2 topics, I have two questions.

1 - Can I control my slave devices with additional PLC slaves?

2 - By adding these additional cards (maximum 4) per PLC, would I also be able to control my devices?

Wouldn't they be slaves? Or would they be masters? And if they are slaves, can I control a slave with a Card or PLC Slave?

 

This way, I can implement a real-time monitoring solution without overloading the network by polling multiple devices simultaneously.

It is not possible to "poll multiple devices simultaneously" over a single Modbus RTU RS-485 bus because the RULE of Modbus RTU is one master only, only one transaction at a time; not multiple transactions.

The reply/response from a Master's query/poll must be received before another transaction is executed. That's why it takes so long to get updated data when there are many devices on the same RS-485 multidrop bus. Polling is one device at a time, one after another.

 

1 - Can I control my slave devices with additional PLC slaves?

1. No. Modbus slaves cannot talk directly to other Modbus slaves. A Modbus slave can only talk to the Master.
A Master would have to be programmed to transfer data from slave A to slave F.

2. The functionality of 'controlling a slave' is specific to a slave's Modbus functionality. There are Modbus slave safety devices that are "read-only", which will not accept or execute "write" commands. Sometimes certain slave functions are not implemented in Modbus; it all depends.

2 - By adding these additional cards (maximum 4) per PLC, would I also be able to control my devices?

Modbus Master functionality varies from PLC to PLC, but in the third decade of the 21st century it's probably pretty safe to say that most major PLC brands have the processing power to execute Modbus transaction nearly simultaneously on multiple channels/serial cards, which is as close as you get to 'polling multiple devices simultaneously". Your ability to control devices depends on the Modbus functionality of the Master and the Slave and your coding skills.

Depending on the 485 chip used, most buses are limited to 31 slave "loads", before a repeater is needed to add more slave devices. A huge disadvantage of putting 100 devices on a single 485 multidrop bus is that a fault anywhere along the daisy-chained multidrop bus can take all devices downstream of the fault off-line, like when someone disconnects the 485 wiring to device #53 and leaves the wires hanging, forcing devices 54 through 100 off-line because the continuity of the bus wiring is disrupted. A failed driver line take all devices down. A near lightning strike or a line voltage fault on the 485 drivers could take out every slave on the bus.

 

Another implementation problem with a really long RS-485 bus with lots of slave devices is ground loops causing comm problems. The RS-485 differential references signal ground, which can be isolated to the chip itself, but most commonly is not because non-isolated chips are cheaper. The signal ground then is chassis ground. When installed chassis ground becomes earth ground. Earth grounds vary in potential with generated a ground loop current which can affect the 485 signal.

The longer the distance between RS-485 devices, the higher the likelihood of a ground loop. Yes, installations are supposed to be equipotential with no potential between earth grounds, but that's theory and RS-485 ends up in reality.

RS-485 Isolator modules can solve ground loop problems.

 

I agree with @David_2--when it comes to grounding (earthing) even when a plant has a safety ground and an instrument ground, it's inevitable the two get "joined" together at some point UNLESS everyone who is installing and commissioning the equipment is aware of and follows the design laid out for the grounding/earthing systems AND everyone who maintains, troubleshoots and installs new equipment is also aware of the design philosophy of the two earthing/grounding systems they get "joined" together at some point. Also, it's not uncommon for the two grounding/earthing systems to not be of the same size and for them to be installed in different soils at their locations--which can make for even more issues.

AND as @David_2 has written, there is theory and there is reality, and rarely does reality follow theory (for a variety of reasons).