GRBL V1.1 Jogging mit OpenCNCPilot

Die aktuelle Version V1.1 von GRBL bietet die Möglichkeit, die Maschine mit sogenannten Jog-Befehlen anzusteuern. Der Fräskopf kann so frei positioniert werden, die Koordinaten werden mitgeführt, der G-Code Streamer - hier OpenCNCPilot - kurz OCP - weiß also, wohin der Fräskopf manuell verfahren wurde.

In OCP ist das als Keyboard-Jogging umgesetzt, nach entsprechender Vorbereitung kann die Fräse mittels der Pfeiltasten bedient werden. Leider immer nur eine Achse gleichzeitig und immer eingeschränkt in der Entfernung, die mit einem Jog-Befehl zurückgelegt werden kann. Das ist dem Sicherheitsgedanken geschuldet, denn sollte mit den Jog-Befehlen mal etwas durcheinander kommen, bleibt die Maschine spätestens nach der initial festgelegten Entfernung stehen und läuft nicht endlos.

Mein bis dato gepflegter Ansatz einer Joystick-Steuerung, logische und physikalische Trennung von GRBL und OCP von den Stepper-Endstufen mittels Interface und Generierung der Step-Impulse mit dem Arduino im Joystick, funktioniert ja inzwischen prima.

Um die oben genannten Einschränkungen zu umgehen, hatte ich schon lange den Wunsch, meinen Joystick verwenden zu können, um kontinuierliche Jog-Fahrten durchzuführen. Die notwendigen Erweiterungen in OCP habe ich aber erst jetzt, unterstützt von Gemini, in Angriff genommen und umgesetzt.

In erster Konsequenz habe ich einen “Minimal-Joystick” programmiert, der ausschließlich die Joystick-Potis abfragt und deren Werte mittels zweiter serieller Schnittstelle an OCP überträgt. In OCP wurde eine neue Klasse “JoystickService” eingebaut, die alle Aufgaben in Verbindung mit dem Joystick sauber getrennt vom Rest des Code abwickelt.

Natürlich mussten kleine Änderungen und Erweiterungen am Code von OCP vorgenommen werden, aber ich habe versucht, diese Änderungen so gering wie möglich zu halten, um die Abhängigkeit von Martins Original-Code nicht aufgeben zu müssen. Wer weiß, vielleicht baut er ja irgendwann mal tolle Features in OCP ein, in deren Genuss ich ebenfalls kommen will :)

Die erweiterten Sourcen für OCP V1.5.13.0 - Mod: Joystick Jogging sind auf Github zu finden.

Da Martin gebeten hat, die von ihm vergebene Versionierung nicht zu verändern, habe ich zur Kennzeichnung meiner privaten Version den Weg über die Mod: deHarro-Angabe  gewählt, zu finden in der About-Box rechts unten.

“Mod: deHarro” ist, angelehnt an Martins Realisierung, gleichzeitig der Link auf mein OCP Repository bei Github und mit Mouse hover wird die Version History angezeigt.

Neben den im Bild angegebenen Erweiterungen habe ich schon in den letzten Jahren das eine oder andere Goody eingebaut. Dazu gehört die Darstellung eines ViewCube rechts unten im Viewport sowie Informationen über die Kameraposition links unten.

Beides eher Gimmicks, habe ich quasi als Fingerübung in Sachen C#, Helix Toolkit und XAML angesehen. Im gleichen Zug habe ich aber auch Nettigkeiten wie “Messageboxen beim Parsen des GCode in den Vordergrund bringen” realisiert, damit man nicht vor einem schweigenden OCP View sitzt und sich fragt “warum passiert nichts”?
Als nächstes passt sich die Breite der File Listbox an die gerade dargestellte Zeilenlänge an, man kann also jetzt problemlos erkennen, welche Datei gerade geladen ist (wenn der Dateiname im GCode enthalten ist, wie das bei pcb-gcode.ulp der Fall ist). Richtig prima ist, dass die Checkmarks in den Checkboxen in der Debug Box, “Show Status Messages” und die beiden Neuen, jetzt korrekt als Haken links unten nach rechts oben dargestellt werden. Dass der Haken vorher seitenverkehrt in der Box hing, ist wahrscheinlich noch nie jemandem aufgefallen ;)

