7 Actuator Safety: Watchdogs and Interlocks

7.1 Start With the Decision

This section: Start With the Decision — A watchdog is a timer that detects a control loop that stops making progress.

A watchdog is a timer that detects a control loop that stops making progress. A control loop repeats the steps that read inputs and command motion. An interlock blocks motion when a safety condition is not met. A watchdog that trips too soon stops sound work; one set too late lets harm grow. Its limit must follow measured loop time.

7.2 Route Overview

This section: Route Overview — This is part 2 of 2.

This is part 2 of 2. Review Actuator Safety: Protection and Fail-Safe Design for the preceding evidence.

7.3 Learning Objectives

This section: Learning Objectives

• Calculate a watchdog timeout from task and bus delays.
• Design relay boot states, interlocks, and stall protection.

7.4 Chapter Roadmap

This section: Chapter Roadmap

• Watchdog Timeout Sizing
• Fail-Safe Relay Setup
• Pull-Downs on Relay Boot
• Fail-Safe Design Principles
• Deep Dive: Failure Energy, Interlocks, and Stall Protection
• Checkpoint: Fault Energy
• Summary
• Key Takeaway
• For Kids: Meet the Actuator Crew!
• Knowledge Check
• Quiz: Actuator Safety
• Concept Relationships
• See Also
• What’s Next?
• Label the Diagram
• Code Challenge

// BEFORE: Unsafe monolithic loop
void control_loop() {
    read_sensors();        // 5ms
    calculate_path();      // 20ms
    send_motor_commands(); // 15ms
    wait_for_feedback();   // 30ms
    verify_grip();         // 5ms
    log_to_sd();          // 10-250ms <-- PROBLEM!
    feed_watchdog();
}

// AFTER: Two-tier architecture
void critical_control_loop() {  // Runs every 100ms
    read_sensors();             // 5ms
    calculate_path();           // 20ms
    send_motor_commands();      // 15ms
    wait_for_feedback();        // 30ms
    verify_grip();              // 5ms
    queue_log_event();          // <1ms (just adds to queue)
    feed_watchdog();            // WDT timeout = 150ms (100ms × 1.5)
}

void background_logger() {      // Runs in lower-priority task
    if (log_queue_not_empty()) {
        write_to_sd_card();     // 10-250ms (doesn't block control)
    }
}

esp_task_wdt_config_t cfg = { .timeout_ms = 150, .idle_core_mask = 0, .trigger_panic = true };
esp_err_t wdt_result = esp_task_wdt_init(&cfg);  // ESP-IDF 5.x; call after the scheduler starts
if (wdt_result == ESP_ERR_INVALID_STATE) {
    wdt_result = esp_task_wdt_reconfigure(&cfg);  // Already initialized
}
if (wdt_result != ESP_OK) {
    // Handle configuration failure; do not claim the watchdog is active.
    return;
}
wdt_result = esp_task_wdt_add(NULL);  // Add current task to WDT
if (wdt_result != ESP_OK) {
    // Handle subscription failure before relying on the watchdog.
    return;
}

while (1) {
    critical_control_loop();     // Must complete in <150ms
    esp_task_wdt_reset();        // Feed watchdog
}

Test 1: Disconnect power to IoT controller
Expected: Actuator moves to safe state
Pass/Fail: ___

Test 2: Disconnect network (Wi-Fi, Ethernet)
Expected: A separate communication-loss timer or local fallback moves the actuator to its defined safe state; a task watchdog need not expire while firmware is still running.
Pass/Fail: ___

Test 3: Force microcontroller crash (trigger WDT)
Expected: Hardware reset → relay de-energizes → safe state
Pass/Fail: ___

Test 4: Remove relay coil power wire
Expected: Relay de-energizes → safe state
Pass/Fail: ___

Vent motor: Powered to open, unpowered to close
Relay: Normally-Open (NO)
Failure behavior: Power loss → relay open → motor unpowered → vent CLOSES → crops overheat

Vent motor: Spring-loaded to open position
Relay: Normally-Open (NO) controls solenoid that holds vent CLOSED
Normal operation: IoT energizes relay when T < 35°C → solenoid holds vent closed
Failure: Loss of relay-coil power opens the relay and releases the solenoid; a separate communication-loss timer or local fallback is needed for network outages. The spring opens the vent if actuator power is lost.

Vent motor: Powered to close, unpowered to open (spring-return)
Alternative (controller/coil-power loss only): An NC contact supplies a powered-to-open actuator from an independent motor supply. When relay-coil power is lost, NC closes and powers the motor open. If motor power also fails, this cannot guarantee opening; add spring return for all-power-loss fail-open behavior.

gpio_pulldown_en(GPIO_NUM_25);  // Post-startup only; external bias holds the pin during reset

7.5 Fail-Safe Design Principles

This section: Fail-Safe Design Principles — Those principles become concrete when you translate failure into energy, travel distance, and timeout.

1. Default State: All actuators should power up in a safe state

   • Valves: Closed (prevents flooding)
   • Heaters: Off (prevents overheating)
   • Motors: Stopped (prevents injury)

2. Power Loss Behavior: Consider what happens during power outage

   • Use normally-closed relays for safety-critical shutoffs
   • Spring-return valves for fail-safe closing

3. Communication Loss: If IoT device loses connection:

   • Implement timeout to safe state
   • Local fallback logic
   • Visual/audio warning

