GRBL V1.1 Jogging

GRBL in der seit einiger Zeit aktuellen Version V1.1 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# und 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 geraden 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.

Auch in pcb-gcode.ulp habe ich 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.

Dieser Ansatz hat den bestechenden Vorteil, das die Ausbrüche für die Joysticks und Schalter nicht mühsam aus dem Alu geschnitzt werden müssen, sondern einfach nicht gedruckt werden ;)

Der Innenteil zur Befestigung der beiden Daumen-Joysticks wird gleich mitgedruckt.