How does a MVI56-MCM determine the Slave Status?
You need to be logged in to get access to the forums. You can do so here
|
simonl
|
Saturday 30 July 2005 1:38:30 am |
|
|
How does a MVI56-MCM determine the Slave Status?
Hi There,
Could someone explain how the MVI56-MCM determines if a slave device is failed or not. I have written a simple timer based ladder that triggers the module to update it's ".P1Slaves(x)" registers (4 seperate triggers per MCM module). The problem I have is that on every other scan of my timer logic some of the slave registers report healthy the next scan bad! I have used a Modbus monitor on my network and the data stream does not show any errors to the affected devices. I've 'scoped the RS485 network too and the waveform looks nice and square and no noise.
I have tried slowing down the poll interval of my commands, increased timeouts, retry counts, interval between commands, all to no real effect. I just get the same problem, just slower.
I understand that the MCM puts the slave device 'to sleep' for the duration of the 'ErrorDelayCntr' and then wakes it up again to retry if it can now talk to the device.
Does the MCM determine if a device is bad by using the retries and timeouts and then if it cannot communicate it then updates the "slave status register" or does the MCM look for a specific watchdog or heartbeat from the slave device?
I have 5 MCM modules on my control scheme all talking to a varity of Schneider and Alstrom breakers and each module has the same problem.
Many thanks for whatever advice anyone can offer.
|
|
jsanders
|
Thursday 17 November 2005 9:15:47 am |
|
|
RE:How does a MVI56-MCM determine the Slave Status?
I am sorry to say that the information in the User's Manual concerning the Slave Status table appears to be a bit misleading. This table is not the best way to determine the status of communication to a given slave. It is really just a 'scratchpad' area of module memory used to store the tempory values of a state engine within the module's operating program that holds the current relationship status between the Master protocol driver and a Modbus Slave at any point in time when the Master driver is trying to poll that Slave. As the module attempts to poll, the values in the table change to indicate what part of the polling process is currently underway. This table has very little practical application for determining whether or not a particular slave is successfully communicating with our module.
The best indication of Slave Communication health, or lack thereof, is the Command Error List. This list contains the result of each poll request on a 'per command' basis. Using this list, it is possible to determine if any particular Command is failing. Since each Command is addressed to only one Modbus Slave node, the status of the Command indicates the status of communication with the associated slave. Successful polls result in a zero (0) status value. Unsuccessfully polls will be given a non-zero value. This Error Codes can provide clues as to why the Command is failing. Any Command Error List value that remains non-zero for a significant amount of time will indicate communication problems to a given slave.
If more than one Command is sent to a Slave, the Command Error List Values can be OR'ed in ladder logic into one Slave Comm Fail Alarm, if so desired. This is the best way to determine communication health between our module and any given Slave.
|