4. Sensor Failure: If feedback sensor fails:

   • Detect out-of-range readings
   • Switch to open-loop with limits
   • Alert user

Those principles become concrete when you translate failure into energy, travel distance, and timeout. The deep dive below is the evidence pass for that translation.

7.6 Deep Dive: Failure Energy, Interlocks, and Stall Protection

This section: Deep Dive: Failure Energy, Interlocks, and Stall Protection — Inspect Figure 7.1 to put local hazard evidence ahead of network control.

Actuators move real things, so the central safety question is not only “does it work?” but “what does it do when a wire falls off, the code hangs, or the load jams?” Good actuator safety starts by defining the least harmful physical state for the specific hazard: stopped, released, clamped, vented, open, closed, or isolated. A heater usually fails safe by turning off. A greenhouse vent may fail safe by opening. A fire-exit lock may fail safe by unlocking. A laboratory exhaust damper may fail safe by opening, even though a security door may fail safe by locking.

Inspect Figure 7.1 to put local hazard evidence ahead of network control. The useful reading order is physical status, interlock decision, and forced operating mode, because a remote command must never bypass a guard or emergency stop.

+

Read Figure 7.1 from equipment status and guard position into the interlock, then compare normal operation, guard-open stop, emergency stop, and maintenance lock-down. Each unsafe condition forces a bounded local response; that hierarchy connects the safe-state choice to the energy and travel calculations below.

Work the failure case with numbers. Suppose a 24 V ventilation actuator draws 0.4 A while holding a damper shut, so the coil consumes 24 V x 0.4 A = 9.6 W. If the controller must keep that coil energized to hold the safe state, a power loss removes the energy needed for safety. A spring-return design reverses the dependency: the controller spends 9.6 W during normal closed operation, and loss of power releases the spring so the damper opens. The same calculation applies to a water valve: a 12 V solenoid drawing 0.6 A dissipates 12 V x 0.6 A = 7.2 W while energized, so continuous hold current is both an energy budget and a thermal safety concern.

Fail-safe design also asks how much motion can occur after the controller has lost authority. A small linear actuator moving at 0.05 m/s travels 0.05 m/s x 2 s = 0.10 m during a two-second software hang unless a limit switch, current limit, or watchdog stops it. A conveyor moving at 0.5 m/s travels the same 0.10 m in only 200 ms, so a cloud timeout or app command is too slow for personnel protection. Hardware defaults come first, local controls second, and network supervision last.

Two design choices carry much of the fail-safe weight. Choose normally-open or normally-closed contacts so that de-energized means safe for that hazard: a brake that clamps when unpowered, or a valve that closes when unpowered, fails safer than a control path that needs healthy firmware. Put the E-stop in the power path, not in software; it must cut actuator power even if the microcontroller is locked up.

Size protection around the fault, not just the normal load. If a 12 V door actuator normally draws 1.5 A, its running power is 12 V x 1.5 A = 18 W. If the mechanism jams and stall current reaches 6 A, the wiring, driver, and fuse must account for a 12 V x 6 A = 72 W fault. A practical design uses driver current limiting near the allowed peak, a fuse for wiring faults, and firmware that cuts drive if high current persists beyond the expected acceleration window.

Bias every control input into its safe state. A relay board driven from a 3.3 V GPIO should not float while the controller boots. A 10 kOhm pull-down defines the input while firmware is not yet running. When GPIO drives HIGH, it draws about 0.33 mA per pin; at LOW or high impedance it draws negligible DC current. Across eight outputs, all pins driven HIGH draw up to 2.64 mA. For high-current drivers, apply the same rule to the enable pin: hardware should hold it disabled until firmware explicitly proves it is healthy.

Choose watchdog timing from the mechanical hazard. If the critical loop normally completes in 80 ms and has a measured worst case of 120 ms, a 200 ms watchdog leaves margin. But if the actuator can cause damage after 150 ms of uncontrolled motion, the software architecture must change; slow logging or network work belongs in a background task. A watchdog is useful only when its timeout is shorter than the physical hazard time and the reset state actually removes actuator energy.

7.7 Summary

This section: Summary — Actuator safety is about limiting energy when hardware, firmware, communication, or users behave unexpectedly.

Actuator safety is about limiting energy when hardware, firmware, communication, or users behave unexpectedly. Good designs combine electrical protection, mechanical limits, watchdogs, safe defaults, and clear manual override paths before the actuator is connected to a real load.

7.8 Knowledge Check

This section: Knowledge Check

7.9 Quiz: Actuator Safety

This section: Quiz: Actuator Safety

7.10 Concept Relationships

This section: Concept Relationships

7.11 See Also

This section: See Also

• Relays and Solenoids - Flyback protection for inductive loads
• DC Motors - Motor driver thermal management
• Actuator Labs - Implement watchdog timers in projects
• PWM Control - Avoid overcurrent with soft-start
• Actuator Assessment - Safety troubleshooting guide

7.12 What’s Next?

This section: What’s Next? — Now that you can apply safety protections to actuator circuits, explore related topics to deepen your practical skills.

Now that you can apply safety protections to actuator circuits, explore related topics to deepen your practical skills.

7.13 Continue Your Route

This section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to Actuator Safety: Protection and Fail-Safe Design or continue from the actuators module index.