Files
appRobotDriver/doc/ToDo_2_Anbindung.md
2026-06-08 17:28:43 +02:00

2.1 KiB

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 (→ 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
  • 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.
  • 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.