173 lines
6.6 KiB
Markdown
173 lines
6.6 KiB
Markdown
# AppRobotDriver
|
|
|
|
Dieses Projekt empfängt G-Code und Robotersteuerbefehle, berechnet Inverse Kinematik für einen mehrgliedrigen Roboterarm und leitet die resultierenden Achsenbefehle an mehrere GRBL/FluidNC-Telnet-Sender weiter.
|
|
|
|
## Architektur
|
|
|
|
- `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()`.
|
|
- `robot/Robot.js` führt die Inverse Kinematik aus und berechnet Motorwinkel sowie optionale Motor-Geschwindigkeiten.
|
|
- `robot/TelnetSenderGRBL.js` formatiert die Motor-Positionen in GRBL-kompatible Befehle und sendet sie per Telnet an einen Zielcontroller.
|
|
|
|
## Eingaben
|
|
|
|
Die Eingaben kommen per WebSocket an den HTTPS-Server und werden in `server/InputWS.js` verarbeitet.
|
|
|
|
### Unterstützte Nachrichten
|
|
|
|
- `Ping`
|
|
- Antwort: Wird zurück an alle verbundenen Clients gesendet.
|
|
- `M114`
|
|
- Antwort: Positionsdaten des Roboters im JSON-Format.
|
|
- G-Code-Befehle:
|
|
- `G90`, `G91`, `G1`, `G28`
|
|
- `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`
|
|
|
|
### G-Code-Verarbeitung
|
|
|
|
- `GCode.receiveGCode(robot, message)`
|
|
- Gruppiert Zeilen, unterstützt Inline-Jogging (`$J=`)
|
|
- Schaltet zwischen absoluter und relativer Koordinatenverarbeitung
|
|
- Aktualisiert Position und Winkel im `robot`-Objekt
|
|
- Führt inverse Kinematik aus mit `robot.calculateAngles3D()`
|
|
- Sendet das Ergebnis an `robot.sendCommand()`
|
|
|
|
## Ausgaben
|
|
|
|
- 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.
|
|
- Telnet-Ausgabe an GRBL/FluidNC-Geräte
|
|
- `TelnetSenderGRBL.execCommand()` erzeugt `G1`/`G90`-Befehle mit Achsenzuordnung und Feedrate.
|
|
- Info-Server API
|
|
- `/api/status` — zeigt Client-Status, Sender-Status und letzte Befehle/Pings an
|
|
- `/api/position` — gibt die aktuelle Roboterposition und Motorwinkel als JSON zurück
|
|
|
|
## Konfiguration
|
|
|
|
### Starten
|
|
|
|
- `npm start`
|
|
- Alternativ: `node startRobot.js`
|
|
|
|
### Umgebungsvariablen
|
|
|
|
- `PORT`
|
|
- Standard: `2095`
|
|
- Port für den WebSocket/HTTPS-Eingabeserver
|
|
- `GRBL_BASE_IP`
|
|
- Standard: `fluidNcBase.local`
|
|
- Zielhost für den ersten Telnet-Sender
|
|
- `GRBL_ELLBOW_IP`
|
|
- Standard: `fluidNcEllbow.local`
|
|
- Zielhost für den Ellbogen-Sender
|
|
- `GRBL_HAND_IP`
|
|
- Standard: `fluidNcHand.local`
|
|
- Zielhost für den Hand-Sender
|
|
- `ROBOT_DEFAULT_FEEDRATE`
|
|
- Standard: `1000` (mm/min)
|
|
- Default-Feedrate für `G1`-Befehle, wenn keine `F`-Angabe vorhanden ist
|
|
- `ROBOT_USE_SPEED_CALC`
|
|
- Werte: `true`, `1` oder sonst leer
|
|
- Wenn gesetzt, werden `robot.calculateSpeeds()` und interne Motor-Geschwindigkeiten verwendet
|
|
|
|
### HTTPS-Konfiguration
|
|
|
|
- `https/localhost.key`
|
|
- `https/localhost.pem`
|
|
- Passphrase aktuell hart codiert als `abcd`
|
|
|
|
### Telnet-Sender-Konfiguration
|
|
|
|
In `startRobot.js` werden drei `TelnetSenderGRBL` Instanzen erzeugt:
|
|
|
|
- `telnetSender1` → Basisachse(n): `x`, `y`, `z`
|
|
- `telnetSender2` → Ellbogenachse: `a`
|
|
- `telnetSender3` → Handachsen: `c`, `e`, `b`
|
|
|
|
Die Achszuordnung kann in `robot/TelnetSenderGRBL.js` durch Anpassung der Konstruktorparameter geändert werden.
|
|
|
|
## Serverschnittstellen
|
|
|
|
### WebSocket Input Server
|
|
|
|
- Läuft auf `https://localhost:<PORT>`
|
|
- Erwartet WebSocket-Verbindungen und verarbeitet Nachrichten als G-Code oder Steuerbefehle
|
|
|
|
### Info Server
|
|
|
|
- Läuft auf `https://localhost:2098`
|
|
- Statische Dateien:
|
|
- `/`
|
|
- `/app.js`
|
|
- `/style.css`
|
|
- `/allApps.css`
|
|
- API-Endpunkte:
|
|
- `/api/status`
|
|
- `/api/position`
|
|
|
|
## Wichtige Dateien
|
|
|
|
- `startRobot.js`
|
|
- `server/InputWS.js`
|
|
- `server/InfoServer.js`
|
|
- `robot/Robot.js`
|
|
- `robot/GCode.js`
|
|
- `robot/TelnetSenderGRBL.js`
|
|
- `robot/fluidnc/FluidNCClient.js` — alternative WebSocket-basierte FluidNC-Anbindung mit Reconnect-Logik (noch nicht integriert)
|
|
- `GCodeFiles/` — enthalten Beispiel- und Log-G-Code-Dateien
|
|
|
|
## Laufzeitvoraussetzungen
|
|
|
|
- Das Verzeichnis `logs/` muss im Arbeitsverzeichnis existieren, da `InputWS.js` dort `pings.log` und `gcode_commands.log` schreibt.
|
|
- HTTPS-Zertifikate: `https/localhost.key` und `https/localhost.pem` (Passphrase aktuell hardcoded `abcd`).
|
|
- Die Telnet-Sender werden erst nach 5 Sekunden zum Roboter hinzugefügt, damit die Verbindungen Zeit haben aufzubauen.
|
|
|
|
## ToDo / Open Tasks
|
|
|
|
Architektur- und Refactoring-Aufgaben sind in `doc/ToDo_*.md` dokumentiert:
|
|
|
|
| Datei | Thema |
|
|
|---|---|
|
|
| `doc/ToDo_1_Parsing.md` | G-Code-Parser-Schicht einführen |
|
|
| `doc/ToDo_2_Anbindung.md` | Sender-Interface und Orchestrierung |
|
|
| `doc/ToDo_3_Config.md` | Zentralisierte Konfiguration |
|
|
| `doc/ToDo_4_GCode.md` | G-Code- und Datei-Handling trennen |
|
|
| `doc/ToDo_5_API.md` | WebSocket-Antwortlogik strukturieren |
|
|
| `doc/ToDo_6_RobotController.md` | RobotController-Klasse einführen |
|
|
| `doc/ToDo_7_Tests.md` | Testabdeckung und Stabilität |
|
|
| `doc/ToDo_8_Bugs.md` | Bekannte konkrete Bugs |
|
|
| `doc/ToDo_9_HardwareFeedback.md` | Hardware-Feedback-Loop (GRBL-Antworten, Command-Queue, Positionsabgleich) |
|
|
|
|
### Empfohlene Bearbeitungsreihenfolge
|
|
|
|
```
|
|
ToDo_8 Bugs beheben — kurz, blockiert nichts anderes
|
|
ToDo_3 Config — Fundament für alles Weitere
|
|
ToDo_1 Parser ┐
|
|
ToDo_6 RobotController ┘ zusammen, da eng verzahnt
|
|
ToDo_4 Datei-Handling — danach, klar abgrenzbar
|
|
ToDo_2 Sender-Interface — mit Entscheidung: Telnet vs. FluidNC-WebSocket
|
|
ToDo_9 Hardware-Feedback — baut auf ToDo_2 auf
|
|
ToDo_5 API — parallel zu ToDo_2/4 möglich
|
|
ToDo_7 Tests — begleitend zu allen obigen
|
|
```
|
|
|
|
Kurzübersicht weiterer offener Punkte:
|
|
|
|
- [ ] Dokumentation der vollständigen G-Code-Syntax erweitern
|
|
- [ ] `FFirst`/`FLast`-Befehle in `GCode.receiveFC()` implementieren
|
|
- [ ] `ROBOT_USE_SPEED_CALC` und `motorSpeeds` im echten Betrieb prüfen
|
|
- [ ] `FluidNCClient.js` evaluieren: als Ersatz oder Ergänzung zu `TelnetSenderGRBL`?
|
|
- [ ] HTTPS-Konfiguration und Zertifikatsverwaltung verbessern (Passphrase aus Env-Variable)
|
|
- [ ] `logs/`-Verzeichnis beim Start automatisch anlegen
|