Dokumentation

doc/ToDo_1_Parsing.md

@@ -0,0 +1,13 @@
+# ToDo 1 — Parsing
+
+## Ziel der Verbesserung
+
+Klare Trennung zwischen G-Code-Parsing und Robotersteuerlogik. Der Parser soll nur lesen und strukturieren, nicht direkt den Roboterzustand verändern.
+
+## Aufgaben
+
+- [ ] `GCodeParser` einführen, das G-Code und Nachrichten in strukturierte Befehlsobjekte übersetzt
+- [ ] Parsing-Regeln definieren für `G90`, `G91`, `G1`, `G28`, `G92`, `M1` und `$J=` sowie Parameter `X`, `Y`, `Z`, `A`, `B`, `C`, `E`, `F`
+- [ ] Raw-String-Verarbeitung aus `GCode.receiveGCode()` entfernen
+- [ ] Parser-Resultate als Objekte an den Controller übergeben, nicht als rohe Textbefehle
+- [ ] Parser-Fehlerfälle klar behandeln: ungültige Syntax, fehlende Werte, unbrauchbare Befehle

doc/ToDo_2_Anbindung.md

@@ -0,0 +1,44 @@
+# 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
+
+- [ ] `startRobot.js` als Orchestrator behandeln
+  - Erzeugung und Verbindung der Module
+  - keine Geschäftslogik im Start-Skript
+- [ ] Bindung der WebSocket-Eingabe an die Steuerlogik
+  - `InputWS.js` empfängt Nachrichten
+  - Delegation an den Parser / Controller
+- [ ] Sauberes Fehler- und Status-Reporting beim Start
+  - fehlende Zertifikate
+  - fehlende Senderverbindungen
+
+## Paket 2: Sender-Schicht (Option C)
+
+- [ ] Sender-Interface definieren
+  - `connect()`
+  - `send(command)`
+  - `getStatus()`
+  - `disconnect()`
+- [ ] `TelnetSenderGRBL` als konkrete Implementierung
+  - async `connect()`-Methode
+  - eindeutiger Verbindungsstatus, nicht nur `this.tSocket`
+  - reconnect/backoff-Strategie
+  - saubere Fehlerlogs
+- [ ] Sender-Schicht testbar und austauschbar machen
+  - später können andere Sender als `TelnetSenderGRBL` angehängt werden
+
+## Paket 3: Status- und Info-Anbindung
+
+- [ ] `InfoServer.js` meldet nicht nur Weboberfläche, sondern auch Senderstatus
+- [ ] `/api/status` erweitert um Senderverbindungen und Health-Informationen
+- [ ] `/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.

doc/ToDo_3_Config.md

@@ -0,0 +1,18 @@
+# ToDo 3 — Konfiguration
+
+## Ziel der Verbesserung
+
+Zentralisierte Konfiguration statt verstreuter Hardcodierung. Konfiguration soll transparent, testbar und leicht anpassbar sein.
+
+## Aufgaben
+
+- [ ] `config.js` oder ein zentrales Config-Modul anlegen
+- [ ] Alle Umgebungsvariablen an einer Stelle lesen und validieren
+  - `PORT`
+  - `GRBL_BASE_IP`, `GRBL_ELLBOW_IP`, `GRBL_HAND_IP`
+  - `ROBOT_DEFAULT_FEEDRATE`
+  - `ROBOT_USE_SPEED_CALC`
+  - HTTPS-Zertifikatpfade und Passphrase
+- [ ] `startRobot.js`, `TelnetSenderGRBL`, `InfoServer.js` und weitere Module mit dem Config-Modul arbeiten lassen
+- [ ] Optional: `config/default.json` oder `.env` als Konfigurationsbasis bereitstellen
+- [ ] Fehlende oder ungültige Konfiguration frühzeitig mit klarer Fehlermeldung melden

doc/ToDo_4_GCode.md

@@ -0,0 +1,15 @@
+# ToDo 4 — G-Code und Datei-Handling
+
+## Ziel der Verbesserung
+
+G-Code-Logik sauber von Datei-Management trennen. Die Bewegungssteuerung soll nicht durch Dateibefehle oder File-IO verwässert werden.
+
+## Aufgaben
+
+- [ ] `GCodeFileManager` einführen für Datei-bezogene Befehle und Logik
+  - `FPoint`, `FPlus`, `FMinus`, `FFirst`, `FLast`
+  - `FShow`, `FList`, `FLoad`, `FSave`, `FClear`
+- [ ] `GCode.js` auf reines G-Code-Parsing reduzieren
+- [ ] Datei-Befehle in `InputWS.js` separate behandeln und an den FileManager weiterleiten
+- [ ] Logfile-Operationen von der Steuerkreislauf-Logik entkoppeln
+- [ ] `G92`/`M92`-Verhalten im Kontext des Datei-Managements klar dokumentieren

doc/ToDo_5_API.md

@@ -0,0 +1,21 @@
+# ToDo 5 — API und Antwortlogik
+
+## Ziel der Verbesserung
+
+Die Schnittstellen sollen klar und vorhersagbar antworten. Steuerbefehle brauchen eigene Antwortpfade, und Status-/Positionsergebnisse müssen eindeutig getrennt werden.
+
+## Aufgaben
+
+- [ ] WebSocket-Antwortlogik strukturieren
+  - Steuerbefehle erhalten gezielte Responses
+  - `Ping`, `M114`, Statusabfragen und Fehlermeldungen getrennt behandeln
+- [ ] Broadcasts nur dort verwenden, wo sie sinnvoll sind
+  - Broadcasts für Status-Updates, nicht für direkte Steuerantworten
+- [ ] `InfoServer` um detaillierte Statusinformationen erweitern
+  - Senderverbindungen
+  - Health-Checks
+  - letzte Befehle / Pings
+- [ ] API-Endpunkte klar dokumentieren
+  - `/api/status`
+  - `/api/position`
+- [ ] Fehlermeldungen konsistent und maschinenlesbar machen

doc/ToDo_6_RobotController.md

@@ -0,0 +1,17 @@
+# ToDo 6 — RobotController
+
+## Ziel der Verbesserung
+
+Der `RobotController` fasst die Steuerlogik zusammen und hält den Roboterzustand vom G-Code-Parsing getrennt. So wird die Architektur modularer und leichter wartbar.
+
+## Aufgaben
+
+- [ ] `RobotController` einführen
+  - verarbeitet strukturierte G-Code-/Befehlsobjekte
+  - steuert `moveRelative`, `calculateAngles3D()`, `calculateSpeeds()` und `sendCommand()`
+- [ ] `Robot.js` als reines Modell-/Kinematik-Modul nutzen
+  - Zustand, Längen, Winkel, Kinematik-Berechnungen
+- [ ] den Übergang von Befehlsobjekt zu Motorpositionen sauber definieren
+- [ ] Logik für Bewegungsbefehle zentralisieren: `G1`, `G28`, `G90`, `G91`, `G92`, `M1`
+- [ ] rohe Textstrings aus der Controller-Schicht entfernen
+- [ ] Zustandsänderungen konsistent an die Sender weiterreichen

doc/ToDo_7_Tests.md

@@ -0,0 +1,27 @@
+# ToDo 7 — Tests und Stabilität
+
+## Ziel der Verbesserung
+
+Testabdeckung und Fehlerbehandlung sollen die Stabilität der Architektur erhöhen. Kernfunktionen müssen verlässlich arbeiten und unerwartete Zustände sauber behandeln.
+
+## Aufgaben
+
+- [ ] Unit-Tests für `GCodeParser`
+- [ ] Unit-Tests für `RobotController`
+- [ ] Unit-Tests für `TelnetSenderGRBL`
+  - Verbindungsstatus
+  - Fehlerfälle
+  - korrektes Sendeformat
+- [ ] Tests für `InputWS.js`
+  - gültige G-Code-Nachrichten
+  - Ping-Verarbeitung
+  - Statusabfragen
+- [ ] Tests für `InfoServer`
+  - `/api/status`
+  - `/api/position`
+- [ ] Fehlerfälle explizit prüfen
+  - ungültiger G-Code
+  - verlorene Telnet-Verbindung
+  - fehlende Zertifikate
+  - unvollständige Konfiguration
+- [ ] Testausführung via `npm test` sicherstellen