PLC Watchdog Timers: Detect the Scan That Did Not Finish in Time

A cyclic PLC program is repeatedly scheduled by the runtime. On a simple controller, engineers often call one complete repetition the scan. On a controller with several tasks, each task has its own period, priority and execution budget. A ten-millisecond motion task and a one-hundred-millisecond supervisory task can therefore have different watchdogs and different consequences. Before diagnosing an overrun, record the exact task name, type, configured period, priority, watchdog, firmware and program calls assigned to it.

The watchdog normally measures elapsed task execution from task start until its configured programs finish. Elapsed time may include pre-emption by higher-priority work depending on the platform. That means a task can overrun even when its own logic did not change: a new high-priority task, communication load, motion processing or runtime service can consume the available wall-clock budget. Conversely, average task time can look healthy while one rare data path exceeds the limit.

Do not confuse this with an ordinary TON instruction. A TON models process time while the PLC continues scanning. A task watchdog is enforced by the runtime when execution is late. A communications watchdog supervises stale or missing messages. An external hardware watchdog may supervise whether the controller itself is alive. Each answers a different question and produces different diagnostic and output behavior.

Do not write “the outputs turn off” as a universal watchdog rule. Output behavior depends on controller state, I/O ownership, module fault action, produced data, network connection response and any configured fault program. A physical output may also remain energized through interposing hardware or stored energy after the controller command changes. The safety assessment and electrical design must define the required response independently of ordinary software assumptions.

Fault handlers require restraint. A handler can save evidence, place ordinary logic into a documented state or support an approved recovery path. It must not repeatedly clear an overrun while the same unbounded path remains active. Some platforms escalate repeated watchdogs, and an automatic clear can hide a machine that is no longer executing its intended control interval.

Recovery begins from physical truth: identify which actuators moved, which state was retained, whether commands remain present and whether sequence data is coherent. Clear the initiating demand before returning the controller to run. Reinitialize only the state that the recovery design specifies; resetting every tag can destroy evidence or create an unplanned process transition.

Measure first. Capture task execution across representative production, startup, changeover, fault and recovery conditions. Include the largest supported recipes and the intended number of communication clients. Use the maximum and distribution, not only the average. If maximum time is still climbing during the test, the sample has not established a stable bound.

Then define margin based on variability and process consequence. A threshold only slightly above a noisy maximum creates nuisance stops; a value hundreds of times the normal scan can allow a stalled control loop to persist too long. The correct number balances scheduler variation against the maximum tolerable loss of timely control and the platform fault response.

Document why the number is acceptable, who approved it and which test supports it. Treat a watchdog increase as a control change requiring review. If the program begins overrunning after a release, raising the limit may merely convert a visible fault into slower, less deterministic control.

Make every loop visibly bounded. Validate array limits before iteration, reject malformed lengths and avoid waiting inside a scan for external state. For algorithms that may process large collections, use a stateful worker that handles a fixed number of elements per cycle and exposes progress, completion and error states.

Separate fast control from slow support work. Motion, interlocks and critical process control need predictable tasks; reports, recipes, diagnostics and noncritical communication can often run at lower priority or in staged services. Shared data then needs an explicit consistency strategy so moving work does not create races or half-updated structures.

Treat timing like memory or I/O capacity: budget it, observe it and regression-test it. Record maximum task times for a known scenario set before release. Flag meaningful growth even when it remains below the watchdog, because disappearing margin is the earliest warning that the next feature may cross the boundary.