appRobotDriver/doc/ToDo_6_RobotController.md

ToDo 6 — RobotController

✅ Status: erledigt

Steuerlogik in robot/RobotController.js ausgelagert; GCode.receiveGCode() ist nur noch Fassade. Tests: test/RobotController.test.js (+ alle bestehenden GCode.*-Tests laufen unverändert über die Fassade).

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 (robot/RobotController.js)
  • verarbeitet strukturierte G-Code-/Befehlsobjekte (applyCommand, receive)
  • steuert moveRelative, calculateAngles3D() 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(=M92), M1
• rohe Textstrings aus der Controller-Schicht entfernen (Controller arbeitet nur auf geparsten Objekten)
• Zustandsänderungen konsistent an die Sender weiterreichen (über robot.sendCommand())

Status

• Erledigt. Die Dispatch-Logik wurde aus GCode.receiveGCode() in RobotController ausgelagert. GCode.receiveGCode() bleibt als dünne Fassade erhalten (delegiert an RobotController.receive()), damit bestehende Aufrufer und Datei-Befehle unverändert funktionieren.
• calculateSpeeds() wird bewusst weiterhin innerhalb von robot.sendCommand() ausgelöst (Geschwindigkeit ist eine Modell-Eigenschaft, die der Controller über sendCommand anstößt — siehe ToDo_6a).
• Tests: test/RobotController.test.js (Controller direkt), alle bestehenden GCode.*-Tests laufen unverändert über die Fassade.