Fault Handling (Allen Bradley)

Hi Folks,

I am an Automation Engineer who has been working on PLCs for 2 years now so I'm still a newbie of sorts. I've worked with mainly Siemens PLC so far but now I've had to work with Allen-Bradley PLC.

Anyway my question is related to Fault Handling. In Siemens we have Organizational Blocks for 'handling' errors. OB's such as OB 121 (Programming Error) and OB 122 ( I/O Access Error) prevent the PLC from going into STOP mode in case a programming error appears or if a module is faulty.

Does Allen-Bradley have any such equivalent?

I know that we can create a routine for the Controller Fault Handler to skip the part of code that creates a major fault but is there any way to do this without the PLC going into Stop Mode?

Regards,
Boris

I know that we can create a routine for the Controller Fault Handler to skip the part of code that creates a major fault but is there any way to do this without the PLC going into Stop Mode?

Click to expand...

Yes, there are ways. If it is a Minor Error, then you can add logic to correct the error (if it is detected), reset the fault, and continue running. If it is a serious Major Fault (something that the PLC cannot work around), then usually a program Fault Reset will not work. Allen Bradley provides several Fault-Handling examples that come with the programming software.

Allen Bradley provides several Fault-Handling examples that come with the programming software.

Click to expand...

Oh ok. I will check up on that and see how it goes. Thanks.

There are 3 types of fault that an A-B processor will handle.

Obviously if the fault stops the processor's OS working (such as a CPU failure), that would make it 4, but that would be a hardware failure - and can't be trapped.

The 3 types of faults, in order of severity, the processor can handle are....

1. Minor Faults - these are fault "warnings" if you like, and don't stop the processor from continuing to execute the user's program. A typical minor fault is "Battery Low".
Lancie1 incorrectly said that you can write code to reset the error, see section 2. Minor faults (In the A-B world) are just warnings, and don't need any additional handling.

2. Recoverable Major Faults - These are faults that the processor has detected, that if not dealt with, will cause the processor to "red light", and stop execution of the user program. To explain "dealt with" - after a recoverable major fault occurs, the processor executes a "fault routine" that you create. In there, you can inspect the fault code, and optionally reset it, so that the processor continues. I've not seen many examples of fault resetting in over 25 years, but the facility exists. This is what Lancie1 was referring to in his post. If you don't reset the fault codes, the processor will stop execution of the user program, and "red light".

3. Non-Recoverable Major Faults - These are faults that will stop the user program execution, and no fault routine (if it exists) is executed. An example of a NRMF is a memory checksum error, indicating program or data corruption.

HTH

I see. As my work is with the Baggage Handling Systems in Airports it is important that the PLC does not go into Stop Mode when a Recoverable Major Fault arises. So if possible I need a code that skips that fault routine (like in S7) and resets it without the PLC going into Stop Mode.

For recoverable major faults, the fault routine will automatically be executed. It is up to you to decide if the fault can be tolerated.

Inspect the fault, decide if it can be reset, and clear the code(s) if you want to. After the Fault Routine is executed, if the fault code is non-zero, the processor will fault (stop).

More importantly, the processor has detected a fault that should stop the processor. Typically these type of faults are due to a bad program ! I would use the information to rewrite my code so that a recoverable major fault doesn't occur.

Ah ok. I'll see what I can do. Thanks for your help!

Some typical recoverable faults.....

Array boundary violation - your code is attempting to read an array, or data-table, element outside of its size (usually when indirect or indexed addressing is used in the code).

Negative Timer preset or accumulator values - you have code that manipulates these mathematically, but there isn't any trap code that stops negative values being written.

Like I said, the recoverable faults are usually created by bad programming - your code should be stopping the causes of recoverable faults. A well-written application should cause no recoverable faults.

It's all in the documentation, but post back if you need any further assistance.

Thread Necro here.

So my dumb *** apparently missed a place where a array index could be out of bounds and faulted a plant wide processor last night.

My code runs in it's own program and it's own task.

Is if I create a fault routine. Will just doing that prevent the whole processor from faulting, or do I have to write code to fix each possible fault?

