Claude: ToDo

README.md

@@ -23,11 +23,13 @@ Die Eingaben kommen per WebSocket an den HTTPS-Server und werden in `server/Inpu
 - `M114`
   - Antwort: Positionsdaten des Roboters im JSON-Format.
 - G-Code-Befehle:
-  - `G90`, `G91`, `G1`, `G28`, `G92`
+  - `G90`, `G91`, `G1`, `G28`
+  - `G92` (wird intern als `M92` verarbeitet — setzt Motorposition ohne Bewegung)
   - Messungen in `X`, `Y`, `Z`, `A`, `B`, `C`, `E`, `F`
   - `M1` für direkte Motor-Koordinaten
 - Datei-Kommandos:
-  - `FPoint`, `FPlus`, `FMinus`, `FFirst`, `FLast`, `FShow`, `FList`, `FLoad <file>`, `FSave <file>`, `FClear`
+  - `FPoint`, `FPlus`, `FMinus`, `FShow`, `FList`, `FLoad <file>`, `FSave <file>`, `FClear`
+  - `FFirst`, `FLast` — erkannt, aber noch nicht implementiert
   - `M20`, `M23`, `M28`, `M29`
 
 ### G-Code-Verarbeitung
@@ -121,18 +123,50 @@ Die Achszuordnung kann in `robot/TelnetSenderGRBL.js` durch Anpassung der Konstr
 - `robot/Robot.js`
 - `robot/GCode.js`
 - `robot/TelnetSenderGRBL.js`
+- `robot/fluidnc/FluidNCClient.js` — alternative WebSocket-basierte FluidNC-Anbindung mit Reconnect-Logik (noch nicht integriert)
 - `GCodeFiles/` — enthalten Beispiel- und Log-G-Code-Dateien
 
+## Laufzeitvoraussetzungen
+
+- Das Verzeichnis `logs/` muss im Arbeitsverzeichnis existieren, da `InputWS.js` dort `pings.log` und `gcode_commands.log` schreibt.
+- HTTPS-Zertifikate: `https/localhost.key` und `https/localhost.pem` (Passphrase aktuell hardcoded `abcd`).
+- Die Telnet-Sender werden erst nach 5 Sekunden zum Roboter hinzugefügt, damit die Verbindungen Zeit haben aufzubauen.
+
 ## ToDo / Open Tasks
 
-- Architektur- und Refactoring-Aufgaben sind zusätzlich in `doc/ToDo_*.md` dokumentiert.
+Architektur- und Refactoring-Aufgaben sind in `doc/ToDo_*.md` dokumentiert:
+
+| Datei | Thema |
+|---|---|
+| `doc/ToDo_1_Parsing.md` | G-Code-Parser-Schicht einführen |
+| `doc/ToDo_2_Anbindung.md` | Sender-Interface und Orchestrierung |
+| `doc/ToDo_3_Config.md` | Zentralisierte Konfiguration |
+| `doc/ToDo_4_GCode.md` | G-Code- und Datei-Handling trennen |
+| `doc/ToDo_5_API.md` | WebSocket-Antwortlogik strukturieren |
+| `doc/ToDo_6_RobotController.md` | RobotController-Klasse einführen |
+| `doc/ToDo_7_Tests.md` | Testabdeckung und Stabilität |
+| `doc/ToDo_8_Bugs.md` | Bekannte konkrete Bugs |
+| `doc/ToDo_9_HardwareFeedback.md` | Hardware-Feedback-Loop (GRBL-Antworten, Command-Queue, Positionsabgleich) |
+
+### Empfohlene Bearbeitungsreihenfolge
+
+```
+ToDo_8  Bugs beheben          — kurz, blockiert nichts anderes
+ToDo_3  Config                — Fundament für alles Weitere
+ToDo_1  Parser                ┐
+ToDo_6  RobotController       ┘ zusammen, da eng verzahnt
+ToDo_4  Datei-Handling        — danach, klar abgrenzbar
+ToDo_2  Sender-Interface      — mit Entscheidung: Telnet vs. FluidNC-WebSocket
+ToDo_9  Hardware-Feedback     — baut auf ToDo_2 auf
+ToDo_5  API                   — parallel zu ToDo_2/4 möglich
+ToDo_7  Tests                 — begleitend zu allen obigen
+```
+
+Kurzübersicht weiterer offener Punkte:
 
 - [ ] Dokumentation der vollständigen G-Code-Syntax erweitern
-- [ ] Feedrate-Berechnung im Sender genauer definieren
-- [ ] `ROBOT_USE_SPEED_CALC` und `motorSpeeds` im Einsatz prüfen
-- [ ] Fehlerbehandlung bei Telnet-Verbindungen verbessern
-- [ ] Einheitliche Behandlung von absoluten und relativen `M1`-Motorbefehlen
-- [ ] `G92`-Verhalten überprüfen: Position setzen ohne Roboterbewegung
-- [ ] Zusätzliche Testfälle für `InputWS`, `GCode` und `TelnetSenderGRBL` schreiben
-- [ ] HTTPS-Konfiguration und Zertifikatsverwaltung verbessern
-- [ ] Mehrsprachige Kommentare/README-Übersetzung bei Bedarf
+- [ ] `FFirst`/`FLast`-Befehle in `GCode.receiveFC()` implementieren
+- [ ] `ROBOT_USE_SPEED_CALC` und `motorSpeeds` im echten Betrieb prüfen
+- [ ] `FluidNCClient.js` evaluieren: als Ersatz oder Ergänzung zu `TelnetSenderGRBL`?
+- [ ] HTTPS-Konfiguration und Zertifikatsverwaltung verbessern (Passphrase aus Env-Variable)
+- [ ] `logs/`-Verzeichnis beim Start automatisch anlegen