6 Actuator Safety: Protection and Fail-Safe Design

6.1 Start With the Decision

A jammed vent can heat its driver while the screen still says closing. The safe stop must work when sensing or code fails.

6.2 Route Overview

This is part 1 of 2. Continue with Actuator Safety: Watchdogs and Interlocks.

6.3 Part Objectives

• Choose flyback, limits, thermal protection, and safe state.
• Separate high-voltage work from low-voltage control.

6.4 Start With the Story

Design the Stop Before the First Motion

Picture a motor closing a greenhouse vent when its shaft jams halfway. The screen may still show “closing” while the driver heats and the plants lose airflow. The safe design begins with what must happen when motion, sensing, software, or power fails.

An actuator is a device that changes the physical world. Firmware means the software stored on a device. Name the moving part, people and equipment within reach, safe resting state, energy source, hardware limit, manual stop, position evidence, and owner of recovery. Put the highest-consequence stop outside the ordinary software path.

Jam the motion, remove position feedback, freeze the firmware, lose communication, interrupt power, and restart. Check that energy is limited or removed, the mechanism reaches or reports a safe state, repeated commands do not create new motion, and the operator can tell a stopped system from a completed action.

This test does not certify machinery or replace local safety law. The deeper sections show driver protection, stored energy, current and heat limits, isolation, watchdogs, emergency stops, and fail-safe review for the full output path.

Start with the uncomfortable version of the demo: the valve sticks open, the motor jams, the relay welds, the firmware freezes, or power disappears while a mechanism is moving. Actuator safety is the plan for that moment, not an afterthought after the circuit works once.

Every output path needs a safe default, a protected driver, and a way to stop or detect unsafe action. The stronger the physical consequence, the more the design must rely on hardware limits and evidence, not just good intentions in code.

6.5 Actuator Safety Considerations

This list is the safety inventory. The first detailed mechanism is the one every relay, solenoid, and motor driver must answer: where does the stored magnetic energy go when the switch opens?

6.6 Flyback Diode Protection

The photographs below make diode (rectifier / protection) a physical comparison: look for changes in package, exposed interfaces, mounting, scale, and service access before treating the forms as interchangeable.

Read across the forms as engineering evidence. They share a capability name, but packaging and installation change the electrical, mechanical, environmental, and maintenance constraints.

When you switch off an inductive load (motor, relay, solenoid), the collapsing magnetic field generates a high voltage spike that can destroy transistors and microcontrollers.

6.6.3 Example Protection Circuits

Load	Diode
Small relay (5V, 50mA)	1N4148
Motor (12V, 1A)	1N5819 Schottky
Solenoid (24V, 2A)	1N5408 + TVS

Before choosing a part number, inspect Figure to connect the table’s ratings to the physical two-terminal clamp that must sit across the inductive load. Orientation matters because the diode must be reverse-biased during normal energisation.

In Figure, identify the axial leads and the marked cathode end, then map them to the coil terminals in the protection circuit. When the driver opens, stored magnetic energy drives current through this local loop instead of forcing a destructive voltage across the transistor or GPIO.

Common Pitfall: Ignoring Back-EMF and Flyback Voltage

The mistake: Omitting flyback diodes when controlling inductive loads, leading to voltage spikes that destroy transistors or microcontrollers.

Symptoms:

• Random microcontroller resets
• Brown-out resets during motor switching
• Transistor driver fails after days/weeks of operation
• Scope shows large negative voltage spikes when load switches off

The fix: NEVER connect any inductive load without a flyback diode. Add protection during initial prototyping, not as an afterthought.

Checkpoint: Flyback Protection

You now know:

• The spike comes from V = -L x (di/dt), so faster current interruption makes the voltage larger.
• The worked relay example stores 0.32 mJ and can calculate an 8000 V ideal spike from 100 mH, 80mA, and 1 us.
• The protection choice is physical: put the flyback diode across the inductive load before the first live driver test.

Phoebe’s Field Notes: Why The Clamp Barely Moves At 80 mA

The mathematical gist. For the same diode at fixed temperature, $V_2-V_1=nV_T\ln(I_2/I_1)$. Using the labelled 0.650 V at 10.0 mA reference, $n=1$, and $V_T=25.85$ mV, this chapter’s 80 mA case adds 53.8 mV and predicts 0.704 V. That is 8.3% above the reference voltage, or 7.6% of the final clamp; the logarithm, not a fixed ideal constant, explains “about 0.7 V.”

