CNC-Software

GRBL

Die Software ist der einzige Teil der Fräse, den ich nicht komplett selbst entwickelt habe, sondern bei dem ich zum Teil auf bestehende Projekte zurückgriff. Für die Steuerung wurde die Software GRBL verwendet, ein Open-Source-Projekt, das auch von kommerziellen Produkten genutzt wird. Es wurde für einen Arduino Uno entwickelt, also für einen ATmega328 Mikrocontroller. Da ich jedoch, wie im Artikel zur Elektronik beschrieben, einen AT90USB1286 nutzte, musste ich die Software etwas anpassen. Die Basis bildete die Version 0.9g von GRBL mit dem Stand vom 5.9.2014 (Build-Nr. 20140905). Mittelfristig möchte ich meine Änderungen auf GitHub veröffentlichen, aber zunächst möchte ich sie hier beschreiben und den Code zum Download anbieten.

Die größte Änderung war die Umstellung von der UART-Kommunikation auf die USB-Schnittstelle, die der AT90USB1286 mitbringt. Dafür wurde der Code für einen virtuellen Seriellport des Teensy-Projekts verwendet. Ein Problem dabei war jedoch, dass die Zeichen nun nicht mehr einzeln, sondern blockweise empfangen wurden. Für die normalen G-Code-Maschinenbefehle war das egal, da diese ohnehin zunächst in einen Puffer zur späteren Auswertung kopiert wurden, allerdings nutzt GRBL auch einige Sonderzeichen, die unmittelbar nach dem Empfang eine Aktion ausführen. GRBL macht sich dabei zu Nutze, dass für jedes empfangene Zeichen ein Interrupt ausgelöst wird. In diesem wird geprüft, ob es sich um ein solches Sonderzeichen handelt, und dann je nachdem die entsprechende Aktion ausgelöst. Das Hauptproblem war der Status-Report-Befehl, welcher die Software dazu veranlasst, die aktuelle Maschinenposition und auf Wunsch auch einige andere Parameter anzuzeigen. Da man diese Parameter am liebsten immer im Blick hat, wird der Status-Report-Befehl von der Steuerung regelmäßig gesendet. Das Problem ist, dass bei Nutzung des USB-Ports nicht mehr jedes Zeichen direkt gesendet wird, sondern der USB-Controller des Mainboards bzw. der USB-Stack des Betriebssystems koordinieren den Versand der Daten. So kann man eine ganze Textdatei mit einmal versenden, ohne dass der Controller aus dem Tritt kommt. Er teilt dem Computer selbstständig mit, wann er bereit ist, neue Zeichen zu verarbeiten, und auch die korrekte Übertragung wird über das USB-Protokoll sichergestellt. Leider kann so aber nicht einfach ein einzelnes Zeichen unmittelbar gesendet werden, sondern dieses wird erst vom Controller empfangen, wenn die Warteschlange aus zuvor gesendeten Zeichen abgearbeitet ist. Um dennoch regelmäßige Statusreports zu bekommen, während parallel die Bewegungsbefehle übertragen werden, wurde der GRBL-Code so modifiziert, dass er diese Statusrepots selbständig in regelmäßigen Abständen sendet, ohne dass er den Status-Report-Befehl empfangen muss. Dafür wurde die Konfigurationsvariable, mit der eingestellt werden konnte, welche Daten bei einem Statusreport gesendet werden, erweitert, so dass zudem das automatische Senden und auch die Dauer des Intervalls bestimmt werden konnte.

Die weiteren Änderungen waren alles Anpassungen für den neuen Mikrocontroller. Dieser hat andere Timer und andere externe Interrupts, was einige kleine Änderungen erforderlich machte. Es folgt eine Liste von allen Änderungen, die am Original-GRBL-Code vorgenommen wurden, und in der auch vermerkt ist, welche Dateien verändert wurden:

serial.h:

Umstellung auf USB mit Teensy V1.7 virtual com port in neue Dateien (usb_serial.h/c)
In serial_read() werden nun auch die Sonderfunktionszeichen ausgewertet und entsprechende Aktionen getriggert. Das passierte vorher in der Interruptroutine des Seriellports.

cpu_map.h:

