...1. Reduced the timeout to 300ms.
2. Set the retries to 0
Then I was able to still communicate with one drive after cutting the power from the other one. I wonder how it will be when I have all 14 drives on the RS-485 bus ?
14 drives should not be a problem. But I will caution you on a common mistake. When you utilize the on-board Ethernet port on the Do-more as a Modbus TCP Client (Master), it also has some timing parameters. For instance, by default, if you go to the System Configuration --> Device Configuration and double-click on @IntModTCPClient device you will see that the Timeout is set to 1000 ms (i.e. 1 second) and the Retries are 2. This means if he sends a TCP telegram to the MB-GATEWAY and then doesn't get a response back in 1 second, he will send another TCP request.
On the other end of the MB-GATEWAY, it also has timing parameters. By default it is also set to 1000 ms and 2 Retries for ALL SLAVES. This would not work well together with the @IntModTCPClient timing if, say, one of your slaves disappears off the RS-485 network. Think about it. It would take 3 seconds for the RTU side to fail. But in the meantime the TCP side has received multiple requests every second.
If you are polling at a 1 second rate in ladder logic, this can get even worse.
So, the bottom-line, you have to manage your polling in ladder when there is a timeout. And you should set the timeouts and retries on not only the slaves, but also the @IntModTCPClient to where they make sense. For instance I might have the Do-more timeout set to 4000 ms. That way, it won't retry until after my slave has retried 3 times on the RTU side.
Make sense? So managing this is why folks usually find it difficult to do their own I/O over Modbus TCP, especially if you are going to a Modbus RTU network through an MB-GATEWAY.
Hope this helps.