Controllogix output module config (output state when fault or program mode)

unsaint32

Member
Join Date
Oct 2012
Location
minneapolis
Posts
365
When configuring a output module of Controllogix, I can choose the output state when going from run mode to either program mode or fault mode.

I want to make sure I get this concept, right. Pleas let me know if my examples are correct use of such config option.

An output activates a solenoid for a vertical cylinder that holds up a heavy load. I do not want the load to crash down when the output module faults. So, when it faults, the output being ON will keep the load up. While the load is up, I want to modify the program, and I can safety change to the program mode.

I am sure there are much better reasons for the config options.
 
So you probably want the Hold Last State option so that when switching to Program Mode if the output is on it will remain on and if it was off it will remain off.

Keep in mind that the Fault option is only for Non-recoverable major faults. These are usually the bad ones, like hardware issues. If the logic causes the fault then it is referred to as a Program Fault and the output would go to its Program Mode state.

Recoverable faults = Program Mode
Non-recoverable faults = Fault Mode

Typically the output is configured the same for either state, but I wanted to point out the difference as it is not obvious.

OG
 
RECOMMENDATION:

postpone your use of these settings (particularly the "Fault" setting) for a while ... right now I'm in the middle of a project with a pressing deadline - so I don't have time to fully explain - but that "Fault" setting doesn't work the way most people assume that it will ...

I'll explain soon - if someone else doesn't before I get time to nail it down ...

TIP: some of the official books are wrong ...
 
I'm still short on time - but here are a few experiments to help nail down some of these "Output Module Configuration" ideas ... these were done with a 1756-L55/A processor - Firmware Revision 16.20 - and a 1756-OA16/A output module - Firmware Revision 2.3 ...

my main reason for posting this material is that the "Fault Mode" setting does not function the way that many people assume that it will ... this could lead to some nasty surprises in certain applications ...

first of all - the "Fault Mode" setting refers to a "Communications Fault" - not to a processor fault ... the "Help" feature does a pretty good job of explaining this - while some of the other documentation sort of drops a stitch ...

notice that removing the processor from the chassis will cause a "Communications Fault" and the output device WILL turn ON ...

.

E.jpg
 
Last edited:
here we've sent the processor into a non-recoverable fault condition - and the output device turns ON - even though the "Fault Mode" setting is set for "Off" ...

notice that the "Program Mode" setting is set for "On" ...

my conclusion is that the processor is not in "Run Mode" - therefore the configuration feature seems to accept this as a "Program Mode" condition ...

.

A.PNG
 
Last edited:
here we've sent the processor into a recoverable fault condition - and the output device turns ON - even though the "Fault Mode" setting is set for "Off" ...

notice that the "Program Mode" setting is set for "On" ...

again - my conclusion is that the processor is not in "Run Mode" - therefore the configuration feature seems to accept this as a "Program Mode" condition ...

.

B.PNG
 
Last edited:
here again - we've sent the processor into non-recoverable fault condition - and the output device turns OFF - even though the "Fault Mode" setting is set for "On" ...

notice that the "Program Mode" setting is now set for "Off" ...

my conclusion is that the configuration feature does not consider this to be a valid "Communications Fault" condition - so the "Fault Mode = On" setting has no effect ...

.

C.PNG
 
Last edited:
here we've sent the processor into recoverable fault condition - and the output device turns OFF - even though the "Fault Mode" setting is set for "On" ...

notice that the "Program Mode" setting is set for "Off" ...

my conclusion is that the configuration feature does not consider this to be a valid "Communications Fault" condition - so the "Fault Mode = On" setting has no effect ...

.

D.PNG
 
Last edited:
now then ...

from the OP's original post:

An output activates a solenoid for a vertical cylinder that holds up a heavy load. I do not want the load to crash down when the output module faults. So, when it faults, the output being ON will keep the load up. While the load is up, I want to modify the program, and I can safety change to the program mode.

going further - I'm pretty sure that there's no way to have a particular output point take a specific action (On/Off/Hold) whenever an OUTPUT MODULE has any type of "fault" condition (other than a loss of communications with the processor) - which is what you seem to have in mind - at least based on how I'm reading your original statement ...

personally - I'd look for another way to SAFELY handle your application than trusting this "Output Module Configuration" feature ...

I hope this helps ...
 
Last edited:
Ron, how are you creating the non-recoverable fault? I ask because your graphics shows a Task watchdog timeout which is not a recoverable fault. I'm just wondering the significance of that fault graphic in your screenshots. It appears as though every example is showing a recoverable fault and every time it is going to the configured Program state. It does not appear you ever had a non-recoverable fault, based on the screenshots.

