49 lines
2.4 KiB
Markdown
49 lines
2.4 KiB
Markdown
# 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.
|