Claude: ToDo

doc/ToDo_9_HardwareFeedback.md

@@ -0,0 +1,48 @@
+# ToDo 9 — Hardware-Feedback-Loop
+
+## Ziel
+
+Der Roboter-Treiber soll nicht nur Befehle senden, sondern auch Antworten der Hardware lesen. Nur so können Fehler erkannt, Positionen verifiziert und Befehlsfolgen zuverlässig synchronisiert werden.
+
+Aktuell ist der Datenfluss vollständig blind:
+
+```
+WebSocket → GCode → calculateAngles3D → sendCommand → tSocket.write()
+                                                          ↓
+                                               GRBL antwortet mit "ok" / "error"
+                                               → wird nie gelesen (data => {})
+```
+
+---
+
+## Paket 1: GRBL-Antworten lesen
+
+- [ ] `connection.on('data', data => {})` in `TelnetSenderGRBL` ersetzen durch echtes Lesen
+  - GRBL antwortet auf jeden G-Code-Befehl mit `ok` oder `error: <Meldung>`
+  - Antworten parsen und ins Log schreiben
+- [ ] Fehlerantworten nach außen meldbar machen
+  - an `InfoServer` oder über einen EventEmitter
+  - damit der WebSocket-Client Feedback bekommt, ob ein Befehl angenommen wurde
+
+## Paket 2: Command-Queue mit ok-Handshake
+
+- [ ] Sendepuffer einführen: Befehle erst abschicken, wenn das vorherige `ok` eingegangen ist
+  - GRBL hat intern ~128 Byte Puffer — bei schnellen Befehlsfolgen (Datei abspielen) droht sonst Puffer-Überlauf und stille Befehlsverwerfung
+  - Alternative: GRBL Line-Counting-Protokoll (sendet mehrere Befehle, zählt Zeichen im Puffer)
+- [ ] Timeout für ausbleibende `ok`-Antworten definieren
+  - nach X ms ohne Antwort: Fehler loggen, ggf. Verbindung zurücksetzen
+
+## Paket 3: Hardwareposition abfragen (`?`-Status)
+
+- [ ] Periodisch GRBL-Statusabfrage senden: `?`
+  - GRBL antwortet mit `<Idle|MPos:0.000,0.000,0.000|WPos:0.000,0.000,0.000>`
+  - Alternative: nach jedem abgeschlossenen Move abfragen
+- [ ] Gemeldete Hardware-Position mit Softwareposition (`robot.x/y/z`) vergleichen
+  - bei Abweichung: warnen oder synchronisieren
+  - schützt gegen Drift durch Endschalter-Auslösung, Motor-Stall, Verbindungsunterbrechung
+- [ ] Status (`Idle`, `Run`, `Alarm`, `Hold`) für den `InfoServer` bereitstellen
+  - `/api/status` um GRBL-Zustand erweitern
+
+## Hinweis zur Implementierung
+
+`robot/fluidnc/FluidNCClient.js` ist eine bidirektionale WebSocket-Anbindung an FluidNC (Port 81) mit Reconnect-Logik und `EventEmitter`-Interface — diese Klasse ist eine gute Grundlage für alle drei Pakete und sollte bei der Umsetzung von `ToDo_2` (Sender-Interface) mit evaluiert werden.