A non-recoverable fault should cause the CPU to wipe its memory. You would not be able to go online, you would have to reload the program.

I would say too that the reason a recoverable type fault goes to Program state is to prevent the possibility of someone affecting an output by simply clearing the fault. Imagine if it was set to Hold for Fault Mode and set to Off in Program mode. Your output is energized and a fault occurs. It would hold On at that point. Then someone goes into the software and clears the fault. That would return the CPU to Program Mode and would cause the output to turn off. So the act of clearing the fault would impact the process. That would be bad, so it treats recoverable faults the same as Program mode.

And I agree, what we are talking about here are CPU faults, not faults with the module itself. If you are looking at protection from failed modules as it appears you are, you probably need to look at GuardLogix and safety I/O.

OG
 
Last edited:
nogoing further - I'm pretty sure that there's no way to have a particular output point take a specific action (On/Off/Hold) whenever an OUTPUT MODULE has any type of "fault" condition (other than a loss of communications with the processor) - which is what you seem to have in mind - at least based on how I'm reading your original statement ...

personally - I'd look for another way to SAFELY handle your application than trusting this "Output Module Configuration" feature ...

I hope this helps ...

Wow, I'm glad you explained about the comm fault. I was just using the cylinder as a hypothetical example, but I'm sure knowing that fine print potentially prevented some fatal mistakes I would have made otherwise. The old adage "I know just enough to be dangerous," really hits home here.

Thanks Ron.
 
Greetings OG ...

I think I see where we're failing to communicate here ...

my understanding (quite probably wrong) was that:

(1) a RECOVERABLE fault is one which CAN be "trapped by a fault routine" ...
(2) a NON-RECOVERABLE fault is one which can NOT be "trapped by a fault routine" ...

the two types of faults in my screen shots were meant to demonstrate those two types of faults ... (specifically: "trappable" and "non-trappable") ...

your definition of a NON-RECOVERABLE fault is quite different ...

A non-recoverable fault should cause the CPU to wipe its memory. You would not be able to go online, you would have to reload the program.

based on that definition (which is undoubtedly more correct) then I can certainly see where a NON-RECOVERABLE fault would always involve a "Communication Fault" – and render the operation of the "Fault Mode" setting more sensible ... (obviously the processor wouldn't be able to communicate – if it had suddenly dumped its memory) ...

Ron, how are you creating the non-recoverable fault?

based on your definition, the only way that I have available (as far as I know) is to simply yank the processor out of the chassis – so that's what I did in the first screen shot ... kind of "brutal" – but it does demonstrate a "Communications Fault" between the processor and the output module - and turn the output ON ...

summing up ...

you and I were both on the same wave length here – except that my working definition of a NON-RECOVERABLE fault is (or at least was) different from yours ... gotta love this forum ...

thank you ...
 
Last edited:
Personally, I would not rely on anything in Controller or Output Module configuration to "fail-safe".

There are far more important decisions to be made in the mechanical, pneumatic or hydraulic, and electrical designs before you even think about failure modes of the PLC control system and it's I/O hardware.

I've yet to see an output module retain an output 'ON' state for the most frequent of failures - total loss of power !

I was once taught that safety should be engineered "backwards", the control system being the last to design....

In the OP's original post, he said he wanted to stop the "heavy load" from crashing down if his output module fails... you definitely can't rely on the output module to do anything you ask it, if it has failed itself....
 
daba said:
... you definitely can't rely on the output module to do anything you ask it, if it has failed itself....

This is probably the bottom line, from my perspective. No matter how many smarts you pack into the PLC to stop a heavy load crashing down, a PLC can't help you if someone drives a forklift into a cable tray and damages the cable going to your actuator. The system must be made inherently mechanically safe before you even entertain the idea of "smart" safety controls.
 

Similar Topics

Hi everyone, I have a course doing lab with AB's controller and it's very fun. However, in today's lab, we were working with the "DC output"...
Replies
7
Views
5,477
I am looking for information that will provided me with information on how to wire a ControlLogix Digital Output to the CompactLogix Input to turn...
Replies
7
Views
2,354
XV was working. Now, following download, not working. Turn it on at the display and it fails. Thought it was the return status not coming back...
Replies
2
Views
1,500
Is this the card, or what's driving the card? It's just a permissive being sent from one building to another.
Replies
19
Views
5,320
Back
Top Bottom