Contrologix Output behavior on Controller Fault?

[Paul351W]

I recently had a controller fault on a project(make sure not to send a negative number to a timer .PRE value) , and I was curious what happens to the card outputs when the controller faults.

I know about the communication fault options you can configure in the module properties, but I haven't found anything that explains what they do when the controller faults.

 

[Mike_RH]

Check the properties for each output module, it is configurable.

 

[Paul351W]

When I check the help information for the module properties, I found this text:

Fault Mode

Select one of the following for each output point:

• Off - output will be 0 or OFF in communications fault mode
• On - output will be 1 or ON in Communications Fault mode
• Hold - output will maintain current level in Communications Fault mode

Use this function to determine what happens to the output of each point after a communication fault occurs and the module enters Communications Fault mode.

That text indicates to me that the module settings are for communication faults only, not controller faults.

 

[dmargineau]

The respective outputs are controlled by the CPU via implicit (I/O type)communications.
When the controller hard faults, the implicit communications cease to be serviced by the processor hence the outputs will be switched to their "Fault State" configuration...

 

[Ron Beaufort]

try this little experiment on a SPARE system ...

shown below is a 1756-OA16 output module which has a field output device being driven OFF by the false condition of the ladder logic rung ...

we can easily create a fault condition in the processor by toggling the CAUSE_A_FAULT bit to the ON status ... the processor will "chase its tail" from the JMP to the LBL and a watchdog fault will soon occur ...

RESULTS: when the processor faults, the output device in the field does NOT come on – regardless of how the "Fault Mode" is set up on the module's Configuration tab ...

on the other hand ...

suppose that we clear the fault and then put everything back into normal operating mode ... once again, the output device in the field is currently being driven OFF by the false condition of the ladder logic rung ...

now suppose that we manually pull the processor out of the chassis – to intentionally cause a "communications" type fault between the processor and the output module ...

RESULTS: this time the output device DOES indeed come on – because of how the "Fault Mode" is set up on the module's Configuration tab ...

CONCLUSION: the "Fault Mode" being controlled on the output module's Configuration tab refers to a "communications" type fault between the processor and the module ... it doesn't refer to a "processor" type fault as most of us would assume ...

.

 

[Ron Beaufort]

here's another little experiment to try on a SPARE system ...

refer to the figure shown below ...

in normal operation a 1756-OA16 module's field output device .0 was being driven ON by the true condition of the top ladder logic rung ...

the same module's field output device .1 was being driven OFF by the false condition of the second ladder logic rung ...

we then created a fault condition in the processor by toggling the CAUSE_A_FAULT bit to the ON status ... the processor "chased its tail" from the JMP to the LBL and a watchdog fault soon occurred ...

RESULTS:

when the processor faulted, the output device for bit .0 in the field was driven OFF – because of how the "Program Mode" is set up for that particular bit on the module's Configuration tab ...

(that sort of "makes sense" because we usually associate a processor fault condition as causing outputs to be driven OFF) ...

on the other hand ...

when the processor faulted, the output device for bit .1 in the field was suddenly driven ON – because of how the "Program Mode" is set up for that particular bit on the module's Configuration tab ...

(and yes, I know that's weird ... specifically, most people expect the output to follow/obey the "Fault" setting shown in the next column – which happens to be set for OFF) ...

do not be confused by the "green on the screen" status indications ... those are a reflection of whether or not the bit/boxes in the processor's memory contain a ONE status or a ZERO status ... but the LEDs on the output module – and any real-world devices that are connected to the terminals for those two bits - will behave as I've just described ...

but don't take my word for any of this – try this out for yourself on a SPARE system ...

CONCLUSION: when the ControlLogix processor enters a Fault condition, the field outputs are driven to the state shown in the "Program Mode" column – NOT to the state shown in the "Fault Mode" column as most of us would assume ...

so are we having fun yet? ...

.

 

[Ron Beaufort]

and finally, back to the OP's original question from Post #1 ...

I know about the communication fault options you can configure in the module properties, but I haven't found anything that explains what they do when the controller faults.

in simplest terms, when the ControlLogix processor enters a Fault condition, the field outputs are driven to the state selected in the "Program Mode" settings of the module's configuration window ...

now many (most?) people find that to be "weird" ...

common sense would prompt us to think that a "faulted" processor would cause the outputs to go to the states selected in the "Fault Mode" column ... this is yet another example of where common sense and PLCs don't fully coincide ...

and going even further ...

the settings on the output module's Configuration tab can even OVERRIDE a "Force" ... specifically, even if a particular output is being held OFF by a Force (and with the Force enabled) an ON setting in the output's Program Mode column can drive the field output device ON when the processor enters a Fault condition ...

but don't take my word for any of this – try it out for yourself on a SPARE system ...

 

[daba]

Great explanation Ron, always a difficult one to get across.

Although just about adequately explained in the "Help" descriptions, perhaps easier to understand if the text on the dialog was changed...