Firmware ESP32 para fabricación y automatización
En una planta de producción, un plazo incumplido o una tarea bloqueada no es una muestra perdida: es un eje en movimiento que no se detiene. Tratamos el firmware ESP32 para control de máquinas ante todo como un problema de seguridad y temporización: bucles acotados, estados de fallo impuestos por watchdog y aislamiento que sobrevive a un brownout. El resultado es un firmware que se degrada a una condición segura conocida en lugar de a una aleatoria.
Challenges specific to Manufacturing & Automation
Fallos de PWM durante errores de firmware
Un ESP32 que se bloquea o reinicia puede dejar las salidas LEDC/MCPWM flotantes o fijas en alto, llevando un VFD o servo al comando máximo en lugar de detenerse de forma segura por inercia.
Paro de emergencia gestionado solo por software
Cuando el circuito de paro pasa por una ISR de GPIO, un reinicio del watchdog o un desbordamiento de pila pueden retrasar o anular el paro, violando la expectativa más básica de seguridad de máquinas.
Pérdida de conteo del encoder bajo carga
El conteo de flancos por software en un GPIO compartido pierde pulsos durante ráfagas de Wi-Fi o tormentas de interrupciones, por lo que la posición deriva y la máquina indexa a la estación equivocada.
Bucles de tierra que corrompen la E/S de 24V
Compartir la tierra del ESP32 con la alimentación del VFD y del contactor inyecta ruido de conmutación y transitorios de arranque que reinician el MCU o disparan falsamente las entradas del contactor.
Temporización de bucle no determinista
Bloquear con MQTT, escrituras en NVS o registro dentro de la ruta de control estira un bucle de 1 ms a decenas de milisegundos, haciendo el movimiento en lazo cerrado irregular e irrepetible.
Estado inseguro tras un microcorte
Los brownouts a mitad de escritura dejan las salidas y la NVS en un estado indefinido, por lo que la máquina reinicia a mitad de ciclo con los relés energizados y sin confirmación del operador.
How GizanTech solves them
- Salidas seguras forzadas por hardware. Comandamos los motores a través de MCPWM con la entrada de fallo cableada para forzar las salidas a nivel bajo, más resistencias pull-down externas, de modo que un ESP32 bloqueado o en reinicio quede en comando cero, no a máxima velocidad.
- Paro de emergencia cableado con eco por software. Encaminamos el paro de emergencia a través de un relé de seguridad por hardware (estilo Categoría 1/PLd) que abre el contactor de forma independiente del MCU; el firmware solo observa y reporta el estado enclavado por el bus.
- Decodificación de cuadratura por hardware. Usamos el periférico PCNT del ESP32 para conteo de cuadratura con filtrado de glitches, de modo que la posición del encoder sobreviva a ráfagas de Wi-Fi y carga de ISR sin perder pulsos por contención de CPU.
- Aislamiento galvánico de E/S. Especificamos entradas de 24V optoaisladas y un DC-DC aislado para el riel del MCU, rompiendo los bucles de tierra entre la lógica y la alimentación del contactor/VFD según los umbrales de entrada de IEC 61131-2.
- Bucle determinista anclado a núcleo. Anclamos la tarea de control a un núcleo de FreeRTOS con la pila de red/telemetría en el otro, manteniendo NVS y MQTT fuera de la ruta crítica para que la fluctuación del bucle se mantenga dentro de un presupuesto acotado.
- Estado de fallo impuesto por watchdog. Activamos el watchdog de tareas y el detector de brownout para que cualquier bloqueo o caída de tensión active una secuencia definida de reinicio a estado seguro: salidas desenergizadas, contactor abierto y bandera de fallo persistida para el rearme del operador.
| Tipo de E/S | Requisito de latencia del bucle de control | Comportamiento a prueba de fallos ante caída del firmware | Necesidad de aislamiento |
|---|---|---|---|
| Accionamiento de motor (VFD/servo) | Actualización PWM ≤ 1 ms, determinista | El fallo MCPWM fuerza las salidas a bajo → el accionamiento se detiene por inercia/rampa | Referencia PWM/analógica aislada respecto a la tierra del accionamiento |
| Relé / contactor | Actuación ≤ 10 ms, con antirrebote | La bobina se desenergiza al reiniciar → el contactor abre (normalmente abierto) | Aislamiento opto/relé del riel de bobina de 24V |
| Encoder / contador | PCNT por hardware, sin flancos perdidos | Conteo enclavado en el periférico, rehoming al reiniciar | Diferencial/aislado para tendidos de cable largos |
| Paro de emergencia / enclavamiento | Enclavado por hardware, < 1 ms para abrir | El relé de seguridad abre independiente del MCU; el firmware solo hace eco | Bucle de seguridad de doble canal totalmente aislado |
Go deeper
ESP32 Firmware & IoT Development for other industries
Frequently asked questions
¿Puede el propio ESP32 ser el controlador de seguridad de un paro de emergencia?
No. Mantenemos el paro de emergencia en un relé de seguridad cableado para que la máquina se detenga incluso si el firmware se bloquea; el ESP32 solo monitorea y reporta el estado enclavado para diagnóstico y la HMI.
¿Cómo garantizan un bucle de control determinista en firmware conectado por Wi-Fi?
Anclamos la tarea de control a un núcleo de FreeRTOS y aislamos la pila de red en el otro, mantenemos las escrituras de NVS y MQTT fuera de la ruta crítica, y verificamos la fluctuación de bucle en el peor caso con trazas de analizador lógico bajo carga de red.
¿Qué les ocurre a las salidas cuando el firmware se cae o sufre un brownout?
Cada salida está diseñada para fallar a un estado desenergizado: las entradas de fallo MCPWM fuerzan el PWM a bajo, las bobinas del contactor caen al reiniciar, y el detector de brownout dispara una secuencia definida de reinicio a estado seguro antes de la recuperación.
¿Funcionará el firmware con nuestro PLC y VFD existentes?
Sí. Integramos sobre Modbus RTU/TCP, referencias analógicas 0-10V o 4-20mA y E/S digital de 24V con umbrales IEC 61131-2, de modo que el nodo ESP32 convive junto al PLC en lugar de reemplazar su cadena de seguridad.
¿Cómo protegen el ESP32 del ruido de conmutación del VFD y del contactor?
Aislamos galvánicamente las entradas de 24V con optoacopladores, alimentamos el MCU desde un DC-DC aislado y separamos las tierras de lógica y potencia, lo que rompe los bucles de tierra que causan reinicios espurios y disparos falsos de entrada.
¿Ofrecen actualizaciones OTA en máquinas que no se pueden detener?
Sí, con particiones A/B y reversión, y condicionamos las actualizaciones para que solo se apliquen cuando la máquina reporta un estado inactivo/seguro, nunca a mitad de ciclo, con reversión automática si la nueva imagen falla su autodiagnóstico posterior al arranque.