46 lines
2.1 KiB
Markdown
46 lines
2.1 KiB
Markdown
# ToDo 2 — Anbindung
|
|
|
|
## Ziel der Verbesserung
|
|
|
|
Die Anbindung soll zuverlässig werden: WebSocket-Eingaben, Steuerlogik und Sender müssen klar verbunden und sauber orchestriert sein.
|
|
|
|
Dieses ToDo konzentriert sich auf die technische Integration der Komponenten, nicht auf G-Code-Parsing oder Konfiguration.
|
|
## Paket 1: Start/Orchestrierung
|
|
|
|
- [x] `startRobot.js` als Orchestrator behandeln
|
|
- Erzeugung und Verbindung der Module
|
|
- keine Geschäftslogik im Start-Skript
|
|
- [x] Bindung der WebSocket-Eingabe an die Steuerlogik
|
|
- `InputWS.js` empfängt Nachrichten
|
|
- Delegation an den Parser / Controller
|
|
- [x] Sauberes Fehler- und Status-Reporting beim Start
|
|
- fehlende Zertifikate
|
|
- fehlende Senderverbindungen
|
|
|
|
## Paket 2: Sender-Schicht (Option C)
|
|
|
|
- [x] Sender-Interface definieren
|
|
- `connect()`
|
|
- `send(command)`
|
|
- `getStatus()`
|
|
- `disconnect()`
|
|
- [x] `TelnetSenderGRBL` als konkrete Implementierung
|
|
- async `connect()`-Methode
|
|
- eindeutiger Verbindungsstatus, nicht nur `this.tSocket`
|
|
- reconnect/backoff-Strategie (→ `FluidNCClient.js` hat eine funktionierende Reconnect-Logik, die als Referenz dienen kann)
|
|
- saubere Fehlerlogs
|
|
- **Bug:** `close`-Event-Handler nutzt falsche `this`-Bindung — siehe `doc/ToDo_8_Bugs.md` Bug 1
|
|
- [x] Sender-Schicht testbar und austauschbar machen
|
|
- später können andere Sender als `TelnetSenderGRBL` angehängt werden
|
|
|
|
## Paket 3: Status- und Info-Anbindung
|
|
|
|
- [x] `InfoServer.js` meldet nicht nur Weboberfläche, sondern auch Senderstatus
|
|
- [x] `/api/status` erweitert um Senderverbindungen und Health-Informationen
|
|
- [x] `/api/position` liefert aktuelle Roboterposition unabhängig von laufenden Verbindungen
|
|
|
|
## Hinweis
|
|
|
|
- Parsing, Konfiguration, Datei-Management und Tests werden getrennt in eigenen `doc/ToDo_*.md`-Dateien behandelt.
|
|
- Event-basierte Architektur ist aktuell nicht vorgesehen; die Umsetzung folgt Option A mit einer klaren Sender-Interface-Schicht.
|
|
- Die Entscheidung Telnet vs. FluidNC-WebSocket (siehe `robot/fluidnc/FluidNCClient.js`) sollte hier fallen — `FluidNCClient` ist bidirektional und hat Reconnect-Logik, was `ToDo_9` (Hardware-Feedback-Loop) direkt ermöglicht. |