# 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.