eigenes CPU-Mapping (Registerdefinitionen) für den AT90USB1286 mit 2 Endschaltern pro Achse
cpu_map.h: Disable-Pins für die 4 Achsen definiert und in die STEPPERS_DISABLE_MASK eingetragen

system.c:

Pin-Change Interrupt für die 3 Taster (Reset/Hold/Start) durch die externen Interrupts INT4,INT5 und INT7 ersetzt

stepper.c:

STEPPERS_DISABLE_BIT durch STEPPERS_DISABLE_MASK ersetzt

limits.c

zusätzliche Endschalter bekannt gemacht

protocol.c

Timer 2 zum automatischen Senden des Statusreports benutzt

PC-Steuersoftware

Es gibt einige freie open-source-Steuerprogramme für GRBL, weshalb es zunächst nahe lag, eine fertige Lösung zu verwenden. Da ich selbst einige Erfahrung mit Qt hatte wollte ich auch ein QT-Programm zur Steuerung der Fräse einsetzen. Daher fiel meine Wahl zunächst auf Grbl Controller 3.0. Da ich jedoch, wie bereits geschrieben, die Kommunikation zwischen PC und Fräsensteuerung etwas verändert hatte, funktionierte das Programm nicht auf Anhieb. Als ich den Code anpassen wollte, stellte ich fest, dass er insgesamt viel komplexer als nötig war. Das lag sowohl an der Vorschau-Funktionalität als auch an der allgemeinen Architektur. Die Vorschaufunktion war zwar sehr praktisch, aber für mich nicht unbedingt nötig, da es auch andere freie Programme gibt, mit denen man G-Code simulieren kann. Wenn so ein optionales Feature dazu führt, das Volumen und die Komplexität des Quellcodes zu verdoppeln, verzichte ich lieber darauf. Ein Programm, das so kritische Aufgaben erfüllt wie das Steuern einer Werkzeugmaschine, muss meiner Ansicht nach so schlank wie möglich sein, damit sich Bugs nur schwer verstecken können. Hinzu kam, dass das Programm für die Kommunikation einen eigenen Thread nutzte, was nicht notwendig war und die Komplexität weiter erhöhte. Dies machte es auch besonders aufwändig, die Kommunikation anzupassen. Das Programm nutzte das Qt-Plugin QextSerialPort, mit dem ich zwar schon sehr gute Erfahrungen gemacht habe, es aber trotzdem nicht mehr verwenden will, da Qt seit der Version 5 nativ Seriellportunterstützung bereitstellt. Insgesamt hatte das Programm ca. 30.000 Codezeilen, wovon fast 20.000 auf eine Bibliothek für Logfunktionen entfiel, deren Notwendigkeit sich mir nicht ganz erschloss. Das eigentliche Programm hatte fast 7.000 Zeilen, wovon vermutlich über die Hälfe für die Vorschaufunktion benötigt wurden. Die Unzufriedenheit mit dem Code weckte in mir den Ehrgeiz, ein eigenes Programm zu schreiben, dass alle Aufgaben erfüllte und dabei deutlich kleiner und übersichtlicher war. Nur auf Vorschaufunktion sollte zunächst verzichtet werden.

