Control.com - Nerds in Control

Prosoft Modbus communication modules for Allen Bradley like MVI56-MCM cause timout problems on multiple slaves RS-485 multipdrop network if slaves are powered off or faulty. Suggest how to nullify/minimize timeout effect on rest of the slaves.

We have extensively been using MVI56-MCM modules for peer to peer communication between Allen Bradley and Hima/ICS/Honeywell etc. As far as peer to peer communication is concerned it works fine but we have been facing problems using this module for multiple slaves on a single multi drop (daisy chain) RS485 network.

For example if we have 10 slaves communicating on RS485 network with MVI56-MCM master, if any of the slaves fails, we get delayed response to the requests from rest of the slaves. The problem worsens if number of devices and the number of non-responding devices increase on the network. The reason behind the problem is believed to be comms timout for a particular slave.

A vendor has advised to use Modbus TCP/IP but there are many other devices like CMAC controllers which work fine even if any of the Modbus slave is turned off or fails to communicate. Similarly, a vendor has written code in co-processor for Allen Bradley PLC-5 which sends Modbus messages on RS485 network but doesn't have the timeout problems as we have in regular MVI modbus comms modules.

Please provide the solution to the problem so that we still could use MVI modules on multipdrop RS485 network.

While I am not at work right now, I do recall the MVI module, in the port setup has variables for retries and timeouts. Did you try to reduce these?

Hugo

On a master/slave multidrop network, the master must send a message to the slave device then wait X mSec for a response from that slave. If the slave fails to respond, the master (the ProSoft module) will then retry for the configured retries, before moving on to the next command in this list.

Although this is a problem that is common on any master/slave multidrop network (like Modbus, DF1, DNP, etc...) the module has many ways that you can deal with this.

1) Adjust your timeout settings and retry counts. This will keep the module from waiting so long for each Modbus message, and if it fails the module will not issue a retry if the retry count is set to a value of 0.

2) Utilize the ErrDelayCnt in the Modbus PortX configuration. This error delay counter tells the module to skip the next X commands to that slave device. If this value is set to a value of 200 for instance, the module will skip the next 200 commands that should go out to that slave device.

3) When a slave is in error (or if you know that it is being taken offline) utilize the block 3000 to disable the slave device from the polling list. When the slave is back online you can then use the block 3001 to enable the slave again on the network (section 8.2.9 of the 1-24-2008 User Manual).

If there are any questions about these items please don't hesitate to give us a call at 661-716-5100.

Thank you,
Erik Syme
Product Development Engineer
ProSoft Technology