Die jetzt gerade neu implementierten Erweiterungen umfassen im Wesentlichen Dinge, die ich mir schon vor geraumer Zeit über die Issues bei Martin gewünscht habe, die Martin aber aus Zeit- oder anderen Gründen nicht oder noch nicht umgesetzt hat.

Joystick Jogging habe ich ja oben schon erklärt.

Ein weiterer Wunsch ergab sich aus der Möglichkeit, mehrere der von pcb-gcode.ulp erzeugten Dateien in einem Aufwasch zu fräsen, weil für die Freistellung der Leiterbahnen und die Texte im Milling Layer derselbe Fräser verwendet wird. Was liegt also näher, als sich die beiden Layer gleichzeitig anschauen zu können und natürlich dann auch zu fräsen.

Bis jetzt habe ich mir mit einem Makro geholfen, das im Editor die parallel geöffneten Dateien für die Leiterbahnen und den Text zusammenführt. Viel komfortabler ist natürlich, die beiden Dateien einfach nacheinander in OCP zu laden und überlagert darzustellen. Im File Dialog gibt es dafür jetzt einen neuen Button “Add Layer”. Der macht genau das, über den normalen Datei öffnen Dialog können weitere Dateien geladen werden, die dann im Viewport von OCP visualisiert werden. Die Reihenfolge des Ladens in OCP wird dabei im GCode abgebildet, heißt, die zuerst geladene Datei ist oben im GCode und wird auch zuerst abgearbeitet. Bei Leiterbahnen und Text ist das ziemlich wahlfrei, aber z.B. bei Löchern und Ausschnitten im Board und dem Ausfräsen des Umfangs ist es im Zweifel geschickter, zuerst die Löcher zu bohren, bevor das Board aus dem Material ausgeschnitten wird.

Ein Wort zu diesem Ansatz.
Eine schon seit längerem bekannte Möglichkeit in John Johnsons pcb-gcode.ulp ist, eine sogenannte Drill Rack Tabelle zu pflegen, in der angegeben wird, welchen Toolnamen welcher Bohrer hat. Eine Erweiterung dieses Schemas ist die Verwendung eines diamantverzahnten Fräsers - im Englischen Endmill - zur Erzeugung beliebig großer Löcher oder Ausschnitte mit nur einem Fräser. Der Toolname ist dann mit einem E zu starten, also E1 für den ersten Listeneintrag. In der Liste wird dann, TAB -getrennt, der Durchmesser des Fräsers, die erlaubten Minimal- und Maximaldurchmesser der mit diesem Fräser zu erstellen Bohrungen oder Löcher, die Länge des Fräsers (des diamantverzahnten Teils) und zuletzt Angaben zur Schrittweite in X/Y- sowie in Z-Richtung angegeben.

Hier beispielhaft der Inhalt meiner default.drl Datei:

# -*- Mode: Eagle -*-
#
# Sample drill rack file.
#
# drill_size is the size of the drill bit.
# minimum is the smallest hole the bit will be used for.
# maximum is the largest hole the bit will be used for.
#
# Each value can have a "unit of measure" added to it,
# such as 0.500mm . If you do not provide the unit of measure,
# values over 0.250 are considered millimeters, and
# values under 0.250 are considered inches. For example:
# 0.400 would be considered 0.400 mm.
# 0.125 would be considered 0.125 inches.
#
# To use an endmill to produce bigger holes than the
# diameter of the endmill denominate the tool with E (instead of T).
# Additionally you must provide 2 more parameters as shown below.
#
# Please note that you must use a TAB character
# between each setting on a line.
# --> Be sure to have no empty lines at the end of the file!!! <--
#
# Tip: Set the TAB size of your editor to 12 characters.
#
#tool
#        drill_size
#        |                 minimum
#        |                 |                 maximum
#        |                 |                 |                length    
#        |                 |                 |                |                 step_xy    step_z
E01    1.000mm  0.900mm  30.0mm   15.0mm   0.70mm   0.50mm
T02    1.000mm  0.600mm  1.10mm   30.0mm
T03    0.040in      0.035in      0.045in    1.5in
T04    0.050in      0.045in      0.055in    1.5in
T05    0.062in      0.055in      0.070in    1.5in
T06    0.125in      0.100in      0.125in    1.5in