Die Basis des Programms war ähnlich wie die der Steuerung meines Reflowofens. Das Programm sucht anhand von der USB-IDs (VID und PID) nach dem Controller und baut eine Verbindung auf. Dann werden Befehle an das Gerät gesendet und empfangene Antworten ausgewertet. Letztere sind vor allem die Statusnachrichten, aus denen der Maschinenzustand und die Position ausgelesen und zur Anzeige gebracht werden. Das Senden von Befehlen geschieht zum Teil automatisch, jedoch sind auch für alle GRBL-Steuerbefehle ($, $#, $X, ...) Buttons vorhanden. Die gesendeten und empfangenen Daten werden in einem Textfenster farblich markiert angezeigt, wobei die zyklischen Statusmeldungen für bessere Übersichtlichkeit versteckt werden können. Es gibt einen Dialog zum Anzeigen und Editieren der GRBL-Parameter, der Teilweise von der Grbl-Controller-3.0-Software übernommen wurde. Allerdings wurde die Zuordnung der Parameterwerte zu ihren Indizes automatisiert (hier gab es Probleme, wenn die Nummerierung der Parameter nicht durchgängig war) und es wurde durch eine farbliche Hinterlegung angezeigt, welche Parameter verändert wurden. Zum manuellen Bewegen wurden einige Bedienelemente hinzugefügt, mit denen Geschwindigkeit und Entfernung eingestellt und die Fräse bewegt werden konnte. Dabei wurde auch eine Funktion für manuelles kontinuierliches Verfahren, so genanntes Jogging, implementiert. Das Problem dabei war, dass der GRBL-Code das nicht direkt unterstützt, sondern nur G-Code-Befehle kennt, um eine definierte Strecke zu verfahren. Daher wurde ein Timer genutzt, mit dem bei Bedarf fünfmal pro Sekunde ein solcher Verfahrbefehl gesendet wurde. Die Strecke des Verfahrbefehls wurde danach errechnet, wie weit die Fräse in dieser Fünftelsekunde bei der eingestellten Geschwindigkeit kommt. Das Ergebnis war einwandfrei. So lange ein Button gedrückt wurde, bewegte sich die Fräse mit der eingestellten Geschwindigkeit und hörte beim Loslassen sofort damit auf. Auch das Ein- und Ausschalten der Frässpindel ließ sich über einen Button steuern. Neben dem Fenster das die Kommunikation protokollierte, war ein Fenster, in das der G-Code kopiert oder aus einer Datei geladen werden konnte. Hier wurde die Klasse QSyntaxHighlighter verwendet, um Schlüsselwörter und Parameter farblich zu markieren. Dieser G-Code konnte auf Befehl an die Fräse übertragen werden. Abschließend wurde noch ein Gampad eingebunden, dass ebenso wie die Buttons der Software zum manuellen Verfahren, Steuern der Spindel und zum Nullen der Koordinaten genutzt werden kann. Da hier die Windows-eigenen Gamepad-Funktionen genutzt werden, ist dieser Teil der Software nicht Cross-Plattfom-fähig, jedoch wird er über Defines automatisch deaktiviert, wenn das Programm für Linux compiliert wird.

Insgesamt besteht das Programm aus lediglich etwas mehr als 1250 Zeilen, wobei ca. 250 für das Synthaxhighlighting und ein individuelles Widget zur Anzeige einer Signalleuchte verwendet werden. Noch einmal etwas mehr als 100 Zeilen entfallen auf die Implementierung des Gamepads und ca. 200 auf den Konfigurationsdialog. Die gesamte Kernfunktion zum Erzeugen und Auswerten der Kommunikationsbefehle ist in weniger als 500 Codezeilen implementiert und das, obwohl auch eine Jogging-Funktionalität enthalten ist, die bei einigen GBRL-Steuerprogrammen fehlt. Letztendlich war ich mit dem Ergebnis sehr zufrieden und hatte ein extrem schlankes, aber dennoch funktionelles Programm zum Steuern meiner Fräse.

Erweiterungen: 3D-Vorschau, Probing und Lochschneidetool

Inzwischen habe ich selbst eine Vorschaufunktion geschrieben. Sie nutzt das QGLWidget um OpenGl in Qt zu nutzen. Dieses Tutorial hier hat mir dabei sehr geholfen. Ein 3D-Fenster, in dem man den Fräserpfad anzeigen und bei dem man mit der Maus die Perspektive ändern kann, konnte ich damit mit nur etwas mehr als 300 Zeilen Code realisieren. Dazu kommt noch der eigentliche G-Code-Parser der in 100 Codezeilen einen G-Code in eine Reihe von Punkten übersetzt, die dann im OpenGL-Fenster als Pfad dargestellt werden.

GRBL unterstützt den G38.2-Befehl für das Kantentasten (Probing). Hierfür wurde ein kleiner Dialog erstellt. Man kann die Achse, die Strecke und die Geschwindigkeit wählen mit der der Befehl ausgeführt wird. Die Fräse fährt dann die Strecke ab und stoppt sofort wenn ihr Kantentaster ein Signal gibt. Da ich oft einfach ein Stück Platine auf mein Werkstück lege, das beim Kontakt mit dem Fräser einen Stromkreis schließt, gibt es die Möglichkeit die Dicke des "Tasters" einzustellen und dann automatisch nach dem Probing die Position auf diesen Wert zu setzen.

Da meine Version von Estlcam Keisausschnitte stufenweise fräst, GRBL aber das schnellere und laufruhigere helikale Fräsen unterstützt, habe ich ein kleines Tool geschrieben, mit dem man G-Code für das helikale Fräsen von Kreisausschnitten erzeugen kann. In Version 1.1 habe ich das Tool dann in die Steuersoftware integriert.

BILD-FEHLT

Komplettüberarbeitung: flexibles Layout, Gamepad-Konfiguration, nativer GRBL-Support

Anfang 2018 wurde das Programm noch einmal komplett überarbeitet. Das Layout wurde dahin gehend angepasst, dass alle wichtigen Module in so genannten Docking-Fenstern überführt wurden, die frei im Programmfenster platziert und bei Bedarf auch übereinandergelegt bzw. geschlossen werden können. So brauche ich selbst zum Beispiel so gut wie nie die Maschinenkoordinaten, da ich nur mit den aktuellen Werkstückkoordinaten arbeite. Auch muss ich den G-Code-Editor während die Maschine läuft nicht sehen, und habe dann lieber eine größere Darstellung der 3D-Vorschau.

Im Zuge dieser Änderung wurde auch das Com-Interface überarbeitet, so dass es jetzt auch mit der normalen GRBL-Software (Arduino) funktioniert. Ebenso wurde ein Dialog erstellt mit dem man die Tastenbelegung des Gamepads anpassen kann (X- und Y-Achse sind bisher noch nicht konfigurierbar). Alle Einstellung sowie das Layout des Fensters werden nun automatisch gespeichert und bleiben über einen Neustart des Programms erhalten.

Auch grafisch wurde einiges verbessert. Die Buttons wurden neu angeordnet und mit Icons versehen. Das Programm wird regelmäßig verbessert und mit neuen Funktionen versehen.

BILD-FEHLT

Erstellen der G-Code-Programme

Zum Erstellen der G-Code-Programme benutze ich das Programm Estlcam von Christian Knüll, das ohne Einschränkungen kostenlos ausprobiert und zu einem fairen Preis gekauft werden kann. Das Programm ist selbst nicht zum Entwerfen der Bauteile geeignet, sondern dazu, aus fertigen Zeichungen G-Code-Programme zu generieren. Die Zeichnungen sollten dafür am besten im DXF-Format vorliegen, welches von vielen Programmen erzeugt werden kann. Ich verwende dafür hauptsächlich das Programm DesignSpark Mechanical, dass auch zum Planen der Fräse verwendet wurde, allerdings können auch die meisten gängigen Layoutprogramme wie Eagle oder Target 3001! DXF-Dateien erzeugen. Das ist praktisch, wenn man z. B. ein Gehäuse für eine Elektronik bearbeiten will, deren Abmaße man ohnehin im Layoutprogramm vorliegen hat. Das Programm Estlcam bietet eine Menge an Funktionen beim Erzeugen des G-Codes, wie z. B. eine automatische Fräsradiuskorrektur. Auch Vorschub, Schnitttiefe und Zustellung können eingestellt werden. Hinzu kommen einige Funktionen zum Gravieren von Texten oder das Erzeugen von Anbindungsstegen, die Innenteile eines Werkstückes während der Bearbeitung festhalten. Auch kann man dem Programm sagen, welche G-Codes es verwenden darf, um zu garantieren, dass der erzeugte Code auch von der Fräsensteuerung verarbeitet werden kann. Die GRBL-Steuerung ist dabei sogar schon vorhanden und kann einfach aus einer Liste ausgewählt werden.

Downloads

DNW_CNC_Control_1_24.zip PC-Steuerprogramm Version 1.24 (8,5 MB)
DNW_CNC_Control_1_24_Source.zip, Qt-Projekt (41 kB)
DNW_GRBL.zip modifiziertes GRBL 0.9g für AT90USB1286, AVR-Studio-6-Projekt (133 kB)

PayPal Spende