Fileservice

README.md

@@ -7,8 +7,9 @@ Dieses Projekt empfängt G-Code und Robotersteuerbefehle, berechnet Inverse Kine
 - `startRobot.js` startet zwei HTTPS-Server:
   - Eingabe-Server + WebSocket für G-Code und Steuerbefehle
   - Info-Server für Status, Position und einfache Weboberfläche
-- `server/InputWS.js` empfängt Nachrichten von WebSocket-Clients, prüft sie auf G-Code oder Datei-Kommandos und gibt Positionsdaten zurück.
-- `robot/GCode.js` verarbeitet G-Code, übersetzt ihn in Roboter-Koordinaten und triggert `robot.sendCommand()`.
+- `server/InputWS.js` empfängt Nachrichten von WebSocket-Clients, routet G-Code-Befehle lokal und leitet FCodes via `robot/FCodeClient.js` an `appRobotFileservice` weiter.
+- `robot/GCode.js` verarbeitet G-Code, übersetzt ihn in Roboter-Koordinaten und triggert `robot.sendCommand()` (kein Datei-Handling mehr).
+- `robot/FCodeClient.js` übersetzt FCodes (`FPoint`, `FPlus`, …) in REST-Aufrufe an `appRobotFileservice` (Gateway-Funktion des Drivers).
 - `robot/RobotBase.js` ist die abstrakte Basisklasse / der Interface-Vertrag: generische Infrastruktur (Zustand, `sendCommand`, Motor-Geschwindigkeiten) plus die zwei abstrakten Kinematik-Methoden.
 - `robot/kinematics/Arm3SegmentLinearX.js` ist die konkrete Kinematik (Inverse + Vorwärts) für den aktuellen Arm. Die Auswahl der Kinematik erfolgt über `robot/KinematicsFactory.js` (Umgebungsvariablen `ROBOT_KINEMATICS` / `ROBOT_KINEMATICS_PARAMS`). Siehe `doc/ToDo_12_InverseKinematikConfig_ROADMAP.md`.
 - `robot/RobotConfig.js` liest `data/robot/robot.json` beim Start synchron und gibt einen typisierten Konfigurations-Record zurück (Kinematik-Parameter, Bewegungs-Defaults, Controller-Endpunkte). Env-Variablen überschreiben die JSON-Werte.
@@ -30,10 +31,11 @@ Die Eingaben kommen per WebSocket an den HTTPS-Server und werden in `server/Inpu
   - `G92` (wird intern als `M92` verarbeitet — setzt Motorposition ohne Bewegung)
   - Messungen in `X`, `Y`, `Z`, `A`, `B`, `C`, `E`, `F`
   - `M1` für direkte Motor-Koordinaten
-- Datei-Kommandos:
-  - `FPoint`, `FPlus`, `FMinus`, `FShow`, `FList`, `FLoad <file>`, `FSave <file>`, `FClear`
-  - `FFirst`, `FLast` — erkannt, aber noch nicht implementiert
-  - `M20`, `M23`, `M28`, `M29`
+- FCodes (Datei-/Programm-Befehle) — werden durch den Driver an `appRobotFileservice` weitergeleitet:
+  - `FPoint`, `FPlus`, `FMinus`, `FFirst`, `FLast`, `FGoto <n>`
+  - `FShow [id]`, `FList`, `FLoad <id>`, `FSave <name>`, `FClear`
+  - `FPlay`, `FStop`
+  - Vollständige API: `doc/fileserviceAPI.md`
 
 ### G-Code-Verarbeitung
 
@@ -48,7 +50,7 @@ Die Eingaben kommen per WebSocket an den HTTPS-Server und werden in `server/Inpu
 
 - WebSocket-Broadcasts an alle verbundenen Clients
   - Nachdem ein G-Code-Befehl verarbeitet wurde, sendet das System `GCode.getM114(robot)` zurück.
-  - Für Datei-Kommandos gibt `GCode.receiveFC()` ebenfalls die aktuelle Position zurück.
+  - Für FCodes leitet der Driver das Ergebnis von `appRobotFileservice` weiter (Stepping-Befehle zusätzlich als Pose-Broadcast nach lokaler Ausführung).
 - Telnet-Ausgabe an GRBL/FluidNC-Geräte
   - `TelnetSenderGRBL.execCommand()` erzeugt `G1`/`G90`-Befehle mit Achsenzuordnung und Feedrate.
 - Info-Server API