Der Fräser im ersten Eintrag in der Liste hat einen Durchmesser von 1 mm und wird für die Erzeugung von Löchern und Ausschnitten ab 0,9 mm aufwärts verwendet. Ist der zu erstellende Durchmesser größer als der Fräserdurchmesser, wird der Fräser in Kreisen mit step size Z ins Material abgesenkt.

Hat man ohne Nachdenken über die Reihenfolge den Umriss zuerst geladen, muss die Reihenfolge geändert werden. Dazu gibt es hinter den Datei- bzw. Layernamen in der sich beim Laden weiterer Dateien ausklappenden Layer-Liste Buttons zum Verschieben innerhalb der Liste.

          (Click auf das Bild für größere Darstellung)

“Filtern von GCode Befehlen” ist schon länger Thema bei OCP, Martin hat über die Settings schon einige Codes selektierbar gemacht. Speziell pcb-gcode.ulp erzeugt häufiger Zeilen, die sinnlos sind und keine Bewegung des Fräsers auslösen. Nachfolgend ist so eine Zeile abgebildet:

G02 X12.8985 Y3.8100 Z-1.7500 I0.1985 J0.0000 F508.00
(last pass)
G01 Z-1.7500 F254.00
G02 X12.5015 Y3.8100 I-0.1985 J0.0000 F508.00

Die gelb markierte Zeile ist der Bösewicht. Hier wird eine Bewegung in Z auf -1,75 mm angefordert, die bereits in der Zeile oberhalb erfolgt ist. Zusätzlich wird die Verfahrgeschwindigkeit halbiert (F254.00), was aber in der darauffolgenden Zeile schon wieder aufgehoben wird (F508.00). Die Zeile nach (last pass) kann also in der Tat ohne Auswirkungen entfernt werden, was Martins Originalcode schon immer so macht.

Solche Zeilen erkennt OCP beim Laden der Datei und erklärt in einer Messagebox, dass sie gefunden wurden und man selbst überprüfen muss, ob diese Zeilen ok sind. Dass diese Messagebox aber eigentlich überflüssig ist, dennoch weggeklickt werden muss, hat mich dazu bewogen, diese Warnungen “ignoring zero-length move from line number XXX ” ausfiltern zu können.

Hinweis:
Den Haken bei “Keep Spindle ON/OFF” unbedingt setzen, sonst funktioniert die Steuerung der Spindeldrehzahl über OCP/GRBL nicht.

Im weiteren Verlauf meiner Forschungen in Sachen OCP ändern - verbessern wage ich fast nicht zu sagen ;) - habe ich einige Dinge implementiert oder geändert, deren Fehlen oder Verhalten mich beim Arbeiten mit OCP immer wieder irritiert oder gestört haben.

Dazu gehört auch die Möglichkeit, Dateien neu zu laden, sollten Änderungen daran erfolgt sein. Das Reload-Feature , zusammen mit dem Überlagern von mehreren Dateien erlaubt es, z.B. die Fräsbahnen um die Leiter herum mit dem im Milling Layer abgelegten Text abzustimmen. Hat man also im ersten Versuch den Text zu nah an den Leiterbahnen platziert, wird der Text durch die Bahnen zur Verbreiterung der Leiterbahnabstände gestört. Die Änderung in EAGLE (mein Layout-Programm) werden mit pcb-gcode.ulp neu erzeugt und müssen zur Kontrolle wieder in OCP geladen werden. Click auf Reload, fertig. Der Button sitzt in der File Box, neben dem Add Layer Button.

Koordinaten im Layout zu bestimmen hat mich schon immer gereizt, weshalb ich auch das in OCP eingebaut habe. Im gleichen Zuge habe ich implementiert, einen Punkt oder eine Fräsbahn aus dem Layout heraus per Mausklick in der File Listbox anzuspringen. Das hilft, wenn ein Fehler im G-Code manuell repariert werden muss, so geschehen bei einer meiner Wortuhren. Dort hat der Codeerzeuger wiederholbar ein Loch mitten in der Fläche erzeugt, das aus dem resultierende G-Code entfernt werden musste. Mit der jetzt implementierten Erweiterung wäre die Suche nach dem Punkt in der Datei ein Klacks gewesen.