Math Bridge · guided foundationsWhy does eight times the current add only about 54 mV?Let Max unpack the logarithm behind the chapter's 0.7 V flyback clamp. Learn the maths

Once the driver is protected electrically, the next failure is liveness. The controller must not keep an actuator energized just because firmware stopped making progress.

6.7 Watchdog Timer for Safety

Read the example from watchdog configuration to periodic reset, actuator command, and forced restart. The reset is useful only when startup code immediately establishes the defined safe output state; a watchdog complements local interlocks and current protection rather than replacing them.

If your control software hangs, actuators could be left in dangerous states. A watchdog timer automatically resets the system.

#include <esp_task_wdt.h>

#define WDT_TIMEOUT 3  // 3 seconds

void setup() {
  Serial.begin(115200);

  // Configure watchdog timer
  esp_task_wdt_init(WDT_TIMEOUT, true);
  esp_task_wdt_add(NULL);

  pinMode(RELAY_PIN, OUTPUT);
}

void loop() {
  // Reset watchdog timer (must be called every <3 seconds)
  esp_task_wdt_reset();

  // Control actuators
  controlActuators();

  delay(1000);
}

void controlActuators() {
  // If this function hangs, watchdog will reset the system
  digitalWrite(RELAY_PIN, HIGH);
  delay(500);
  digitalWrite(RELAY_PIN, LOW);
}

Checkpoint: Watchdog Timing

You now know:

• A watchdog is a hardware deadline, not a patient software monitor.
• If a normal loop is 80 ms, a 100 ms watchdog can still be too tight when one iteration takes 150 ms.
• Slow logging, networking, and storage work should be decoupled so the critical control loop can feed the watchdog before the actuator hazard time expires.

Software recovery still cannot make high voltage safe by itself. The next section shifts from firmware liveness to isolation, ratings, wiring, and code compliance.

6.8 High-Voltage Safety

6.9 Design Scenario: Smart Thermostat Fail-Safe Behavior

Consider a connected thermostat that controls a heating relay, runs from a low-voltage control supply, and has a small backup battery for short interruptions. A firmware bug, weak battery, loose terminal, or failed power supply can still leave the thermostat unable to command the heating system. The safety issue is not the brand of controller; it is the architecture: one smart device has become the only path between a cold building and a working furnace.

What can go wrong:

If the controller loses power, the display goes dark, the network connection disappears, and cloud notifications stop. If the relay coil is normally open, the relay opens when the thermostat is dead. That is usually safe for an electric heater because “off” prevents overheating, but it can be unsafe for a freeze-protection load where a minimum temperature must be maintained.

Why the damage can be severe — a fail-safe design failure:

The thermostat is the sole controller for the HVAC system. When it loses power:

The fundamental problem is that “safe” depends on the hazard. A normally open heating relay makes loss of control equal to furnace OFF. In summer, that prevents overheating. In a freeze-protection application, it can be the wrong safe state because the building needs enough heat to protect pipes and occupants.

What good fail-safe design would have done:

1. Battery health monitoring with early warning: Alert locally and remotely while there is still enough energy to communicate, not only after complete failure.

2. Independent low-temperature fallback: A simple mechanical or independent electronic thermostat can be wired so heating starts at a low protective setpoint even if the smart controller is offline.

3. Last-gasp communication: Before the battery dies, use remaining power to send one final local or network alert: “Battery critical — heating control may be disabled.”

4. Relay selection: For heating-critical installations in cold climates, use a latching relay that maintains its last state without power. If the thermostat was calling for heat when it died, the furnace continues running until manual intervention. Trade-off: risk of overheating vs. risk of freezing.

Outcome: The design review changes from “does the app control heat?” to “what protects the building if the app, controller, supply, or network is gone?”. That answer often requires an independent fallback, not just better firmware.

Key design lesson for IoT actuator systems: Never make a smart controller the single point of failure for a safety-critical system. Always provide a mechanical or independent electronic fallback that maintains minimum safe conditions when software, power, or connectivity fails.

6.10 Common Pitfalls

6.11 Continue to the Next Part

Carry this evidence into Actuator Safety: Watchdogs and Interlocks, which begins with Watchdog Timeout Sizing.