How to avoid slow data updates on a Modbus network with an MVI56(E)-MCM or MVI69-MCM when some Slaves are either not on-line or not functioning correctly?

A customer wrote:

"Prosoft Modbus communication modules for Allen Bradley, like MVI56-MCM, experience timeout problems and polling delays on RS-485 multipdrop networks if slaves are powered off or faulty. 
For example, if we have 10 slaves communicating on the RS485 network with the MVI56-MCM master, if any of the slaves fails, we get delays in making requests to the other slaves. The problem worsens if the number of non-responding devices increases on the network.
Please provide the solution to the problem and suggest how to nullify/minimize timeout effects and delays on polling the rest of the slaves."

Prosoft Technical Support responded:

"On a master/slave multidrop network, the master must send a message to the slave device then wait a configured amount of time for a response from that slave. If the slave fails to respond or the master receives an invalid response, the master (the ProSoft MCM solution) will then retry for the configured number of retries before moving on to the next command in the list.
Although this is a problem that is common on any master/slave multidrop network (like Modbus, DF1, DNP, etc...), ProSoft MCM solutions have several ways that you can minimize these delays.
1) Lower your ResponseTimeout and Retry Count. A lower Response Timeout value will keep the module from waiting so long for each Modbus response; and if it gets no response or gets an invalid response and the retry count is set to 0, the master will not issue a retry.  This will allow the master to move on to the next command in the list as quickly as possible.
2) Utilize the Error Delay Count in the Modbus Port configuration. This Error Delay Count tells the master to skip the next so-many commands to a slave device once one command fails. If this is set to a value of 200, for instance, the master will skip the next 200 commands that would have been sent to that slave device before it tries to send it another command.  This effectively creates a 'slow poll mode' for that slave and only that slave.  Once the slave starts responding normally, the master will continue to poll it normally.  Skipping commands to non-responding slaves speeds up polling to slaves that do respond.
 
3) When a slave is in error (or if you know that it is being taken offline), you can utilize the special Disable Slave function to disable polling of that slave. When the slave is back online you can then use the special Enable Slave function to enable polling the slave again.
If there are any questions about these items please don't hesitate to give us a call at 661-716-5100.