PLC Watchdog - ControlLogix


Thread Starter


For an industrial gas turbine application, should you require an independent watchdog for a ControlLogix PLC?

I'm used to seeing independent Watchdogs on an E-Stop loop for control systems. For example, the Mark II had re-triggerable relays that the processor needed to set every few milliseconds or the E-stop loop would be opened. It did processor to processor calculations to verify network communications as well.

I keep hearing "ControlLogix" has built in watchdogs, but I don't understand how something can truly monitor itself, and I don't see any special watchdog outputs on the processors. If the processor "freezes" how can it take action if it's the thing frozen?

Agree? Disagree? Does anyone know of any Rockwell Literature supporting this claim?

Thanks for you input.

Curt Wuollet

As far as I know the internal watchdogs are meant to monitor user code. I agree that if the processor locks up, it can't very well watch anything.

If they have another means to watch the processor, that could work. But I think they believe that _their_ processor would never do that :^)

The Turbine designs I see, the external hardwired watchdog is combined with overspeed. So either overspeed detection or watchdog pulse which is one o/p from the PLC provides a hardwired monitor.

If a PLC detected trip is required, the watchdog pulse simply stops which is a constant check on the hardwired system.

This external watchdog applies to any PLC not just ControlLogix.
> As far as I know the internal watchdogs are meant to monitor user code.

Thanks Curt. That's how I understand it as well.

Bob Peterson

I have seen people put external watchdog timers on PLCs. I have never heard of one ever tripping because the PLC went nuts. I have also seen people but a PLC controlled relay in series with the MCR so that if the PLC could no longer control I/O the MCR would trip. Again, never heard of it ever tripping that way.

For the most part PLCs are far more reliable than the MCR circuit as long as you are using modern PLC hardware from reputable manufacturers. I think you are just adding an extra thing that can fail to the system.

If you feel you must have it, I don't have an issue with it, and the way to go if you insist on doing so is to go with the external timer being reset by a PLC pulsed output. That covers both scenarios.

Curt Wuollet

I agree that conservatively rated and properly applied electronics should be much more reliable than electromechanical devices. But I replaced half a dozen AB PLCs in one month due to a memory problem. And I have seen the old Honeywell thermostats work for 60 years.

I think it is easier to make a safe circuit with relays, you don't have to know much. And they are very simple and obvious.
And you can make a PLC fail fairly easily by omission or misapplication.

So, I would add, if you know what you are doing, to your PLC statement. And the world is much grayer and more nuanced than when I started.

> So, I would add, if you know what you are doing, to your PLC
> statement. And the world is much grayer and more nuanced
> than when I started.

Thanks Curt. I agree. Much grayer indeed!

Now, how would I test a PLC watchdog? How do you make the PLC fail (non-destructively) so that you can see a watchdog work?

Simply shutting off power to the PLC would hopefully move devices to a fail safe position, but what I really want to see is what would happen if the PLC locks up (stops executing or gets stuck executing the same code over and over again).

I assume a network I/O watchdog can be tested by simply pulling the cable, but that also isn't the same as a network flood or overrun buffer.

Any ideas? ControlLogix or any plc would be helpful.

Just write a subroutine that runs longer than the watchdog timeout. Since normal scanning is suspended for the sub exec, it would simulate a lockup.

Of course, you would need to disable the internal watchdog. I've sent many computers into la la land, it's just a little harder with RLL :^)



> Now, how would I test a PLC watchdog? How do you make the
> PLC fail (non-destructively) so that you can see a watchdog work?

Write a program loop that never ends or has many iterations. Some sort of FOR loop or GOTO (or jump) statements can be used in many PLCs. The scan then gets "stuck" in one spot in the program and the watchdog timer will time out.

Unintentional programming bugs of this sort are what PLC watchdogs are really intended to find. The PLC itself is running normally, but your program has a bug which prevents the scan from proceeding. It's not intended as a critical safety element.
In ControlLogix CPUs, it is possible to configure a maximum scan time, such that if the actual scan time exceeds the configured max, the CPU goes into Fault Mode, and all the output signals go to their configured Fault States. Within Logix5000/Studio5000, this max scan time is referred to as a "Watchdog."

According to the safety manual the latest line of ControlLogix CPUs, the L70 series, have a safe failure fraction (SFF) of 96%. That means that for 96% of all known failures that can happen to the CPU (not including backplane, I/O modules, or wiring), the CPU will detect the failure and go into Fault Mode. If you configure all your output channels to go to their respective safe states (presumably de-energize for most of them), and there is a detected PLC fault, you should be okay. Of course, a SFF of 96% means that 4% of all known CPU failures will not be detected be the CPU and will not go to Fault Mode if one of those failures occurs.

It should be pointed out that a SFF of 96% is good compared to many of the logic solvers available out there, and puts the L70 CPUs in the highest performance tier as defined by ISA84/IEC61511.

But there's still that 4%, most or all of which should be covered by an external watchdog relay that has a contact in the ESD/MCR circuit. If your application has significant enough risk, the external watchdog may be a good idea.
We are building turbine controls based on ControlLogic PLC. Put a lot of thoughts to the issue. We are going for:
-energized to run trip solenoid(s);
-two PLCs involved. Control PLC plus Safety PLC. The control one runs the sequence, including over-speed protection, exhaust temp protection etc. The safety one runs only over-speed, exhaust temperatures, etc.
-With both PLCs three of their DOs are dedicated to run three trip relays wired in a two of three scheme. The relays have a feedback that goes to three DIs.
-trip solenoid is wired in series with both PLC trip relays.

Believe achieving the following:
-In a case either of the PLC malfunctions the other one is able to trip the unit independently.
-Two of three trip relays set-up gives enough protection against premature trip.

Can I have some comments please.