Hinweis:
Da der Marker im Modus “Link G-Code” oberhalb der Platinenebene platziert wird, schlägt im Bild oben die perspektivische Verzeichnung zu und zeigt den Punkt leicht schräg versetzt gegenüber dem eigentlichen Einstichpunkt für das Loch an.
Update: Inzwischen habe ich die Marker in die Ebene gelegt, keine Verzeichnung mehr :)

Den angeklickten Punkt bzw. dessen Koordinaten (aus der Zeile oberhalb der im Bild hellblau markierten Zeile) kann man per Button “Send to Manual Command” in die Manual Box transferieren und so den Punkt auf der Fräse direkt anfahren. Vor Ausführung der Bewegung in X/Y wird der Fräser auf Z=5 mm gefahren. Die Bewegung wird erst ausgeführt, wenn der Button Send in der Manual Box betätigt wird.

Die Klickziele im Viewport werden jeweils mit Punkten markiert. Bei der Suche nach Koordinaten im G-Code ist der Punkt rot, werden Abstände gemessen, ist der erste Punkt blau, der zweite rot.

Beim Messen von Abständen kann durch SHIFT (auf der Tastatur) eine der beiden Achsen X oder Y festgehalten werden, der zweite Punkt liegt dann genau horizontal oder vertikal auf derselben Koordinate. Welche Achse festgehalten wird, wird aus dem Abstand zum ersten Punkt bestimmt - die Achse mit dem kürzeren Abstand wird gelockt.

Die Größe der Markierungspunkte kann zum einen über die Settings festgelegt werden, zum anderen erfolgt, ausgehend von dieser Festlegung, eine Skalierung abhängig von der Layoutgröße. Für die Messung wird das Design Format füllend gezoomt, die Marker werden beim Setzen per Klick mit dem eingestellten Defaultdurchmesser gezeichnet, sind also ggf. sehr klein. Hier hilft die automatische Skalierung.

Alle Messarten machen nur Sinn, wenn das Layout genau in der X/Y-Ebene liegt, man also senkrecht von oben auf die Platine schaut. Das wird beim Öffnen der “Inspection & Measurement” Box so eingerichtet, sprich, das Layout wird an den Achsen ausgerichtet, flach in die X/Y-Ebene gelegt und Format füllend gezoomt.

Beide Messarten sind in der neuen Box “Inspection & Measurement” zusammengefasst.

Die Box sitzt unterhalb der About Box.

“Link G-Code” und “Measure” sind Toggle-Buttons, sie lösen sich gegenseitig aus. Beim Schließen der “Inspection & Measurement” Box oder wenn die Buttons “Link G-Code” oder “Measure” deselektiert werden, werden die Marker im Layout gelöscht.

Martin hat schon länger die Möglichkeit eingebaut, das Design im Viewport an die Ausrichtung der Fräse auf dem Tisch anzupassen, er hat dafür den Button “RotateCW” implementiert.

Bei jedem Klick auf den Button rotiert das Design 90° im Uhrzeigersinn. Diese Rotation war aber immer nur während der aktuellen Frässitzung gültig, beim nächsten Neustart von OCP ging sie verloren. Das hat nicht wirklich gestört, da man das Design lädt, fräst und fertig ist. Mit den neuen Features Reload, Add Layer und der Möglichkeit einzelne Layer per Checkbox zu de-/aktivieren, ist dieses Verhalten aber nervig geworden, denn nach jedem Klick auf einen der zugehörigen Buttons ist das Design wieder in die ursprüngliche Lage zurück gesprungen. Deshalb habe ich die Rotation in den Settings verewigt und so erreicht, dass das Design schon beim Laden und auch bei jedem Klick sofort in die vorgegebene Richtung gedreht wird.

