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.

2.4 KiB Raw Blame History