if it is the latter what would be the point of a fault routine? I already wrote code to try to prevent a index out of bounds it just seems I messed up and my logic was off.




EIA:

would a acceptable approach be to inhibit the program? http://www.plctalk.net/qanda/showthread.php?t=113912

If you did that from the fault routine would it prevent a system wide fault?

I have used fault routines on Rockwell Systems, upon a fault the routine ran to place everything in a safe place, before the processor halted. I don't think you can correct the fault, only react to it, others may have a better understanding.

A fault routine can absolutely be used to clear a fault and continue running. However, there has been a problem. Clearing the fault doesn't fix that problem. Often times we will use the fault routine to clear the fault while we start an orderly shutdown. Once the shutdown is complete, the fault routine may allow the controller to enter Fault Mode.

When created, A fault routine exists within a Program. If a major recoverable fault occurs while scanning within that Program, then your fault routine will execute. If the scan is in another Program or Task, your fault routine will not execute. If the fault is not related to logic, such as the failure of a required I/O module, your fault routine will not execute.

Within a fault routine I typically include logic to do three things.

1. Set a bit to indicate there has been a fault. I create a BOOL tag for this. I can then use that tag in my normal logic to alert that we have had a fault. I might call it ProgramName_Fault_Flag or something along those lines.
2. Capture the fault information. Use a GSV instruction to capture this information so I have it stored. This requires creating a UDT and then a tag using that UDT to capture the structured data.
3. Clear the fault. I use an SSV with a separate fault tag using that same UDT. That tag has all zeroes for its data which will clear out the fault in the controller. You might choose to have conditions to examine what the fault code was and then decide if you want to allow the fault to be cleared.

So, the process would be that when your fault occurs, the scan will interrupt and jump to your fault routine. It will scan through that fault routine and let's say that we clear the fault. At the end of the fault routine the scan will return to the next instruction from where it was interrupted and resume scanning at that point.

Now, let's say that the fault routine did not clear the fault. At the end of the scan of the fault routine the controller will check to see if there is a Controller Fault Handler (CFH). If there is one, the scan will jump to the Fault Handler. If there is no CFH, then the controller will enter Fault Mode and stop scanning.

Now let's assume that the fault is unrelated to logic. If the connection to a required I/O module fails, the Fault Routine will NOT execute and the controller will interrupt the scan wherever it is and jump to the CFH if it exists. If it does not exist, then the controller will fault.

The Controller Fault Handler is sort of a catch all, or last resort for capturing faults. It can be tricky when you set it up because you have to create a Program and a Main routine, but not a fault routine. I would include the same three things here that I would include in a normal fault routine.

If your project contains multiple Programs, then you would have to create a Fault Routine for each Program. Alternatively, you could instead create one CFH that could handle faults for all Programs. And remember that the Fault Handler is the only way to react to I/O type faults.

Same rule applies. If at the end of the scan of the CFH if you have cleared the fault, the scan resumes with the next instruction from where it was interrupted. If the fault has not been cleared, then the controller will enter Fault Mode and shut down.

Example of my typical Fault Routine or CFH logic (with a special nod to theColonel26)

OG

Awesome!!!!!

Where did you get the Major fault UDT?

And Is there any reason why I shouldn't programmatically inhibit the program from running after clearing the fault?

I created it following their directions. Go into the help for the GSV and look up help on the PROGRAM object. For the MajorFaultRecord it outlines how to construct the UDT.

OG

theColonel26 said:

...And Is there any reason why I shouldn't programmatically inhibit the program from running after clearing the fault?

Click to expand...

Sorry, I missed the second part of your message...You certainly can inhibit a Program. I guess the issue comes down to identifying what you want to have happen if/when a fault occurs. I typically have logic in that Program that alerts the operator; usually a flashing light, but in some cases a horn/claxon. Then, I also have logic to acknowledge the alarm and silence the horn/flashing light. That logic could however be placed in a separate Task/Program.

OG

Thank you sir.

And yeah what I want to happen is for it not to take down a whole plant just because one of like 50 programs had a fault in it.

A program I might add that interacts with nothing else on the PLC.