ESP32 Firmware for Manufacturing & Automation
On a factory floor, a missed deadline or a hung task is not a dropped sample, it is a moving axis that does not stop. We treat ESP32 firmware for machine control as a safety and timing problem first: bounded loops, watchdog-enforced fail-states, and isolation that survives a brownout. The result is firmware that degrades to a known-safe condition instead of a random one.
Challenges specific to Manufacturing & Automation
PWM glitches during firmware faults
A crashing or rebooting ESP32 can leave LEDC/MCPWM outputs floating or stuck high, slamming a VFD or servo to full command instead of coasting to a safe stop.
E-stop handled in software only
When the stop circuit runs through a GPIO ISR, a watchdog reset or stack overflow can delay or swallow the stop, violating the most basic machine-safety expectation.
Lost encoder counts under load
Software edge-counting on shared GPIO misses pulses during Wi-Fi bursts or interrupt storms, so position drifts and the machine indexes to the wrong station.
Ground loops corrupting 24V I/O
Sharing the ESP32 ground with VFD and contactor power injects switching noise and inrush transients that reset the MCU or false-trigger contactor inputs.
Non-deterministic loop timing
Blocking MQTT, NVS writes, or logging inside the control path stretches a 1 ms loop to tens of milliseconds, making closed-loop motion jittery and unrepeatable.
Unsafe state after power blip
Brownouts mid-write leave outputs and NVS in an undefined state, so the machine restarts mid-cycle with relays energized and no operator acknowledgment.
How GizanTech solves them
- Hardware-forced safe outputs. Drive motor commands through MCPWM with the fault input wired to force outputs low, plus external pull-downs so a hung or resetting ESP32 lands at zero command, not full speed.
- Hardwired E-stop with software echo. Route the E-stop through a hardware safety relay (Category 1/PLd style) that drops the contactor independent of the MCU; firmware only observes and reports the latched state over the bus.
- Hardware quadrature decoding. Use the ESP32 PCNT peripheral for glitch-filtered quadrature counting so encoder position survives Wi-Fi bursts and ISR load without losing pulses to CPU contention.
- Galvanic I/O isolation. Specify opto-isolated 24V inputs and isolated DC-DC for the MCU rail, breaking ground loops between logic and contactor/VFD power per IEC 61131-2 input thresholds.
- Core-pinned deterministic loop. Pin the control task to one FreeRTOS core with the network/telemetry stack on the other, keeping NVS and MQTT off the hot path so loop jitter stays within a bounded budget.
- Watchdog-enforced fail-state. Arm the task watchdog and brownout detector so any hang or power dip drives a defined reset-to-safe sequence: outputs de-energized, contactor open, fault flag persisted for operator reset.
| I/O type | Control-loop latency requirement | Fail-safe behavior on firmware crash | Isolation need |
|---|---|---|---|
| Motor drive (VFD/servo) | ≤ 1 ms PWM update, deterministic | MCPWM fault forces outputs low → drive coasts/ramps to stop | Isolated PWM/analog ref to drive ground |
| Relay / contactor | ≤ 10 ms actuation, debounced | Coil de-energizes on reset → contactor opens (normally-open) | Opto/relay isolation from 24V coil rail |
| Encoder / counter | Hardware PCNT, no missed edges | Count latched in peripheral, re-homed on restart | Differential/isolated for long cable runs |
| E-stop / interlock | Hardware-latched, < 1 ms to open | Safety relay drops independent of MCU; firmware echoes only | Fully isolated dual-channel safety loop |
Go deeper
ESP32 Firmware & IoT Development for other industries
Frequently asked questions
Can the ESP32 itself be the safety controller for an E-stop?
No. We keep the E-stop in a hardwired safety relay so the machine stops even if the firmware hangs; the ESP32 only monitors and reports the latched state for diagnostics and HMI.
How do you guarantee a deterministic control loop on Wi-Fi-connected firmware?
We pin the control task to one FreeRTOS core and isolate the networking stack on the other, keep NVS writes and MQTT off the hot path, and verify worst-case loop jitter with logic-analyzer traces under network load.
What happens to outputs when the firmware crashes or browns out?
Every output is designed to fail to a de-energized state: MCPWM fault inputs force PWM low, contactor coils drop on reset, and the brownout detector triggers a defined reset-to-safe sequence before recovery.
Will the firmware work with our existing PLC and VFD?
Yes. We integrate over Modbus RTU/TCP, analog 0-10V or 4-20mA references, and digital 24V I/O at IEC 61131-2 thresholds, so the ESP32 node sits alongside the PLC rather than replacing your safety chain.
How do you protect the ESP32 from VFD and contactor switching noise?
We galvanically isolate 24V inputs with optos, power the MCU from an isolated DC-DC, and separate logic and power grounds, which breaks the ground loops that cause spurious resets and false input triggers.
Do you provide OTA updates on machines that cannot be stopped?
Yes, with A/B partitions and rollback, and we gate updates so they only apply when the machine reports an idle/safe state, never mid-cycle, with automatic revert if the new image fails its post-boot self-check.