7 Actuator Safety: Watchdogs and Interlocks

7.1 Start With the Decision

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 is part 2 of 2. Review Actuator Safety: Protection and Fail-Safe Design for the preceding evidence.

7.3 Learning Objectives

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

7.4 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_init(150, true);  // 150ms timeout, panic on trigger
esp_task_wdt_add(NULL);         // Add current task to WDT

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: Watchdog timeout → system reset → safe state
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: Any power/communication loss → relay opens → solenoid releases → spring opens vent

Vent motor: Powered to close, unpowered to open (spring-return)
Relay: Normally-Closed (NC) supplies power to motor
Normal operation: IoT de-energizes relay when T > 35°C → motor loses power → spring opens vent
Failure: Power loss → relay defaults to closed → motor loses power → spring opens vent

// ESP32: Set pull-down in bootloader (before setup())
// Edit sdkconfig or platformio.ini:
CONFIG_GPIO_PULLDOWN_GPIO25=y
CONFIG_GPIO_PULLDOWN_GPIO26=y
// ... for all relay control pins

7.5 Fail-Safe Design Principles

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

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 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 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 draws only 3.3 V / 10000 ohm = 0.33 mA, but it defines the input while firmware is not yet running. Across eight relay outputs, that is 8 x 0.33 mA = 2.64 mA, a tiny standby cost compared with valves or motors energizing during reset. 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

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

7.9 Quiz: Actuator Safety

7.10 Concept Relationships

7.11 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?

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

7.13 Continue Your Route

This final part closes the route from Watchdog Timeout Sizing through Code Challenge. Return to Actuator Safety: Protection and Fail-Safe Design or continue from the actuators module index.