"Watchdog" timer implementation on PLC

Coming from embedded world, I am interested how things are done in a PLC-based system to recover or "go safe" when PLC "goes-off-the-rails"???

zack,

Can you be a little more specific in what you mean by ...recover or "go safe" when PLC "goes-off-the-rails"???

Are you talking about the processor itself? Or the process?

Can you provide a sample scenario?

Off the rails??

This usually implies to me that one of the + or - power supplies has exceeded its current limitation (exceeded the maximum current limitation of one of the rail voltages) and the power supply is loading - voltage beginning to decrease due to over current conditions... I don't think this is what you mean. You probably mean program corruption, or "lost it's brains" scenarios???

Search here for topics regarding: Error Recovery, controlled crash, re-initialization, Alarm recovery, RSLogix User Fault Routine.

You will find a cornucopia of information.

You're probably going to get a lot of answers to this one so I'll try to be consise.

1) Certain PLC's have the ability to recover from certain software types of faults. Watchdog timer faults are software related and if there is no inherant flaw in the PLC logic (like an endless loop) the fault can be reset on-the-fly by user code.

3) Redundancy can be implemented on many mid to large PLC's. The level of redundancy varies from multiple power-supplies and multiple (backup) processors to duplicating I/O and even duplicating entire systems including the controlled hardware.

2) Hardware/System design issues. Fail-Safe design is one of those issues that is basic to good system design but is often overlooked. 1st of all (and I'm sure someone is going to call me to the carpet on this one) PLC systems are not inherantly fail safe. What I mean by this is that the normal failure of a solid-state input or output is unknown. To make matters worse digital inputs usually (does anyone have any statistics on this) fail in the ON state. Where safety issues are concerned the lack of a known fail state of the PLC hardware must be taken into account. Quite often it isn't.

Regardles, by designing PLC systems to be as fail-safe as possible within the context of a PLC (see above) and the rest of the hardware . When the entire system is really fail safe we provide the best protection for those times when our PLCs go "...-off-the-rails"

Good Luck,

(8{)} ( .)

Most PLC's have some form of a hardware based watchdog timer. Typically the operating system is forced to reboot using hardware.

A PLC is nothing more than an embedded controller executing an interpreted high level assembly language program often written to a EEPROM memory (at least these days). The ladder logic we see on the screen reduces to a series of simple statements. Most of the details of servicing I/O and managing the various housekeeping tasks is hidden from the PLC program.

Depending on the brand of PLC the programmer has several options available to him/her. PLC’s can be instructed to stop, set a bit, and/or start the program over. These options can typically be set by the programmer when the program is created. Some machines maintain a fifo list of the identified error(s).

Assuming the PLC reboots successfully, the user written program can determine what action to take. Sometimes hard stops are the worst thing to do.

How a machine reacts to serious fault conditions depends on how much effort went into anticipating those conditions. The level of effort usually comes down to money or safety. (It can be argued that safety is simply a way of avoiding a cost)