When a device is a Modbus slave, it has no way to tell the difference between a situation where communications have failed between it and the master and a situation where the master is not trying to talk to it. If our module does not see a request from the master, it will not know why, i.e not be able to tell the difference between the master not trying to talk to it or bad wiring, or a locked-up master. Unless the slave receives a valid message addressed to it's slave node address, it will not know the master even wants to talk to it. As a Modbus slave, there is no way for our module to know whether or not a master is supposed to be communicating but isn't; and, therefore no bit or value in our module to pass this information on to the processor to generate a comm fail alarm.As a work-around, if you can add Modbus commands to the master device, you can have the master write a constantly changing integer value, essentially a 'heartbeat',that can be monitored by logic in the slave processor. If you can't add commands to the master, but it is always writing values that change to our module's slave port, you could use one of those values for your 'heartbeat'. You could then add timer logic in the slave processor to look for this 'heartbeat' data to change. If this data stops changing, the logic timers will time out and a comm failure alarm can be generated. For any suspected communication loss, always first check for cable faults or noise on the communication lines. for ProSoft MVI and ProLinx modules, use a terminal emulator program, like MS windows hyperterminal, to access the data analyzer through the debug/config port, port 0. refer to your user manual for details.
MVI ProLinx ProSoft