DeviceNet Faults - DeviceFailureRegister

[bonjourdaisy 0]

Hey guys, I've got one that maybe someone here might have some insight on. Basically, we're monitoring the DeviceFailureRegister (S register for DNET scanner module) to detect loss of comms to certain nodes. What I'd like to know, is what happens if the DNET scanner module itself fails? Am I guaranteed to obtain a fail in my DeviceFailureRegister? I've playing around with the emulator a bit and it seems to trigger the DeviceFailureRegister to basically indicate all nodes have failed when I have a module fault. But the thing is, I'm still not certain. As I understand it, this DeviceFailureRegister is an "S" register that I'm reading from the DNet scanner at my RPI. So my concern is that if I lose a connection to the module, the DeviceFailureRegister may not reflect a loss of comms to that node (ie the DeviceFailureRegister bit for that node may not have changed since I no longer have a connection to the module anymore). Does anyone have any insight on this issue? I'm using devicenet to control this motor so I'd like to know if this is reliable way to monitor my entire connection to that motor driver (from the CLX processor, to the DNET scanner, and then to the motor driver). Much appreciated. Edited 20 Apr 2014 by bonjourdaisy

[Ken Roach 194]

That's a great question, but I think you'll have to test the actual hardware to be certain. In general, the tags associated with the input data of an I/O module remain at their last state if the connection between the controller and the module fails. I'm certain that the Input data for the 1756-DNB remains at its last state if the DNB itself fails or is removed or loses its connection to the CPU. But I'm not certain about the Status tags of the 1756-DNB. The usual method I've used to verify the connectivity of a 1756-DNB or a 1788-CN2DN or 1788-EN2DN is to periodically (every 100 to 500 ms) execute a GSV instruction to check the Module Status attribute of the Module Object. Any time the value of bits 12-15 isn't "4", you have a broken connection. This is a very common method for any I/O connection in the ControlLogix world. The other thing you're going to want to check is to find out if the DeviceFailure bit turns on when the Scanner module boots and never establishes communication with the slave device. Over the years I've tested various combinations of the Active Devices bit array and the Device Failure bit array to handle a failure to communicate after reboot, but I haven't done it recently enough to post with confidence about how every 1756-DNB firmware revision will work.

[bonjourdaisy 0]

Thanks for the response, sir. Just to clarify, when you say DeviceFailure are you referring to something other than the DeviceFailureRegister? I know that there is also a DeviceFailure bit which is kind of a general fault indicator for your network, rather than the DeviceFailureRegister which contains a bit for each node on the network. Yeah I'm wondering if to be safe I should monitor the GSV EntryStatus, ActiveNodeRegister as well as DeviceFailureRegister. If any of these are indicating a problem, trigger a shutdown. Thanks again. Edited 21 Apr 2014 by bonjourdaisy