@@ -103,6 +105,10 @@ Die Eingaben kommen per WebSocket an den HTTPS-Server und werden in `server/Inpu
   - Statischer Bearer-Token für `PUT /api/robot`. Fehlt die Variable, generiert
     `RobotConfigService` beim ersten Start einen zufälligen Key und speichert ihn in
     `data/robot/.apikey` (nicht im Repo). Der Key wird beim Start einmalig geloggt.
+- `FILESERVICE_URL`
+  - Standard: `http://appRobot_Fileservice:2100`
+  - URL der `appRobotFileservice` — wird von `robot/FCodeClient.js` verwendet.
+    Im Container-Netz entspricht das dem Docker-Dienstnamen aus dem Portainer-Stack.
 - `SHELLY_URL`
   - URL für den Shelly Smart Plug Emergency-Stop: `http://<IP>/rpc/Switch.Set?id=0&on=false`
   - Überschreibt `controllers.emergencyStop.url` aus `robot.json` (analog zu `GRBL_BASE_IP`).
@@ -208,11 +214,12 @@ Socket geschlossen und der bestehende Reconnect-Mechanismus startet automatisch.
 - `data/robot/robot.json` — zentrale Roboter-Konfiguration (Single Source of Truth)
 - `robot/GCodeParser.js` — wandelt rohe Nachrichten in strukturierte Befehlsobjekte
 - `robot/RobotController.js` — wendet geparste Befehle auf das Modell an (Steuerlogik)
-- `robot/GCode.js` — Fassade + Datei-Befehle
+- `robot/GCode.js` — Fassade für G-Code-Verarbeitung (Bewegung, Pose, Logging)
+- `robot/FCodeClient.js` — Gateway: übersetzt FCodes in REST-Aufrufe an `appRobotFileservice`
 - `robot/TelnetSenderGRBL.js`
 - `robot/ShellyEmergencyStop.js` — steuert Shelly Smart Plug als Emergency-Stop-Aktor (HTTP GET, kein GCode)
 - `robot/fluidnc/FluidNCClient.js` — alternative WebSocket-basierte FluidNC-Anbindung mit Reconnect-Logik (noch nicht integriert)
-- `GCodeFiles/` — enthalten Beispiel- und Log-G-Code-Dateien
+- `GCodeFiles/` — G-Code-Programme werden jetzt in `appRobotFileservice` verwaltet
 
 ## Laufzeitvoraussetzungen
 
@@ -235,8 +242,7 @@ Architektur- und Refactoring-Aufgaben sind in `doc/ToDo_*.md` dokumentiert:
 | `doc/ToDo_6_RobotController.md` | RobotController-Klasse einführen | ✅ erledigt |
 | `doc/ToDo_6a_Speed.md` | Speed-Steuerung: Schalter, `calculateSpeeds()`-Fix, koordinierte Feedrate | ✅ erledigt (WS-Sender offen) |
 | `doc/ToDo_6b_FileHandling.md` | File-Handling: fehlende Befehle, Cursor im Speicher, Fehler-Feedback | ✅ ausgelagert → `appRobotFileservice` |
-| `doc/draft_filehandeling.md` | File-Handling als externes Projekt `appRobotFileservice` (Driver als Gateway, FCode-Pass-through) | Entwurf |
-| `doc/draft_filehandeling_API.md` | API der `appRobotFileservice` (Programme, aktiver Cursor, Teaching/Playback) | Entwurf |
+| `doc/fileserviceAPI.md` | REST-API der `appRobotFileservice` (Programme, aktiver Cursor, Teaching/Playback) | ✅ implementiert |
 | `doc/ToDo_7_Tests.md` | Testabdeckung und Stabilität | teilweise |
 | `doc/ToDo_8_Bugs.md` | Bekannte konkrete Bugs | teilweise |
 | `doc/ToDo_9_HardwareFeedback.md` | Hardware-Feedback-Loop (GRBL-Antworten, Command-Queue, Positionsabgleich) | teilweise (Baustein Port→Motor ✅, Pakete 1–6 offen) |
@@ -266,7 +272,7 @@ ToDo_7  Tests                 — begleitend zu allen obigen
 Kurzübersicht weiterer offener Punkte:
 
 - [ ] Dokumentation der vollständigen G-Code-Syntax erweitern
-- [x] `FFirst`/`FLast` (und übriges File-Handling) → ausgelagert in `appRobotFileservice` (siehe `doc/draft_filehandeling.md`)
+- [x] `FFirst`/`FLast` und gesamtes File-Handling → ausgelagert in `appRobotFileservice` (siehe `doc/fileserviceAPI.md`)
 - [ ] `ROBOT_USE_SPEED_CALC` und `motorSpeeds` im echten Betrieb prüfen
 - [ ] `FluidNCClient.js` evaluieren: als Ersatz oder Ergänzung zu `TelnetSenderGRBL`?
 - [x] HTTPS-Passphrase aus Env-Variable (`HTTPS_PASSPHRASE`) — erledigt