ESP32-Firmware für Fertigung & Automatisierung
In der Fertigung ist eine verpasste Deadline oder eine hängende Task kein verlorenes Messsample, sondern eine bewegte Achse, die nicht stoppt. Wir behandeln ESP32-Firmware für die Maschinensteuerung zuerst als Sicherheits- und Timing-Problem: begrenzte Regelkreise, watchdog-erzwungene Fail-States und eine Isolation, die einen Brownout übersteht. Das Ergebnis ist Firmware, die in einen bekannten sicheren Zustand übergeht statt in einen zufälligen.
Challenges specific to Manufacturing & Automation
PWM-Störimpulse bei Firmware-Fehlern
Ein abstürzender oder neu startender ESP32 kann LEDC-/MCPWM-Ausgänge floatend oder dauerhaft High hinterlassen und so einen VFD oder Servo auf Vollbefehl treiben, statt sicher auslaufen zu lassen.
Not-Aus nur in Software behandelt
Läuft der Stop-Kreis über eine GPIO-ISR, kann ein Watchdog-Reset oder Stack-Überlauf den Stopp verzögern oder verschlucken und damit die grundlegendste Maschinensicherheitsanforderung verletzen.
Verlorene Encoder-Zählwerte unter Last
Software-Flankenzählung an gemeinsam genutzten GPIO verliert Impulse bei Wi-Fi-Bursts oder Interrupt-Stürmen, sodass die Position driftet und die Maschine zur falschen Station indexiert.
Erdschleifen verfälschen 24V-I/O
Wird die ESP32-Masse mit VFD- und Schützversorgung geteilt, koppeln Schaltrauschen und Einschaltstromtransienten ein, die die MCU zurücksetzen oder Schützeingänge fälschlich auslösen.
Nicht-deterministisches Loop-Timing
Blockierendes MQTT, NVS-Schreibvorgänge oder Logging im Steuerpfad dehnen einen 1-ms-Loop auf zig Millisekunden aus und machen die geschlossene Bewegungsregelung ruckelig und nicht reproduzierbar.
Unsicherer Zustand nach Spannungseinbruch
Brownouts mitten im Schreibvorgang lassen Ausgänge und NVS in einem undefinierten Zustand zurück, sodass die Maschine mitten im Zyklus mit angezogenen Relais und ohne Bedienerquittierung neu startet.
How GizanTech solves them
- Hardware-erzwungene sichere Ausgänge. Motorbefehle werden über MCPWM angesteuert, dessen Fault-Eingang die Ausgänge zwangsweise auf Low zieht, plus externe Pull-Downs, sodass ein hängender oder zurücksetzender ESP32 bei Nullbefehl landet statt bei Volllast.
- Festverdrahteter Not-Aus mit Software-Echo. Der Not-Aus läuft über ein Hardware-Sicherheitsrelais (Kategorie 1/PLd-Stil), das das Schütz unabhängig von der MCU abwirft; die Firmware beobachtet und meldet nur den verriegelten Zustand über den Bus.
- Hardware-Quadraturdekodierung. Das ESP32-PCNT-Peripheriemodul übernimmt die glitch-gefilterte Quadraturzählung, sodass die Encoder-Position Wi-Fi-Bursts und ISR-Last übersteht, ohne Impulse durch CPU-Konkurrenz zu verlieren.
- Galvanische I/O-Trennung. Wir spezifizieren opto-isolierte 24V-Eingänge und einen isolierten DC-DC für die MCU-Schiene und brechen damit Erdschleifen zwischen Logik und Schütz-/VFD-Leistung gemäß den IEC 61131-2-Eingangsschwellen auf.
- Core-fixierter deterministischer Loop. Die Steuer-Task wird an einen FreeRTOS-Core gebunden, während der Netzwerk-/Telemetrie-Stack auf dem anderen läuft, sodass NVS und MQTT vom Hot Path ferngehalten werden und der Loop-Jitter im begrenzten Budget bleibt.
- Watchdog-erzwungener Fail-State. Task-Watchdog und Brownout-Detektor werden aktiviert, sodass jeder Hänger oder Spannungseinbruch eine definierte Reset-to-Safe-Sequenz auslöst: Ausgänge entregt, Schütz offen, Fault-Flag für den Bediener-Reset persistiert.
| I/O-Typ | Anforderung an die Regelkreis-Latenz | Fail-Safe-Verhalten bei Firmware-Absturz | Isolationsbedarf |
|---|---|---|---|
| Motorantrieb (VFD/Servo) | ≤ 1 ms PWM-Update, deterministisch | MCPWM-Fault zwingt Ausgänge auf Low → Antrieb läuft aus/rampt in den Stopp | Isolierte PWM-/Analogreferenz zur Antriebsmasse |
| Relais / Schütz | ≤ 10 ms Ansteuerung, entprellt | Spule entregt beim Reset → Schütz öffnet (Schließer) | Opto-/Relaistrennung von der 24V-Spulenschiene |
| Encoder / Zähler | Hardware-PCNT, keine verpassten Flanken | Zählwert im Peripheriemodul verriegelt, beim Neustart neu referenziert | Differenziell/isoliert für lange Kabelstrecken |
| Not-Aus / Verriegelung | Hardwareverriegelt, < 1 ms bis zum Öffnen | Sicherheitsrelais wirft unabhängig von der MCU ab; Firmware spiegelt nur | Vollständig isolierter zweikanaliger Sicherheitskreis |
Go deeper
ESP32 Firmware & IoT Development for other industries
Frequently asked questions
Kann der ESP32 selbst die Sicherheitssteuerung für einen Not-Aus sein?
Nein. Wir halten den Not-Aus in einem festverdrahteten Sicherheitsrelais, damit die Maschine selbst dann stoppt, wenn die Firmware hängt; der ESP32 überwacht und meldet nur den verriegelten Zustand für Diagnose und HMI.
Wie garantieren Sie einen deterministischen Regelkreis bei Wi-Fi-vernetzter Firmware?
Wir binden die Steuer-Task an einen FreeRTOS-Core und isolieren den Netzwerk-Stack auf dem anderen, halten NVS-Schreibvorgänge und MQTT vom Hot Path fern und verifizieren den Worst-Case-Loop-Jitter mit Logikanalysator-Traces unter Netzwerklast.
Was passiert mit den Ausgängen, wenn die Firmware abstürzt oder einen Brownout erleidet?
Jeder Ausgang ist so ausgelegt, dass er in einen entregten Zustand fällt: MCPWM-Fault-Eingänge zwingen die PWM auf Low, Schützspulen fallen beim Reset ab, und der Brownout-Detektor löst vor der Wiederherstellung eine definierte Reset-to-Safe-Sequenz aus.
Funktioniert die Firmware mit unserer vorhandenen SPS und unserem VFD?
Ja. Wir integrieren über Modbus RTU/TCP, analoge 0-10V- oder 4-20mA-Referenzen und digitale 24V-I/O an IEC 61131-2-Schwellen, sodass der ESP32-Knoten neben der SPS sitzt, anstatt Ihre Sicherheitskette zu ersetzen.
Wie schützen Sie den ESP32 vor dem Schaltrauschen von VFD und Schütz?
Wir trennen 24V-Eingänge galvanisch mit Optokopplern, versorgen die MCU aus einem isolierten DC-DC und trennen Logik- und Leistungsmassen, was die Erdschleifen aufbricht, die Störresets und Falschauslösungen verursachen.
Bieten Sie OTA-Updates für Maschinen an, die nicht gestoppt werden können?
Ja, mit A/B-Partitionen und Rollback. Wir koppeln Updates so, dass sie nur greifen, wenn die Maschine einen Leerlauf-/Sicherheitszustand meldet, nie mitten im Zyklus, mit automatischer Rücknahme, falls das neue Image seinen Post-Boot-Selbsttest nicht besteht.