node-red-contrib-me-vplc 1.0.0

package/project/README.md

@@ -0,0 +1,1052 @@
+# EFUSE Parallel-Fast-Path V3 - 2026-05-10
+
+Diese Version optimiert `FB_EFuseControl.st` erneut, weil die bisherige Optimized-Variante trotz Stabilisierung weiterhin seriell über `ActiveChannel` gearbeitet hat. Dadurch konnten bei mehreren gleichzeitig angeforderten Kanälen weiterhin unnötige 650-ms-Schritte nacheinander entstehen.
+
+## Umsetzung
+
+- `Optimized` und `Optimized_V2` enthalten jetzt die neue EFUSE-Parallel-Logik.
+- `Original` bleibt unverändert als Referenz.
+- Aktives Projekt ist auf `Optimized_V2` gesetzt.
+- Die serielle `ActiveChannel`-Kaskade wurde entfernt.
+- Die sieben verschachtelten `FB_EFuseChannel`-Instanzen wurden aus dem Laufzeitpfad entfernt.
+- Jeder Kanal wird in jedem PLC-Zyklus direkt bewertet.
+- Alle benötigten Kanäle erhalten im selben PLC-Zyklus ihr `CTLx`-/`ONx`-Signal.
+- Jeder Kanal besitzt weiterhin eine eigene 650-ms-Impulsbegrenzung über `TON`.
+- Sobald das jeweilige `PWR`-Feedback zum gewünschten Zustand passt, fällt `WAITx`, `CTLx` und `ONx` ohne zusätzlichen Zwischenzyklus ab.
+- Vorherige unnötige Rückschreibungen `EFuseControl.WAITx := LDC.LDSCx.WAIT` vor dem FB-Aufruf wurden entfernt.
+
+## Erwarteter Effekt
+
+Mehrere gleichzeitige EFUSE-Anforderungen werden nicht mehr nacheinander abgearbeitet. Statt bisher im schlechtesten Fall bis zu 7 × 650 ms laufen die Kanalimpulse parallel. Die reale Dauer wird damit im Wesentlichen durch den langsamsten Kanal bzw. dessen Feedback bestimmt, nicht mehr durch die Summe aller Kanäle.
+
+## Prüfung
+
+- `Optimized` kompiliert und führt aus.
+- `Optimized_V2` kompiliert und führt aus.
+- Direkter EFUSE-Test mit sieben gleichzeitigen ON-Anforderungen setzt `CTL1..CTL7`, `ON1..ON7`, `WAIT1..WAIT7` und `CommonON` im ersten Zyklus parallel auf TRUE.
+- Bei einzeln eintreffendem Feedback fallen die betroffenen Kanäle separat wieder ab, ohne andere Kanäle zu blockieren.
+
+---
+
+# Optimized_V2
+
+Dieses Projekt enthält jetzt eine dritte auswählbare Projektvariante:
+
+1. `Original`
+2. `Optimized`
+3. `Optimized_V2`
+
+`Optimized_V2` wurde als neue Arbeitsbasis ergänzt, ohne `Original` oder `Optimized` zu verändern. Die Variante ist logisch am Original ausgerichtet und nutzt die bereits stabilisierte, modulare EFUSE-Struktur als Grundlage. Ziel ist, weitere Optimierungen am Gesamtprojekt nachvollziehbar und getrennt vom Original fortzuführen.
+
+## Umsetzung in Optimized_V2
+
+- eigener Projektordner: `backend/projects/Optimized_V2/`
+- eigenes ST-Projekt-ZIP: `backend/projects/Optimized_V2/st_project/example_project.zip`
+- eigener PLC-Connector: `backend/projects/Optimized_V2/connector/example_connector.zip`
+- `DEFAULT_PROJECT_NAMES` im Backend erweitert
+- aktives Projekt auf `Optimized_V2` gesetzt
+- ST-Projekt wurde gegen den aktuellen Compiler kompiliert und ausgeführt
+- `Original` bleibt unverändert als Referenz
+- `Optimized` bleibt unverändert als bisherige Zwischenstufe
+
+## Fachliche Leitlinie
+
+Optimized_V2 soll keine fachlichen Zustandsbedingungen verändern. Optimierungen werden nur dann übernommen, wenn sie die Original-Logik funktional erhalten und die Ausführung robuster oder deterministischer machen. EFUSE ist deshalb modularisiert/stabilisiert, während die übrigen Bausteine zunächst als funktionale Referenzbasis erhalten bleiben.
+
+---
+
+# Multiprojekt-Fähigkeit
+
+Die Anwendung unterstützt jetzt mehrere übergeordnete Projektordner. Standardmäßig werden zwei Projektbereiche angelegt:
+
+1. `Original`
+2. `Optimized`
+
+Die Projektdaten liegen unter:
+
+```text
+backend/projects/Original/st_project/
+backend/projects/Original/connector/
+backend/projects/Optimized/st_project/
+backend/projects/Optimized/connector/
+```
+
+Über die Dropdownliste im Frontend kann das aktive Projekt ausgewählt werden. Ein Projektwechsel ist nur bei PLC STOP möglich. Beim Wechsel werden ST-Projekt und PLC Connector des gewählten Projektordners geladen und das ST-Projekt neu kompiliert.
+
+---
+
+# ME vPLC Anwendung - Projektdokumentation
+
+Diese Datei fasst alle bisherigen Markdown-Dokumentationen des Projekts zusammen.
+
+
+---
+
+## AUTO_ZYKLUS_README.md
+
+
+# Auto-Zyklus
+
+Der Dashboard-Schalter **Auto-Zyklus** ersetzt die ursprünglich angedachte Bezeichnung "Autoteach".
+
+## Funktion
+
+Wenn Auto-Zyklus aktiv ist, stellt das Backend die `PLC Cycle Time [ms]` automatisch anhand der realen Bearbeitungszeit ein:
+
+```text
+Ø reale PLC-Zeit = READ.avg + EXECUTE.avg + WRITE.avg
+PLC Cycle Time   = ceil(Ø reale PLC-Zeit * 1.20 + 2 ms)
+```
+
+`SYNC` wird bewusst nicht eingerechnet, weil `SYNC` nur die Wartezeit bis zum Soll-Zyklus ist.
+
+## Manuelle Einstellung
+
+Wenn Auto-Zyklus deaktiviert ist, kann `PLC Cycle Time [ms]` wieder manuell gesetzt werden. Beim manuellen Übernehmen wird Auto-Zyklus automatisch deaktiviert.
+
+## Dashboard
+
+Die Beispielmeldung zum ST-Compiler wird nicht mehr im Dashboard angezeigt. Der Compiler-Log bleibt weiterhin als Datei erhalten:
+
+```text
+backend/logs/st_compiler.log
+```
+
+
+---
+
+## COMPILER_FIX_CASE_ASSIGNMENT.md
+
+
+# Compiler-Fix: CASE-Zuweisungen in FB_EFuseControl
+
+## Problem
+Bei kompakten CASE-Zweigen mit mehreren Anweisungen, z. B.
+
+```st
+0: CTL1 := ctrl; WAIT1 := wait;
+```
+
+wurde die zweite Anweisung `WAIT1 := wait` im CASE-Parser fälschlich als neues CASE-Label `WAIT1:` interpretiert, weil der Doppelpunkt aus `:=` erkannt wurde.
+
+Dadurch entstand intern eine ungültige Rest-Anweisung:
+
+```text
+= wait
+```
+
+Sobald der EFuse-Zweig nach Ablauf des Timers aktiv wurde, brach die Runtime mit einem ST-Compilerfehler ab und die PLC ging auf STOP.
+
+## Korrektur
+Der CASE-Parser erkennt Labels jetzt nur noch an Doppelpunkten, die nicht Teil des Zuweisungsoperators `:=` sind.
+
+Zusätzlich werden kompakte CASE-ELSE-Zweige wie `ELSE CURRENT := 0;` korrekt als Default-Zweig verarbeitet.
+
+## Test
+Das Example-Projekt wurde mit aktivem LDSC/EFuse-Zweig über mehrere Zyklen inkl. Timer-Ablauf getestet. Die Runtime bleibt im RUN.
+
+
+---
+
+## COMPILER_FIX_EFUSE.md
+
+
+# Compiler-Fix: Example-Projekt / EFuse
+
+## Ursache
+
+Im optimierten ST-Compiler gab es zwei relevante Probleme bei verschachtelten Function-Block-Instanzen:
+
+1. **CASE-Zweige mit Inline-Anweisungen wurden nicht korrekt erkannt**
+
+   Beispiel aus `FB_EFuseControl.st`:
+
+   ```st
+   CASE CURRENT OF
+       0: req := IN1; pwr := P1; wait := WAIT1;
+       1: req := IN2; pwr := P2; wait := WAIT2;
+   END_CASE
+   ```
+
+   Der Compiler hat bisher nur CASE-Labels erkannt, die allein auf einer Zeile standen, z. B. `0:`. Dadurch wurden `req`, `pwr` und `wait` für den aktuellen EFuse-Kanal nicht sauber übernommen.
+
+2. **FB-Eingänge wurden nach Attribut-Zuweisungen nicht immer in die Runtime-Umgebung synchronisiert**
+
+   Beispiel aus `FB_CSC.st`:
+
+   ```st
+   LDC.Enabled := TRUE;
+   EFuseControl.IN1 := LDC.LDSC1.EFuseControl;
+   EFuseControl.P1 := LDC.LDSC1.LineTripped;
+   ```
+
+   Die Werte wurden zwar am FB-Objekt gesetzt, aber eine bereits erzeugte interne Runtime-Umgebung des FB konnte noch alte Werte enthalten. Dadurch lief z. B. `LDC`, `LDSC` oder `EFuseControl` mit veralteten Eingängen weiter.
+
+## Umsetzung
+
+- CASE-Parser erweitert für Inline-Labels wie `0: req := IN1` oder `BCC_OFF: ...`.
+- `FunctionBlockInstance.__setattr__()` synchronisiert nun automatisch die Runtime-Umgebung.
+- `STRuntime.set_target()` synchronisiert Attribut-Zuweisungen zusätzlich abgesichert.
+
+## Verifiziert
+
+Getestet mit dem enthaltenen `example_project.zip`:
+
+- `CSC` geht in Start-/Limited-State.
+- `LDC.Enabled` wird korrekt in der LDC-Runtime wirksam.
+- `LDSC1` geht bei PushButtonOn in `LDSC_CLOSING`.
+- `LDSC1.EFuseControl = 3` wird korrekt an `EFuseControl.IN1` übergeben.
+- `EFuseControl.CTL1` und `EFuseControl.CommonON` werden aktiv.
+
+
+---
+
+## COMPILER_LOG_README.md
+
+
+# Compiler Log
+
+Diese Version ergänzt einen sichtbaren Compiler-Log im Dashboard.
+
+## Enthaltene Informationen
+
+- geladene ST-Quelldateien
+- Anzahl Zeichen und Zeilen je Datei
+- zusammengeführte Quellen
+- entfernte Kommentare
+- ausgewertete Datentypen, Aliase und Konstanten
+- globale Deklarationen
+- erkannte POUs: PROGRAM, FUNCTION_BLOCK, FUNCTION
+- ausgewähltes Main-PROGRAM
+- vorbereitete Variablen und Anweisungen je POU
+- Abschlussmeldung der optimierten Runtime
+- Runtime-Fehler im PLC-Zyklus werden ebenfalls in den Log geschrieben
+
+## Datei-Log
+
+Zusätzlich zum Dashboard schreibt das Backend den Compiler-Log nach:
+
+```text
+backend/logs/st_compiler.log
+```
+
+Der API-Endpunkt ist:
+
+```text
+GET /api/compiler-log
+```
+
+
+---
+
+## MODBUS_CONNECTOR_README.md
+
+
+# Modbus TCP Connector Runtime
+
+Diese Version interpretiert den importierten Connector `ModbusTCP_57108.json` funktional.
+
+## Ablauf im PLC-Zyklus
+
+1. **READ**
+   - Modbus TCP Verbindung zu `ip:port`, Unit-ID aus `unit.address`.
+   - READ-Variablen werden nach Registertyp und zusammenhängenden Adressen gebündelt.
+   - Werte werden in das ST-Prozessabbild geschrieben.
+   - Beispiel: `CSC_BCM_BatteryTemp1` wird automatisch auf `CSC.BCM.BatteryTemp1` gemappt.
+
+2. **EXECUTE**
+   - ST-Runtime verarbeitet das Programm mit den gelesenen Modbus-Werten.
+
+3. **WRITE**
+   - WRITE-Variablen werden aus dem ST-Prozessabbild gelesen.
+   - Beispiel: `CSC_LEDC_Line1Green` wird automatisch aus `CSC.LEDC.Line1Green` gelesen.
+   - Coils werden zusammenhängend gebündelt.
+   - Coils werden nur geschrieben, wenn sich Werte geändert haben.
+
+## Unterstützte Registertypen
+
+- `DiscreteInput` lesen
+- `Coil` lesen/schreiben
+- `InputRegister` lesen
+- `HoldingRegister` lesen/schreiben
+
+## Unterstützte Datentypen
+
+- `BOOL`
+- `BYTE`, `WORD`, `DWORD`
+- `INT`, `UINT`, `DINT`, `UDINT`
+- `REAL`
+
+## Kommunikationsverhalten
+
+Bei Verbindungsfehlern stoppt die PLC nicht sofort. Der Connector wird als offline markiert und versucht nach einem kurzen Backoff erneut zu verbinden. Dadurch blockiert eine nicht erreichbare Modbus-Station nicht dauerhaft den PLC-Zyklus.
+
+## Dashboard
+
+Im Importbereich wird nun zusätzlich angezeigt:
+
+- Modbus Endpoint
+- Verbindungsstatus
+- Anzahl READ-/WRITE-Variablen
+- Anzahl gebündelter READ-/WRITE-Requests
+- letzter Connector-Fehler
+
+
+---
+
+## MODBUS_WRITE_FIX.md
+
+
+# Modbus WRITE Fix / Verhalten
+
+Das Dashboard zeigte bisher `WRITE Requests: 0`, weil dieser Wert nur den letzten PLC-Zyklus dargestellt hat und die Runtime aus Performance-Gründen nur bei Wertänderung schreibt.
+
+Anpassung:
+
+- Beim PLC-Start wird ein erster WRITE-Zyklus erzwungen.
+- Nach Reconnect wird ein WRITE-Zyklus erzwungen.
+- Zusätzlich wird standardmäßig alle 1000 ms ein WRITE-Resync ausgeführt (`writeResyncMs`).
+- Das Dashboard zeigt jetzt getrennt:
+  - WRITE Requests letzter Zyklus
+  - WRITE Requests gesamt
+  - WRITE übersprungen letzter Zyklus
+  - WRITE Resync
+  - Letzter WRITE Grund (`changed` oder `resync`)
+
+Damit ist erkennbar, ob tatsächlich Modbus-Schreibaktionen ausgeführt wurden, obwohl die Outputs stabil bleiben.
+
+
+---
+
+## PERFORMANCE_OPTIMIERUNGEN.md
+
+
+# ME vPLC Performance-Optimierungen
+
+Umgesetzt:
+
+1. **ST-Compiler / Runtime optimiert**
+   - ST-Ausdrücke werden beim ersten Auftreten in Python-Codeobjekte übersetzt und anschließend wiederverwendet.
+   - Die Runtime verwendet eine wiederverwendbare Ausführungsumgebung statt pro Ausdruck neue Dictionaries aufzubauen.
+   - PROGRAM- und FUNCTION_BLOCK-Runtimes werden wiederverwendet.
+
+2. **Variablenzugriff optimiert**
+   - Variablen werden intern synchron in Runtime-Maps geführt.
+   - Zuweisungen aktualisieren direkt die aktive Runtime-Umgebung.
+   - Keine wiederholte vollständige Environment-Erzeugung pro ST-Ausdruck.
+
+3. **Timer/FBs als native Runtime-Klassen**
+   - IEC-Bausteine wie TON, TOF, TP, R_TRIG, F_TRIG, RS, SR und CTU bleiben native Python-Klassen.
+   - FB-Instanzen behalten ihren Zustand über Zyklen.
+
+4. **Dashboard-Snapshot entkoppelt**
+   - Der PLC-Zyklus erzeugt fertige Status-Snapshots.
+   - `/api/status` liefert nur eine Kopie des letzten Snapshots zurück.
+   - Das Frontend kann den Status zyklisch lesen, ohne PLC-Phasen neu zu berechnen.
+
+5. **Trace/Debug im normalen Run deaktiviert**
+   - Flask startet mit `debug=False`.
+   - Im PLC-Zyklus werden keine Trace-Listen aufgebaut.
+
+6. **Statistiken ohne Listen**
+   - Min/Avg/Max werden laufend berechnet.
+   - Es werden keine wachsenden Cycle-Historien für die Phasenstatistik benötigt.
+
+Erwarteter Effekt beim Beispielprojekt: EXECUTE reduziert sich gegenüber der interpretierenden Variante deutlich. Auf der Testumgebung sank die reine ST-Ausführungszeit des enthaltenen Beispielprojekts von ungefähr 60 ms auf ungefähr 7 ms pro Zyklus.
+
+
+---
+
+## README.md
+
+
+# ME vPLC
+
+Professionelle Flask + React Anwendung für eine ME vPLC Runtime.
+
+## Start
+
+Unter Windows nur diese Datei ausführen:
+
+```bat
+START_ME_VPLC.cmd
+```
+
+Die CMD prüft/erstellt automatisch:
+
+- Backend `.venv`
+- Backend Dependencies
+- Frontend Dependencies
+- Backend auf `http://127.0.0.1:5000`
+- Frontend auf `http://127.0.0.1:5173`
+
+## Funktionen
+
+Dieses Paket enthält unter `examples/` zusätzlich die getesteten Importdateien `example_project.zip` und `example_connector.zip`.
+
+
+- Start / Stop
+- PLC Cycle Time
+- PLC Phasen `READ`, `EXECUTE`, `WRITE`, `SYNC`
+- Min / Avg / Max / Last je Phase
+- Import ST Projekt
+- Import Connector
+
+## Startlogik
+
+- Kein ST-Projekt und kein Connector: Start gesperrt.
+- ST-Projekt vorhanden, aber kein Connector: `READ = 0 ms`, `WRITE = 0 ms`, `EXECUTE = echte ST-Laufzeit`.
+- Connector vorhanden, aber kein ST-Projekt: `READ`/`WRITE` aktiv, `EXECUTE = 0 ms`.
+- ST-Projekt und Connector vorhanden: alle Phasen aktiv.
+
+## ST Compiler
+
+Der ST Compiler wurde erweitert. Details siehe:
+
+`ST_COMPILER_README.md`
+
+## Import-Test
+
+Getestet mit dem bereitgestellten ST-Projekt inklusive `PROGRAMS`, `FUNCTION_BLOCKS`, `FUNCTIONS`, `DATATYPES` und `GLOBALS` sowie dem ModbusTCP-Connector-ZIP.
+
+
+---
+
+## RUNTIME_FIXES.md
+
+
+# Runtime-Fixes
+
+## Behoben
+
+- PLC stoppt nicht mehr direkt nach Start, wenn `example_project.zip` und `example_connector.zip` geladen sind.
+- Ursache war die CASE/IF-Auswertung im ST-Compiler: `ELSE` innerhalb eines `IF` in einem `CASE`-Zweig wurde fälschlich als `CASE ELSE` interpretiert.
+- Dadurch wurde der IF-Block im CASE-Zweig unvollständig ausgeführt und die Runtime meldete `IF ohne END_IF gefunden`.
+
+## Neues Verhalten
+
+- ST-CASE-Blöcke können jetzt IF/ELSIF/ELSE/END_IF sauber innerhalb der CASE-Zweige enthalten.
+- Offline-Modbus-Verbindung stoppt die vPLC nicht.
+- Connector geht bei Verbindungsfehlern auf offline und versucht zyklisch erneut zu verbinden.
+- ST-Ausführung läuft weiter, auch wenn die Modbus-Station gerade nicht erreichbar ist.
+
+## Test
+
+Getestet mit:
+
+- `example_project.zip`
+- `example_connector.zip`
+
+Ergebnis:
+
+- Import ST-Projekt: OK
+- Import Connector: OK
+- Start PLC: OK
+- PLC bleibt RUNNING
+- Wenn Modbus TCP nicht erreichbar ist: Connector offline, PLC läuft weiter
+
+
+---
+
+## ST_CODE_AUDIT_REPORT.md
+
+
+# ST-Code-Audit und Compiler-Abgleich
+
+Basis: `example_project.zip` und aktueller ME-vPLC Compiler.
+
+## Ergebnis
+
+Das Example-Projekt wird syntaktisch vollständig geladen und ausgeführt. Beim funktionellen Abgleich wurden jedoch drei relevante Punkte gefunden und korrigiert.
+
+## Gefundene Compiler-Abweichungen
+
+### 1. Positionsbasierte FB-Ausgänge wurden nicht zurückgeschrieben
+
+Betroffene ST-Zeilen/Pattern:
+
+```st
+HyUblock1BelowLowLimit(UBlock2-UBlock1, UBLOCK_HIGH_BAL_LIM, VOLTAGE_HYSTERESIS, CMP_Type#GT, Ublock1BelowLowLimit);
+HYTempBelowOperRange(InternalTemperature, OPER_RANGE_LOW, TEMP_HYSTERESIS, CMP_Type#LT, TempBelowOperRange);
+```
+
+Der letzte positionale Parameter ist hier funktionell als Ausgangsbindung zu verstehen, analog zu:
+
+```st
+HyUblock1BelowLowLimit(
+    A := UBlock2-UBlock1,
+    B := UBLOCK_HIGH_BAL_LIM,
+    H := VOLTAGE_HYSTERESIS,
+    CMP := CMP_Type#GT,
+    Q => Ublock1BelowLowLimit
+);
+```
+
+Vorher wurde dieser letzte Parameter ignoriert. Dadurch waren mehrere Hysterese-/Latch-Ergebnisse in `FB_BSMSS` und `FB_TC` funktionell falsch.
+
+Korrektur:
+
+- Positionaler Aufruf erkennt jetzt Anzahl `VAR_INPUT` und `VAR_OUTPUT` des Ziel-FBs.
+- Zusätzliche positionale Parameter werden nach dem FB-Aufruf auf die passenden `VAR_OUTPUT`-Variablen zurückgeschrieben.
+
+Betroffene Bausteine:
+
+- `FB_BSMSS.st`
+- `FB_TC.st`
+- indirekt `FB_BMS.st`, `FB_CSC.st`, LED-/EFuse-Logik
+
+### 2. `VAR_TEMP` wurde zyklusübergreifend gehalten
+
+IEC-semantisch ist `VAR_TEMP` nur für den aktuellen Bausteinaufruf gültig. Der Compiler hatte `VAR_TEMP` bisher wie statische interne Variablen behandelt.
+
+Korrektur:
+
+- `VAR_TEMP` wird vor jedem FB-Aufruf auf Defaultwerte zurückgesetzt.
+- `VAR`, `VAR_OUTPUT` und FB-Instanzen bleiben weiterhin zustandsbehaftet.
+
+Betroffene Bausteine:
+
+- `FB_EFuseControl.st`
+- `FB_BSMSS.st`
+- `FB_CompareWithLatch.st`
+
+### 3. Wiederverwendete Runtime-Umgebung konnte alte globale Werte behalten
+
+Der optimierte Compiler verwendet wiederverwendete Runtime-Umgebungen. Dadurch konnten verschachtelte FBs nach HMI-/Global-Änderungen alte Werte in ihrer Eval-Umgebung behalten.
+
+Korrektur:
+
+- Vor jedem äußeren Program-/FB-Aufruf werden globale und lokale Werte in die Runtime-Umgebung gespiegelt.
+- Dadurch sehen verschachtelte FBs aktuelle `VAR_GLOBAL`-/HMI-Werte.
+
+## Gefundene ST-Logik-Auffälligkeit in `FB_EFuseControl.st`
+
+Original:
+
+```st
+IF timer.Q THEN
+    ctrl := FALSE;
+    cmn := FALSE;
+    timer(IN := FALSE);
+    faulted := TRUE;
+    timerElapsed := TRUE;
+END_IF
+
+IF rst OR timer.Q THEN
+    wait := FALSE;
+END_IF
+```
+
+Auffälligkeit:
+
+`timer(IN := FALSE)` setzt den TON im selben Zyklus zurück. Danach ist `timer.Q` wieder `FALSE`. Das nachfolgende `IF rst OR timer.Q THEN` setzt `wait` deshalb bei Timer-Ablauf nicht sicher zurück.
+
+Korrektur im mitgelieferten Example-Projekt:
+
+```st
+IF timer.Q THEN
+    ctrl := FALSE;
+    cmn := FALSE;
+    wait := FALSE;
+    timer(IN := FALSE);
+    faulted := TRUE;
+    timerElapsed := TRUE;
+END_IF
+
+IF rst OR timerElapsed THEN
+    wait := FALSE;
+END_IF
+```
+
+Damit wird `WAITx` bei Timer-Ablauf sauber gelöscht und in `LDC.LDSCx.WAIT` zurückgeschrieben.
+
+## Abgedeckte ST-Konstrukte im Example-Projekt
+
+Im Example-Projekt wurden folgende Konstrukte erkannt und mit dem Compiler abgeglichen:
+
+- `PROGRAM`
+- `FUNCTION_BLOCK`
+- `FUNCTION`
+- `TYPE ... END_TYPE`
+- ENUM-Typen mit und ohne expliziten Basistyp
+- `VAR`, `VAR_INPUT`, `VAR_OUTPUT`, `VAR_EXTERNAL`, `VAR_GLOBAL`, `VAR_TEMP`
+- Initialwerte
+- HMI-Attribute `{ IN HMI }`, `{ OUT HMI }`, `{ IN INTERNAL HMI }`
+- `IF`, `ELSIF`, `ELSE`, `END_IF`
+- `CASE`, `ELSE`, `END_CASE`
+- kompakte CASE-Zweige wie `0: A := B; C := D;`
+- mehrere CASE-Labels wie `CMP_Type#LT, CMP_Type#LTE:`
+- FB-Aufrufe formal mit `:=`
+- FB-Ausgänge formal mit `=>`
+- positionsbasierte FB-Aufrufe mit Ausgangsbindung
+- Funktionsaufrufe
+- verschachtelte FB-Attribute wie `CSC.LDC.LDSC1.PushButtonOn`
+- Bitzugriffe wie `REQ.1`, `VIDI2OperatingMode.0`
+- Zeitliterale wie `T#500ms`, `T#650ms`
+- Standardfunktionen `INT_TO_REAL`, `REAL_TO_INT`
+
+## Testfälle
+
+### Compile-Test
+
+`example_project.zip` kompiliert erfolgreich:
+
+```text
+PROGRAM my_program
+64 Runtime-Variablen
+32 Top-Level-Anweisungen
+Optimierte Runtime aktiv
+```
+
+### Connector-Pfad-Test
+
+Alle 41 Variablen aus `example_connector.zip` wurden gegen das ST-Prozessabbild geprüft.
+
+Ergebnis:
+
+```text
+41 / 41 Connector-Variablen auflösbar
+0 Pfadfehler
+```
+
+### EFuse-Funktionstest
+
+Testfall:
+
+- `PushButtonOn = TRUE`
+- `LineTripped/PWR = FALSE`
+- `EFuseControl.IN1 = 3`
+
+Erwartetes Verhalten:
+
+- `CTL1 = TRUE`
+- `CommonON = TRUE`
+- TON läuft bis `T#650ms`
+- danach `CTL1 = FALSE`
+- `WAIT1 = FALSE`
+- PLC bleibt RUNNING
+
+Ergebnis nach Korrektur:
+
+```text
+CTL1 wird aktiv
+CommonON wird aktiv
+Timer läuft
+WAIT1 wird nach Timeout gelöscht
+LDC.LDSC1.WAIT wird zurückgeschrieben
+Runtime bleibt ohne STOP
+```
+
+## Fazit
+
+Der Compiler versteht das Example-Projekt jetzt vollständig genug für die enthaltene ST-Logik. Die wesentlichen funktionellen Abweichungen lagen nicht bei der Syntaxerkennung, sondern bei:
+
+1. positionalen FB-Ausgangsparametern,
+2. IEC-korrekter `VAR_TEMP`-Lebensdauer,
+3. Runtime-Synchronisation globaler Werte,
+4. einer echten ST-Logik-Auffälligkeit im EFuse-Baustein.
+
+Diese Punkte sind in dieser Projektversion korrigiert.
+
+
+---
+
+## ST_COMPILER_README.md
+
+
+# ME vPLC ST Compiler / Runtime
+
+Der Compiler wurde als IEC-61131-3-orientierter ST-Interpreter erweitert.
+Er ist bewusst lokal und leichtgewichtig umgesetzt und benötigt keine externe SPS-Runtime.
+
+## Unterstützte Programm-Organisationseinheiten
+
+- `PROGRAM ... END_PROGRAM`
+- `FUNCTION_BLOCK ... END_FUNCTION_BLOCK`
+- `FUNCTION ... : <DATENTYP> ... END_FUNCTION`
+- Instanzierung von Funktionsbausteinen in `VAR`, z. B. `Motor1 : FB_Motor;`
+- Aufruf von FB-Instanzen mit formalen Parametern, z. B. `Motor1(Start := TRUE);`
+- Zugriff auf FB-Ausgänge über Punktnotation, z. B. `Q := Motor1.Running;`
+
+## Unterstützte Variablenbereiche
+
+- `VAR`
+- `VAR_INPUT`
+- `VAR_OUTPUT`
+- `VAR_IN_OUT`
+- `VAR_TEMP`
+- `VAR_GLOBAL`
+- `VAR CONSTANT`
+- Direkte Variablen mit `AT %IX...`, `AT %QX...`, `AT %MW...` werden syntaktisch akzeptiert.
+
+## Unterstützte Datentypen und Literale
+
+- `BOOL`
+- `BYTE`, `WORD`, `DWORD`
+- `INT`, `DINT`, `SINT`, `UINT`, `UDINT`
+- `REAL`, `LREAL`
+- `TIME`
+- `STRING`
+- `ARRAY [x..y] OF <TYPE>`
+- `TYPE ... STRUCT ... END_STRUCT END_TYPE`
+- Bool-Literale: `TRUE`, `FALSE`
+- Zeitliterale: `T#650MS`, `T#2S`, `T#1M`, `T#1H`, `T#1D`
+- Binär: `2#1010`
+- Hex: `16#FF`, `B#16#FF`, `W#16#1234`, `DW#16#FFFF_FFFF`
+
+## Unterstützte ST-Anweisungen
+
+- Zuweisung mit `:=`
+- `IF ... THEN ... ELSIF ... ELSE ... END_IF`
+- `FOR i := a TO b BY s DO ... END_FOR`
+- `WHILE ... DO ... END_WHILE`
+- Vergleich: `=`, `<>`, `<`, `<=`, `>`, `>=`
+- Boolesche Operatoren: `AND`, `OR`, `XOR`, `NOT`
+- Arithmetik: `+`, `-`, `*`, `/`, `MOD`
+- Array-Zugriff: `INP[1]`, `CTL[i]`
+- Struktur-/FB-Zugriff: `Instanz.Q`, `Daten.Feld`
+
+## Eingebaute IEC-Funktionsbausteine
+
+- `TON`
+- `TOF`
+- `TP`
+- `R_TRIG`
+- `F_TRIG`
+- `RS`
+- `SR`
+- `CTU`
+
+## Eingebaute Standardfunktionen
+
+- `ABS`
+- `MIN`
+- `MAX`
+- `LIMIT`
+- `SEL`
+- `MUX`
+- `INT`, `DINT`, `REAL`, `BOOL`
+- `SIN`, `COS`, `TAN`, `SQRT`
+
+## Grenzen
+
+Dies ist kein zertifizierter IEC-61131-3-Compiler und erzeugt keinen nativen SPS-Maschinencode.
+Es ist ein lokaler ST-Interpreter für die ME-vPLC-Simulation. Nicht enthalten sind derzeit u. a. vollständige `CASE`-Syntax, `REPEAT`, Pointer/ANY, vollständige Typprüfung, echte Hardware-Adressbindung und SFC/AS.
+
+## Erweiterung für das bereitgestellte Projekt
+
+Der Compiler wurde zusätzlich auf die hochgeladenen Dateien `project.zip` und `connector.zip` getestet.
+
+Neu abgedeckt:
+
+- ENUM-/abgeleitete Datentypen in `TYPE ... : INT (...) END_TYPE`, z. B. `BCC_STATES`, `BCM_STATES`, `CMP_Type`
+- qualifizierte ENUM-Konstanten wie `CMP_Type#GTE`
+- Deklarationsattribute in geschweiften Klammern, z. B. `{ OUT HMI }`, werden toleriert
+- `VAR_EXTERNAL` und `VAR_GLOBAL` mit gemeinsamem Global-Speicher
+- `CASE ... OF ... END_CASE`
+- mehrere CASE-Labels, z. B. `CMP_Type#LT, CMP_Type#LTE:`
+- formale Parameter `:=`
+- Ausgangsparameter-Mapping mit `=>`, z. B. `CTRL => ctrl1`
+- nichtformale/positionale FB-Aufrufe, z. B. `HY(A, B, H, CMP_Type#GT, Q)`
+- Inline-IF, z. B. `IF timer1.ET > ET THEN ET := timer1.ET; END_IF`
+- Bitzugriff auf numerische Typen, z. B. `REQ.1`, `VIDI2OperatingMode.0`
+- Konvertierungsfunktionen `INT_TO_REAL`, `REAL_TO_INT`, `DINT_TO_REAL`, `REAL_TO_DINT`
+- Connector-Import als `.json` oder `.zip`
+
+
+## Performance-Runtime
+
+Die Runtime wurde optimiert:
+
+- ST-Ausdrücke werden in Python-Codeobjekte vorkompiliert und wiederverwendet.
+- Variablen werden in einer wiederverwendbaren Runtime-Umgebung gehalten.
+- PROGRAM- und FUNCTION_BLOCK-Runtimes werden nicht pro Zyklus neu aufgebaut.
+- IEC-Timer und Standard-FBs laufen als native Python-Klassen mit persistentem Zustand.
+- Dashboard-/API-Status basiert auf einem entkoppelten Snapshot.
+- Flask-Debug und zyklischer Trace sind im normalen Start deaktiviert.
+- Phasenstatistiken werden laufend ohne Listen berechnet.
+
+## Dashboard-Struktur
+
+Die Oberfläche ist in drei Seiten aufgeteilt:
+
+- **PLC Control**: Start/Stop, PLC Cycle Time, Auto-Zyklus und Statistik zurücksetzen.
+- **PLC Connector**: Connector-Import und Modbus-/Connector-Status.
+- **PLC Monitoring**: ST-Projekt-Import, Zykluskennzahlen und Phasenübersicht READ, EXECUTE, WRITE und SYNC.
+
+Die Hauptseite enthält bewusst nur die Control-Elemente.
+
+## Optimized-Projekt: parallelisierte EFuse-Logik
+
+Im Projekt `Optimized` wurde `FUNCTION_BLOCKS/FB_EFuseControl.st` angepasst.
+
+Die bisherige sequenzielle Auswertung über `CURRENT` wurde entfernt. Stattdessen werden alle sieben EFuse-Kanäle in jedem PLC-Zyklus parallel verarbeitet:
+
+- je Kanal ein eigener `TON`-Timer
+- je Kanal eigene `CTRL`/`CMN`/`RST`-Auswertung über `FN_EFuse`
+- `CTL1` bis `CTL7` werden in jedem Zyklus aktualisiert
+- `CommonON` wird als Oder-Verknüpfung aller aktiven Common-Signale gebildet
+- Timeout pro Kanal bleibt bei `T#650ms`
+
+Das Projekt `Original` bleibt unverändert.
+
+## Optimized: EFuse 7-fach parallel
+
+Im Projekt `Optimized` wurde `FB_EFuseControl.st` vollständig 7-fach parallelisiert:
+
+- `IN1..IN7`, `P1..P7`
+- `WAIT1..WAIT7`
+- `timer1..timer7`
+- `CTL1..CTL7`
+- `ON1..ON7`
+- `CommonON = ON1 OR ... OR ON7`
+
+Zusätzlich wurde Kanal 4 im `FB_CSC.st` angebunden:
+
+- `EFuseControl.IN4` aus `BCC.VIDI2PowerSupplyEFuse`
+- `EFuseControl.P4` aus `BCC.FullyFunctional`
+
+Der Optimized-Connector enthält zusätzliche WRITE-Variablen für `CTL4` und `ON1..ON7`.
+
+
+## Optimized: EFUSE-Kanalstruktur
+
+Im Projekt `Optimized` wurde die EFUSE-Logik modularisiert:
+
+- `FUNCTION_BLOCKS/FB_EFuseChannel.st` enthält die Logik für genau einen EFUSE-Kanal.
+- `FUNCTION_BLOCKS/FB_EFuseControl.st` enthält sieben Instanzen `Ch1..Ch7` und ruft alle Kanäle in jedem PLC-Zyklus parallel auf.
+- `Original` bleibt unverändert.
+
+Damit entfällt die frühere sequenzielle `CURRENT`-Kaskade. Alle Ausgänge `CTL1..CTL7`, `ON1..ON7`, `CommonON`, `T` und `ET` werden im optimierten Projekt zyklisch aktualisiert.
+
+
+## EFUSE Optimized
+
+Im Projekt `Optimized` ist die EFUSE-Logik modularisiert:
+
+- `FB_EFuseChannel.st` enthält die Original-Logik für genau einen EFUSE-Kanal.
+- `FB_EFuseControl.st` ruft sieben Channel-Instanzen parallel in jedem PLC-Zyklus auf.
+- Das Original-Projekt bleibt unverändert.
+- Die Optimierung ändert nicht die fachliche EFUSE-Entscheidungslogik, sondern entfernt nur die sequenzielle `CURRENT`/`CASE`-Abarbeitung über sieben Zyklen.
+
+
+## EFUSE Optimized - stabile 650-ms-Schaltfenster
+
+Im Projekt `Optimized` ist die EFUSE-Logik modular aufgebaut:
+
+- `FB_EFuseChannel.st` verarbeitet genau einen Kanal.
+- `FB_EFuseControl.st` ruft sieben Kanalinstanzen parallel auf.
+- Jeder Kanal latcht eine neue Schaltanforderung beim Start des Vorgangs.
+- Während des laufenden 650-ms-Fensters bleiben `CTL`, `ON` und `WAIT` stabil.
+- Neue IN-Wechsel werden erst nach Abschluss des aktuellen Vorgangs bewertet.
+
+Damit wird verhindert, dass ein Ein-/Ausschalten innerhalb einer PLC-Zykluszeit den laufenden EFUSE-Schaltvorgang durcheinanderbringt. Die fachliche Bewertung von `REQ`, `PWR`, `CTRL`, `CMN` und `RST` erfolgt weiterhin über die originale Funktion `FN_EFuse`.
+
+## Optimized EFUSE Umsetzung
+
+Im Multiprojekt **Optimized** wurde `FB_EFuseControl` erneut aus der Original-Logik abgeleitet und nur modularisiert/parallelisiert:
+
+- `FB_EFuseChannel.st` bildet die originale Bearbeitung eines einzelnen `CURRENT`-Kanals nach.
+- `FB_EFuseControl.st` ruft sieben Instanzen `Ch1..Ch7` in jedem PLC-Zyklus parallel auf.
+- Es gibt keine zusätzliche Sonderlogik für Latching, Retrigger oder Completed-Filter.
+- `Original` bleibt unverändert.
+
+## EFUSE Optimized Parallel Stable
+
+Im Projekt `Optimized` wurde die EFUSE-Logik modular und parallel stabilisiert:
+
+- `FB_EFuseChannel.st` bildet einen einzelnen EFUSE-Kanal ab.
+- `FB_EFuseControl.st` ruft sieben Instanzen parallel auf.
+- Jeder Kanal besitzt eigenen Zustand und eigenen Timer.
+- Eine neue Anforderung wird beim Start gelatcht.
+- Schnelle IN-Wechsel während eines laufenden Kanals überschreiben die laufende Logik nicht.
+- `PWR` wird weiterhin live ausgewertet, damit der Zielzustand erkannt wird.
+- `ON`, `CTL` und `WAIT` bleiben stabil, bis `FN_EFuse` den Abschluss meldet oder der 650-ms-Timer abläuft.
+
+## Änderung: entkoppelte Modbus-Kommunikation und 100-Zyklen-Statistik
+
+- Die PLC-Phasen `READ` und `WRITE` führen keine direkten Modbus/TCP-Zugriffe mehr aus.
+- Ein separater Modbus-Worker übernimmt Connect, Reconnect, READ, WRITE und Backoff.
+- Der PLC-Zyklus arbeitet nur mit Eingangs- und Ausgangs-Caches.
+- `Min`, `Avg` und `Max` der PLC-Phasen werden blockweise aus abgeschlossenen 100-Zyklen-Fenstern synchronisiert.
+- Das Dashboard zeigt die letzte 100-Zyklen-Synchronisierung mit Zyklusnummer und Uhrzeit an.
+
+
+## Anpassung Statistik Live-Fenster
+
+Die PLC-Phasenstatistik berechnet `min`, `avg` und `max` jetzt live aus den letzten 100 Zyklen. `Last` bleibt der aktuelle Zykluswert. Alte Ausreißer, zum Beispiel frühere Modbus-Timeouts, fallen nach 100 neuen Zyklen automatisch aus der Anzeige. Die Anzeige der letzten Synchronisierung dient nur noch als 100-Zyklen-Marker.
+
+## Optimized_V2
+
+`Optimized_V2` ist eine zusätzliche Projektvariante neben `Original` und `Optimized`.
+
+Ziel der Variante ist eine bausteinweise Optimierung, ohne das fachliche Originalverhalten zu verändern. Umgesetzt wurden aktuell:
+
+- `FB_CSC`: zentrale Zustandsbedingungen werden einmal pro Zyklus berechnet und anschließend in der FSM verwendet.
+- `FB_LDC`: Fuse-Trip-Bewertung der drei LDSC-Zweige wird einmal pro Zyklus gecacht.
+- `FB_LDSC`: wiederkehrende Basisanforderungen werden einmal pro Zyklus berechnet.
+- `EFUSE`: bleibt modular über `FB_EFuseChannel` und `FB_EFuseControl`, mit stabiler deterministischer Schaltfreigabe.
+- `FB_LEDC`, `FB_BMS`, `FB_BCM`, `FB_BCC`: geprüft und zunächst funktionell unverändert gelassen, da dort die Reihenfolge der Zustände sicherheits- bzw. fachlogisch relevant ist.
+
+Details stehen zusätzlich in `OPTIMIZED_V2_NOTES.txt` innerhalb des ST-Projekts.
+
+## Projektwechsel und ST-Kompilierung
+
+Beim Wechsel eines Projekts über die Projekt-Dropdownliste wird das ST-Projekt aus dem jeweils ausgewählten Projektordner neu geladen und direkt frisch kompiliert. Dadurch wird verhindert, dass nach einem Projektwechsel noch eine alte Runtime, ein alter AST oder ein zuvor kompiliertes Programm weiterverwendet wird.
+
+Relevante Projektstruktur:
+
+```text
+backend/projects/Original/st_project/
+backend/projects/Optimized/st_project/
+backend/projects/Optimized_V2/st_project/
+```
+
+Die API liefert zusätzlich zurück, welches Projekt und welche ST-Datei zuletzt kompiliert wurden:
+
+```text
+st_compiled_project
+st_compiled_file
+st_compiled_at
+```
+
+## Projekt: EFUSE only
+
+Das bestehende Projekt **EFUSE only** wurde modularisiert und parallelisiert. Es wurde kein neues Projekt angelegt.
+
+Ziel:
+
+- EFUSE-only bleibt als eigene auswählbare Projektvariante erhalten.
+- Die EFUSE-Logik ist jetzt in kleine ST-Bausteine aufgeteilt.
+- Alle 7 EFUSE-Kanäle werden in jedem PLC-Zyklus ausgeführt.
+- Jeder Kanal besitzt einen eigenen `TON` und eigenen Zustand.
+- Die fachliche Originalentscheidung bleibt in `FN_EFuse` gekapselt.
+- Die Connector-kompatible Struktur `CSC.EFuseControl.*` bleibt erhalten.
+
+Struktur im ST-Projekt:
+
+```text
+DATATYPES/EFUSE_TYPES.st
+FUNCTIONS/FN_EFuse.st
+FUNCTION_BLOCKS/FB_EFuseChannel.st
+FUNCTION_BLOCKS/FB_EFuseControl.st
+PROGRAMS/my_program.st
+project.json
+```
+
+Die Datei liegt im Projekt unter:
+
+```text
+backend/projects/EFUSE only/st_project/efuse_only_project.zip
+```
+
+Der passende Connector liegt unter:
+
+```text
+backend/projects/EFUSE only/connector/efuse_only_connector.zip
+```
+
+Hinweis:
+
+Die bekannten Connector-Pfade wie `CSC_EFuseControl_CTL1`, `CSC_EFuseControl_ON1`,
+`CSC_EFuseControl_CommonON` und `CSC_LDC_LDSC1_PushButtonOn` bleiben erhalten.
+Das Main-Programm ruft `FB_EFuseControl` auf und schreibt die Ergebnisse anschließend
+in die Connector-Struktur `CSC.EFuseControl` zurück.
+
+
+## EFUSE only - KEEP-Logik
+
+Im Projekt `EFUSE only` wurde die EFUSE-Logik um eine kanalbezogene KEEP-Stabilisierung erweitert.
+
+- Jeder der sieben EFUSE-Kanäle besitzt ein eigenes `KEEP`-Signal.
+- Eine neue Anforderung wird beim Start eines Schaltvorgangs gelatcht.
+- Während `KEEP = TRUE` bleibt die gelatchte Anforderung aktiv, auch wenn der Eingang innerhalb der PLC-Zykluszeit umschaltet.
+- `PWR` bleibt live, damit der Abschluss des Vorgangs sofort erkannt wird.
+- `CTL`, `ON`, `WAIT`, `BUSY`, `NEED` und `KEEP` werden pro Kanal getrennt geführt.
+- Der Connector wurde um `CSC_EFuseControl_KEEP1..KEEP7` erweitert.
+
+Damit bleibt die EFUSE-only-Variante modularisiert und parallelisiert, verhindert aber instabile Zwischenzustände durch schnelle Eingangssignale.
+
+## EFUSE only - Channel 1
+
+Das Projekt `EFUSE only` wurde auf eine reine Channel-1-Variante reduziert.
+
+- Es wird ausschließlich `EFuseControl` Kanal 1 ausgeführt.
+- `FB_EFuseControl.st` enthält nur noch `Ch1: FB_EFuseChannel`.
+- `my_program.st` verarbeitet nur noch `EFUSE_REQ1`, `EFUSE_PWR1`, `CSC.LDC.LDSC1.PushButtonOn` und `CSC.LDC.LDSC1.LineTripped`.
+- Der EFUSE-only-Connector wurde auf die Channel-1-relevanten Modbus-Variablen reduziert.
+- Die Projekte `Original`, `Optimized` und `Optimized_V2` bleiben unverändert.
+
+## EFUSE only - Channel 1 + Channel 2
+
+Die Projektvariante `EFUSE only` enthält jetzt Channel 1 und Channel 2. Beide Kanäle arbeiten autark:
+
+- Channel 1 nutzt `CSC.LDC.LDSC1.PushButtonOn` und `CSC.LDC.LDSC1.LineTripped`.
+- Channel 2 nutzt `CSC.LDC.LDSC2.PushButtonOn` und `CSC.LDC.LDSC2.LineTripped`.
+- Beide Kanäle verwenden jeweils eine eigene `FB_EFuseChannel`-Instanz mit eigenem `TON`, `KEEP`, `WAIT`, `BUSY`, `NEED`, `CTL` und `ON`.
+- `CommonON` wird aus `ON1 OR ON2` gebildet.
+- Die Modbus-Connector-Variablen wurden auf die Channel-1-/Channel-2-Signale erweitert.
+
+
+## EFUSE only - No-Dead-Cycle Anpassung
+
+Im Projekt **EFUSE only** wurde `FB_EFuseChannel.st` so angepasst, dass keine leeren Zwischenzyklen mehr entstehen.
+
+- `CTL`, `ON`, `WAIT`, `BUSY` und `KEEP` bleiben während eines laufenden Schaltvorgangs stabil.
+- `timer.Q` erzeugt keine periodische AUS-Phase mehr. Der TON dient als Status-/Überwachungszeit.
+- Wenn ein Vorgang abgeschlossen ist, wird im selben PLC-Zyklus direkt geprüft, ob bereits eine neue Anforderung anliegt.
+- Channel 1 und Channel 2 arbeiten autark mit jeweils eigener Instanz und eigenem Zustand.
+
+## EFUSE only - Mico-Pro-orientierte Umsetzung
+
+Das Projekt **EFUSE only** verwendet jetzt pro Kanal eine eigene Impuls-/Feedback-Zustandsmaschine:
+
+- `REQ = 1`: Restart über ON-Klemme, ON-Puls 200 ms.
+- `REQ = 2`: Ausschalten über CTRL-Klemme, CTRL-Puls 650 ms.
+- `REQ = 3`: Einschalten über CTRL + ON, gemeinsamer Puls 650 ms.
+- Nach dem Puls werden die Steuerklemmen wieder freigegeben.
+- `WAIT`, `BUSY` und `KEEP` bleiben aktiv, bis die erwartete Rückmeldung `PWR`/Alarm-Klemme erreicht ist oder die Anforderung zurückgenommen wird.
+- Channel 1 und Channel 2 laufen autark mit jeweils eigener `FB_EFuseChannel`-Instanz.
+
+Damit wird nicht mehr dauerhaft `CTRL`/`ON` gehalten, sondern die Mico-Pro-Zeitlogik über definierte Pulse abgebildet.
+
+
+## EFUSE only Channel 1 bis 7
+
+Das Projekt `EFUSE only` wurde auf sieben autarke Kanäle erweitert. Jeder Kanal nutzt dieselbe `FB_EFuseChannel`-Logik mit eigener TON-Instanz und eigener Puls-/Feedback-FSM nach Mico-Pro-Logik:
+
+- `REQ = 1`: Restart über ON-Klemme, 200 ms Puls
+- `REQ = 2`: Ausschalten über CTRL-Klemme, 650 ms Puls
+- `REQ = 3`: Einschalten über CTRL + ON, 650 ms Puls
+- `PWR/Alarm`: Rückmeldung, ob der Kanal eingeschaltet ist
+
+Alle sieben Kanäle besitzen eigene Signale `CTLx`, `ONx`, `WAITx`, `BUSYx`, `NEEDx`, `KEEPx`, `STATEx`. `CommonON` wird aus `ON1 OR ... OR ON7` gebildet.
+
+
+## EFUSE only - Ausschaltimpuls korrigiert
+
+Die EFUSE-only-Kanallogik wurde so angepasst, dass `IN = 2` immer einen definierten CTRL-Ausschaltimpuls erzeugt, auch wenn die Rueckmeldung/PWR noch nicht passend oder nicht sicher abgebildet ist. Nach dem 650-ms-Impuls werden `CTL` und `ON` wieder freigegeben. Wenn die Rueckmeldung weiterhin nicht dem Zielzustand entspricht, kann der Impuls wiederholt werden. Dadurch funktioniert das Abschalten stabiler und haengt nicht mehr daran, dass `PWR` vor dem ersten Ausschaltimpuls bereits TRUE ist.
+
+## EFUSE V4 KEEP-Latch
+
+Die optimierten Projekte `Optimized` und `Optimized_V2` verwenden `FB_EFuseControl` als Parallel-Fast-Path mit `KEEP1..KEEP7`.
+
+- `KEEPx` zeigt an, welcher Kanal aktuell aktiv gemerkt ist.
+- `KEEP_INx` speichert den gelatchten IN-Befehl fuer die laufende 650-ms-Impulsdauer.
+- `KEEP_COUNT` zeigt die Anzahl der aktuell aktiven/gemerkten Kanaele.
+- Kurze IN-Wechsel kleiner als 650 ms gehen dadurch nicht verloren.
+- Alle 7 Kanaele laufen parallel und blockieren sich nicht gegenseitig.
+
+## Projekt: Optimized_EFUSE-Function
+
+Dieses Projekt enthält eine optimierte EFUSE-Funktion mit zyklischem 7-Kanal-Scan. In jedem PLC-Zyklus werden alle Kanäle geprüft. Benötigte Kanäle werden über `ACTIVE1..ACTIVE7` und `KEEP1..KEEP7` markiert. Dadurch ist direkt sichtbar, ob z. B. Kanal 2, 5 und 7 gleichzeitig aktiv sind. Die bisherige serielle Kanalzähler-Kaskade wird in diesem Projekt nicht mehr als Bearbeitungslogik verwendet.
+
+Wichtige Diagnosewerte:
+
+- `ACTIVE1..ACTIVE7`: Kanal benötigt aktuell einen EFUSE-Schaltimpuls.
+- `KEEP1..KEEP7`: Kanal wurde gelatcht und wird aktuell verarbeitet.
+- `ACTIVE_COUNT`: Anzahl aktuell erkannter aktiver Kanäle.
+- `KEEP_COUNT`: Anzahl aktuell gelatchter Kanäle.
+- `ACTIVE_MASK`: Bitmaske der aktuell aktiven Kanäle, Kanal 1 = 1, Kanal 2 = 2, Kanal 3 = 4 usw. Beispiel Kanal 2+5+7 = 82.
+- `KEEP_MASK`: Bitmaske der gelatchten Kanäle.
+- `FIRST_ACTIVE_CHANNEL` / `CURRENT`: erster aktuell erkannter aktiver Kanal, 0 wenn keiner aktiv ist.