The short answer
Watchdog Faults
A watchdog fault means a task ran longer than the time the controller was told to allow it, and the controller faulted rather than let the process run on stale logic. The cause is always that the task took too long, and the reasons are a program that has grown, a loop that iterated more than intended, an instruction that is slow on that platform, such as a string or array operation on a large array, communications servicing that stole the processor, or a task period and watchdog set without margin when the program was small. The fix is to measure the task time, find what grew, and either make the logic cheaper, move it to a slower task, or, when the time is legitimately needed, raise the watchdog with the reason documented. Raising the watchdog without knowing why the task got slow is turning off the alarm.
Key points
- The watchdog fault says the task exceeded its allowed time; the question is what took the time.
- Measure: last, maximum, and average task execution time from the controller diagnostics.
- Loops, large array and string operations, and indirect addressing are the usual slow instructions.
- Communications servicing competes with logic for the processor on many platforms.
- Raise the watchdog only with a measured reason and a documented margin; otherwise fix the logic.
What it protects
The watchdog is a timer that the task must reset by finishing. If the task does not finish, something has gone wrong that the program cannot detect from inside: an infinite loop, a hardware fault, or a load the design never anticipated. Rather than keep the outputs in whatever state the last complete scan left them, while the logic that should be updating them is stuck, the controller faults and drops the outputs to their safe state. The fault is inconvenient; the alternative is a pump running with no logic watching it.
Why the task got slow
| Cause | How it shows | Fix |
|---|---|---|
| Program growth | Task time creeping up over months of additions | Move logic to periodic tasks with longer periods; remove dead code |
| A loop that runs long | Task time jumps when a condition is true | Bound the iteration count; check the exit condition |
| Large array or string operations | Time spent in a few instructions | Process arrays in slices; avoid string handling in fast tasks |
| Indirect addressing and computed indexes | Slow on some platforms | Direct addressing where the index is constant |
| Communications load | Task time rises when SCADA or programming sessions connect | Raise the communication time slice deliberately, or reduce the clients |
| Too many periodic tasks | Tasks preempting each other; the lowest priority starves | Rationalize task periods and priorities |
| Firmware or hardware | Task time rises after an update or on one controller only | Check release notes; test the hardware |
| A watchdog set too tight | Fault at the first busy moment with normal times close to the limit | Set the watchdog from measured maximum time with margin |
Measuring
- 1
Read the task times
The controller reports last, maximum, and often average execution time per task. Clear the maximum and watch it through a busy period.
- 2
Compare with the period and watchdog
A periodic task should finish well inside its period; a continuous task should scan within what the process needs. A maximum near the watchdog is the problem even before it faults.
- 3
Find the expensive routines
Some platforms report time per routine; where they do not, disable routines one at a time in a test or add timestamps at routine boundaries to a diagnostic tag.
- 4
Correlate
Task time against communications activity, against a sequence step, against an operator action, to catch the loop or the condition that triggers the growth.
- 5
Trend it
Move the maximum task time to a tag, historize it, and alarm at a fraction of the watchdog. A watchdog fault should never be the first warning.
Watchdog ≥ T_max × 1.5, and T_max ≤ 0.6 × Period
- T_max = measured maximum task execution time under load
- Period = the task period for a periodic task
- Margins are a starting point; document the values chosen
After the fault
The fault dropped the outputs, the process is in its fail state, and the restart puts every output back on the first scan according to the logic. Before clearing, read the fault record and the task times, note which task and how long, and look at what was happening. Then restart with operators ready for what starts. If the cause is not found, the controller runs with a task time trend and an alarm until it is; a fault that happened once will happen again, and the second time it should be caught before the watchdog does.
Frequently asked questions
- The task time is normally 8 milliseconds and the watchdog is 500. How did it fault?
- Something took 500 milliseconds once: a loop with a condition that let it run thousands of times, a string operation on a large array, or a communications burst on a platform that services communications inside the task. The maximum time and the fault record show which task; the correlation shows what triggered it.
- Does a faster processor fix it?
- It buys time, and it hides a loop that will still run away. Fix the logic first; upgrade when the program legitimately needs more capacity.
- Should the fault handler clear a watchdog fault?
- No. A watchdog fault means the program did not complete; clearing it and continuing means running with outputs that a stuck task may not have updated. Stop, alarm, and restart under control.
- Why does the task time rise when the programming laptop connects?
- The controller services the programming session from the same processor and, on many platforms, from a time slice inside the scan. Online monitoring of many tags, cross-reference searches, and uploads all add load. Go offline when not editing, and set the communication time slice deliberately.
Related topics
- The Watchdog TimerWhat the scan watchdog protects against, why it faults the controller instead of pausing it, what makes a scan run long, and why raising the limit is the wrong first response.
- Tasks and Execution PriorityHow a controller schedules its work: the continuous task, periodic tasks at a fixed rate, event tasks triggered by something happening, how priority preempts, and where each kind of logic belongs.
- The PLC Scan CycleRead inputs, solve logic, write outputs, housekeeping. Understanding scan order explains most PLC behavior that looks wrong at first glance.
- Program FaultsFaults the program causes: an index out of range, division by zero, an invalid indirect address, a missing routine, a type mismatch, or task overlap. Reading the fault record, what a fault handler should do, clearing safely, and logic that does not fault.
- Processor FaultedA PLC with its fault light on and no logic running. How to read what it is telling you, the causes in order of likelihood, and how to restart it without repeating the fault.
- Program OrganizationStructuring a controller program so that someone else can maintain it: a layout that follows the plant, one routine per job, standard device blocks, I/O mapped in one place, a fixed execution order, naming that means something, and comments that say why.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.