Keine Angst mehr vor dem neuen CH340 Treiber
Seit Ende 2024 verbreitet Microsoft über seinen Update-Mechanismus auch aktualisierte Treiber für die oft in Arduinos verwendeten CH340 USB-Serial Bridges. Der Treiber mit der Version 3.9 vom 16.10.2024 wird vom Hersteller des Original CH340, Fa. WCH.CN zur Verfügung gestellt und ist offenbar so geschrieben, dass Clones des Chip nicht mehr korrekt angesprochen werden können. In Folge war es nicht mehr möglich, OCP mit dem GRBL Controller zu verbinden, es wurde immer eine Exception "Fatal error in Work Loop" geworfen und die Verbindung wurde nicht aufgebaut oder sofort wieder abgebaut.

Normalerweise meldet OCP die korrekte Kontaktaufnahme mit GRBL mit dieser Meldung:

Manchmal kommt auch noch eine ausführlichere Meldung in dieser Form:

Der Unterschied scheint nach meinen Beobachtungen am Timing bei der Kontaktaufnahme zu liegen, denn mit einer längeren Pause nach dem open() kommt nur die kurze Meldung, bei einer kürzeren Pause kommt erstaunlicherweise die Längere.

Erscheinen solche Fragmente (mindestens die beiden einleitenden Zeichen “<“ und ein Blank fehlen jeweils)...

... dann wurde zwar die Verbindung aufgebaut und gehalten, aber die Daten von GRBL Richtung OCP werden nicht korrekt übertragen. Der GRBL-Parser von OCP filtert alle korrekt erkannten GRBL-Meldungen aus, angezeigt werden im Log normalerweise nur die G-Code-Befehle von OCP an GRBL oder Texte, die nicht als GRBL-Statusmeldungen erkannt werden.

Der schnelle Workaround ist, einen älteren Treiber für den CH340, z.B. V3.4 vom 08.08.2014, zu installieren und Updates für Treiber über den Microsoft-Mechanimus zu deaktivieren.

Da aber mit LaserGRBL ein G-Code Streamer existiert, der sich von diesen Kleinigkeiten nicht von der Zusammenarbeit mit Arduinos mit CH340 und aktualisiertem Treiber abhalten lässt, habe ich mich entschlossen, mit Unterstützung durch Gemini auch eine Lösung für OpenCNCPilot zu erarbeiten. Durch Umstellung der GRBL-Kommunikation in OCP vom original Event getriebenen ReadLine() Ansatz, üblich in .NET Applikationen mit serieller Kommunikation, auf eine pollende, Byte orientierte Lösung, ist es mir gelungen, OCP mit dem neuen Treiber anzufreunden. Das Release V2.06 meines OpenCNCPilot Forks stellt dieses Feature - und einige andere - für Interessierte zur Verfügung.

Die mir zur Verfügung stehenden Rechner, auf denen ich OCP testen kann, sind allesamt recht performant unterwegs. Ich bitte um Rückmeldung, falls diese Implementierung auf langsameren Rechner Probleme macht.

Diese Frage hat mir natürlich keine Ruhe gelassen. Ich habe meine aktuelle OCP-Version auf einem kleinen Spiel-Tablet mit Intel Atom CPU Z3736F @ 1,33 GHz, 2 GB RAM, unter Windows 10 laufend, installiert und einen Fräsjob simuliert. Es sind keinerlei Probleme zu erkennen. Selbst wenn ich während des laufenden Fräsvorgangs mit der Maus den Viewport schwenke oder drehe läuft der Prozess unbeeindruckt weiter. Die Umstellung auf Lesen einzelner Bytes scheint also keine Probleme zu implizieren.

Im Zuge der Arbeiten an OCP habe ich auch in pcb-gcode.ulp Verbesserungen eingebaut.

---

Um die Akzeptanz des Jogging per Joystick für andere Nutzer von OCP zu erhöhen, habe ich das von mir ursprünglich aus Alu erstellte Joystickgehäuse für den 3D-Drucker nachempfunden.

Die Beschreibung und die notwendigen Unterlagen finden sich auf einer eigenen Seite.

Um die Akzeptanzschwelle noch weiter zu senken, habe ich einen Minimal-Joystick entworfen, der per USB-Kabel an den Rechner mit OpenCNCPilot angeschlossen wird und in Verbindung mit meiner Version von OpenCNCPilot die Steuerung der Fräse per Jog-Kommandos erlaubt.