Grbl Frontend SerialComCNC

Hi!

Ich weiß immer nicht so genau wo das Thema CNC Fräsen am besten einzuordnen ist, ich schreib deswegen hier mal unter "Mechanik" (btw: wäre das vielleicht nicht eine eigene Unterabteilung wert?)

Ich wollte eigentlich nur einen kleinen Tipp geben: Ich habe an die Motorsteuerung (Parallelport Step/Dir-Interface) meiner China CNC Portalfräse mal auf die Schnelle einen Arduino mit Grbl als G-Code Interpreter gehängt. Erstmal gefiel mir schon sehr gut, wie simpel und geradeaus das ging. Zufällig habe ich zu Grbl ein tolles Frontend bei mikrocontroller.net entdeckt: http://www.mikrocontroller.net/topic/345380 Der Autor der Software stellt dort immer die aktuelle Version zur Verfügung und ist augenscheinlich auch sehr offen für Verbesserungsvorschläge und Kritik. Vielleicht ist es für den einen oder anderen Grbl-Nutzer hier interessant.

Anhang 29764

Gruß
Malte

Hmm, mal ausprobieren, wie gut das läuft. Ich benutz derzeit nämlich den Universal-G-Code-Sender und der hat irgendwie ein paar leichte Macken. Ich kann da beispielsweise nicht zweimal hintereinander in derselben Session von Datei fräsen, da er beim zweiten Mal irgendwelchen Mist fabriziert. Hat mich schon das eine oder andere Werkstück gekostet und immer wieder Progrmm schließen und wieder öffnen ist auf Dauer auch nervig.

Bin auch noch am probieren. Aber wie gesagt, es gibt offenbar einen kurzen Draht zum Autor. Wenn Dir Probleme auffallen, schreib doch ruhig bei mc.net rein.

Ich nutze übrigens auch ein weiteres Tool vom selben Programmierer:
https://www.roboternetz.de/community...ComInstruments

high,

ich hab mir vor 2 Jahren eine kleine Fräse gebaut, die ich "headless" , d.h. ohne PC direkt, mit SD-Karte betreiben wollte.
Auf der SD ist eine am PC mit EAGLE 6.x (mittlerweile 7.2) / ULP erzeugte G-Code - Datei. Die G-Code Daten werden vom "G-Code-Sender"-Board (auf einem Arduino UNO) über die Rx/Tx -Leitung (serielle Schnittstelle) an das "G-Code-Empfänger-Board" , ebenfalls ein Arduino UNO, geschickt. Auf dme Empfängerboard befindet sich die eigentliche Ansteuerungssoftware (grnl 0.6...), die die drei Steppermotoren/H-Bridges ansteuert.

Ich hab damit damals einige Platinen gefräst ( EAGLE /und eine ULP, die den Gcode aus den EAGLE Dateien erzeugt), war aber nicht zufrieden.
Mitllerweile hab ich die Fräse mechanisch verbessert, die Ansteuerungssoftware auf grbl V09.j upgedatet.

Ausserdem hab ich den "G-Code-Sender" erweitert:

Er hat jetzt zwei Funktionen:
- Mode 0: abarbeiten SD-Karte
- Mode 1: Jogging:

Der ursprüglichen Mode 0 wurde erweitert, die Anzeige der Nachrichten von grbl ("messages") erfolgt jetzt auf einem Grafik-Farb-Display,
es können bis zu 15 angezeigt werden, danach scrollt der BS und die älteste Nachricht geht verloren. Wenig informative Nachrichten ("ok") werden unterdrückt (werd ich aber mal mitzählen), der Text "error: " ebenso( diese Nachricht wird rot dargestellt).

Im Mode 1 kann ich G-Code über zwei 4x4 Keyboards eingeben oder Einstellungen ("grbl-settings") anzeigen (FEED-Rate, steps_per_mm, max_rate,...) ändern.
Es wird bei der G-Code Eingabe auf dem Keypads einiges formal geprüft, den Rest übernimmt (hoffentlich) grbl.

Das Programm ist noch in Arbeit, ich kämpfe mit dem Speicher (von den 32kB benutze ich fast 30kB), hab aber Dank Auslagerung der ca 90 Fehlermeldungen
(z.B. Zahl sollte maximal einen Dezimalpunkt haben) in ein externes EEProm und Auslagerung der messages von grbl in ein externes RAM (SPI-RAM)immer noch Platz gefunden.

Die HW des G-Code-Senders hab ich in 2 Gehäusen untergebracht:

Die Anzeige (SPI-TFT ILI9341 240x300 2.4") incl. SD-Card, Arduino Nano und SPI-RAM in einem kleinen Kästchen (ca 8x6x5cm) an einem Schwanenhals, den Rest (EEPROM, 2 x 4x4 Keyboard) über I2C Bus in der Nähe des grbl-Board/H-Bridges. Ich komm mit einem 8/9 poligen Kabel im Schwanenhals aus:
Spannungsversorgung : 0V, 5,6V, (3,3V kann ich auch aus den 5,6V erzeugen),
mProzessor-Reset,
I2C: SDA,SCL
Serielle: Rx,Tx.
Interrupt ( von D13 nach D2) , noch nicht intergriert


Den Nano betreibe ich mit 3.6V, da schaffe ich noch locker 16MHz, kann mir aber die Levelshifter sparen. Der Umbau ist bei der Nano-VClone-Version mit CH340 ist recht einfach, blöd ist nur, dass es keine Pin-kompatiblen 3.6V Regler gibt, sodass ich einen AM1117 adj mit zwei Widerständen nehmen musste.

Grosse Probleme hatte ich mit der Darstellung der messages "error" von grbl, die über Rx/Tx geliefert werden:
Es wurden - da der Arduino-Nano im Vergleich zum PC/Pentium I5 wohl etwas langsam ist - einige verschluckt, auch konnten die "Settings:" (ca. 25 Zeilen auf einmal) nur zu einem kleinen Teil ausgegeben werden.
Ich hab lange "geübt", geholfen hat nur eine Erhöhung des Serial-Rx-Buffers (Arduino-IDE: /.hardware/arduino/avr/cores/arduino/HardwareSerial.h)
von 64 auf 224 byte: #define SERIAL_RX_BUFFER_SIZE 224
und eine Splittung der Message in grbl v0.9j in 2 Teile. Auch habe ich dort die reinen "festen" Texte dort eliminiert, die kann ich zur Not aus dem extrenen EEPRom holen. Aber jetzt klappt die Anzeige gut, auch bei 115200 Baud, gerade wenn ich die Einstellungen (Vorschub, inch/mm etc.) über das Keypad ändere, hab ich dann eine Kontrolle, was wirklich im grbl-EEProm abgelegt ist.


https://www.youtube.com/watch?v=ODvCfD5I694


https://www.youtube.com/watch?v=w21rDR9v4T8

https://www.youtube.com/watch?v=w-IEwHAgBiM

https://www.youtube.com/watch?v=5eaE3VN7RyE

https://www.youtube.com/watch?v=K_Lu_iBz-cE

Gruss mausi_mick

Zitat:

---

Zitat von mausi_mick

high,
......
Das Programm ist noch in Arbeit, ich kämpfe mit dem Speicher (von den 32kB benutze ich fast 30kB), hab aber Dank Auslagerung der ca 90 Fehlermeldungen
(z.B. Zahl sollte maximal einen Dezimalpunkt haben) in ein externes EEProm und Auslagerung der messages von grbl in ein externes RAM (SPI-RAM)immer noch Platz gefunden.

....
Gruss mausi_mick

---

Wie sieht es mit dem Arduino mega aus ?
Der hat doch 256k Eprom und 4 K SRAM ?

Die China Modelle kosten auch nicht mehr viel ...

73

Hat eigentlich schon mal Jemand auf Basis eines Arduino (& Speicher) einen "Hardwaresender" gebaut ?
Also praktisch einen (oder mehrere) in sich abgeschlossenen G-Code auf `nen Nano mit SD-Karte draufgepacken, der dann per Knopfdruck eine Fräse oder Lasercutter ansteuert.

Sehr sinnvoll für Veranstaltungen, auf denen ständig das Gleiche gefertigt wird und dafür ein Besucher selber nur auf einen Button drücken und es dann schon gleich losgehen könnte.

Für unseren Eggbot und Lasergravierer wird z.B. immer ein Laptop bereitgestellt, mit dem natürlich dafür mit Kanonen auf Spatzen geschossen wird. :-)

Andree,

sowas ist das,
ich speichere am PC die Daten (z.B G-Code aus Eagle 7.2 ) auf eine SD. Die SD hänge ich dann einen Arduino (UNO bzw. der neue mit NANo), der sendet dann die Daten über rx-tx an die Fräse , die mit einem UNO (mit GRBL v9.i) läuft.

- sorry, hatte mir die Info in der Nachricht echt nur überfliegend durchgelesen - :-)

Sehr cool und sinnvoll!

mausi_mick: Hast Du Dein Projekt irgendwo dokumentiert/veröffentlicht ?

Ich habe als "Front End" eine Webserver-Lösung im Netz gefunden:

www.xyzbots.com/grblweb.html

Hier wird der Arduino UNO mit GRBL Firmware direkt an einen freien USB Port eines Raspberry Pis angeschlossen. Der Pi wird mit einem Image, welches man von xyzbots.com runterladen kann, bespielt.
Sobald der Pi dann ans Netzwerk angeschlossen wird, kann man das Web Frontend über den Browser eines Smartphones oder Desktop PCs aufrufen und direkt mit der Steuerung der Fräse loslegen.

Hier habe ich versucht meine Erfahrungen mit der Fräse ein wenig offen zu legen:

www.michaelwuehr.de/de/hardware/cnc

Grüße,
Michael

Hi Michael,
das hatte ich auch schon kürzlich installiert - war aber dann doch nicht so ganz begeistert davon. Ist ja schon sehr minimalistisch/in der Funktion eingeschränkt.

....das autarke Projekt von "mausi_mick" interessiert mich hingegen viel mehr!

@Andree-hb

genau deswegen habe ich das ganze mit ein paar Features ergänzt:

- Auto Probing
- Auto Leveling
- Presets für verschiedene Werkstückkoordinaten
- Fräsmotor Ein/Aus
- Usw

evtl stelle ich mal das ganze als GIT Source online, falls Interesse besteht?

aber mausi_mick, rück mal ein paar Infos raus :-)))

...da ist ganz klares Interesse da! :-)

Na dann werde ich mal ran machen :-)

Bin noch im Urlaub,
werde mich Ende Oktober melden und mich zum Source-Code und Änderungen am grbl-Paket äussern.

Hi,

hab die HW nochmals etwas geändert/reduziert, anstelle der zwei 4x4 Keypads (32 Tasten) hab ich jetzt ein 8x8 Keypad (mit echten 14mmx14mm Tasten) aufgebaut mit einem MCP23017 am I2C-Bus. Nutze aber momentan "nur" 36 Tasten (6x6), mit denen ich die 10 Ziffern, die Buchstaben M,F,G, X,Y,Z, H,I,G,K,L,,R,S,T , P und Q und einige Sonderzeichen / Befehle .-=$!? sowie Del, Blank und CR/LF eingeben kann.
Die beiden übrigen Reihen /Spalten der Matrix werd ich wohl für Sonderzwecke (Pfeil rechts/links , oben/unten etc.) verwenden.
Probleme machen mir noch einige / wenige Fehlermeldungen von grbl (siehe Display). Ich weiss nicht, ob das jetzt nur an der Simulation liegt (an dem Test-grbl UNO hab ich keine Motoren angeschlossen, sodass hier der Datentransfer über TX/RX sehr flott
läuft, vielleicht etwas zu flott ??)


https://www.youtube.com/watch?v=S7sPyyGJ8GI[/VIDEO]

Das ist ja mal ein richtig cooles Projekt!
Respekt - finde ich sehr gut!

Gibt's da auch Sourcecode dazu? :-)

- - - Aktualisiert - - -

Ich habe übrigens eine erweiterte Version von GRBLweb namens WoidMill - Controller auf Git und auf meiner Internetseite online gestellt.

https://github.com/michaelwuehr/woidmill_controller

WoidMill - Controller
http://www.michaelwuehr.de/de/softwa...mill-interface/

Im Prinzip : ja

da das Projekt aber noch in Arbeit ist , möchte ich das noch nicht auf github oder andere Plattformen stellen.
Ich muss doch - neben dem sketch - einige libs (EEPROM,SPIRAM,UTFT_ILI9341,..) bereitstellen , die ich geändert habe (z.T. wegen Fehlern, z.T. um sie kompakter zu machen).
auch hab ich grbl geändert (im Wesentlichen report.h, report.c), sodass man es mit arduino (Spezialversion im Netz) kompilieren muss.
Eventuell muss ich die Sender-Funktion und die Jog-Funktion (mit ellenlanger Code-Prüfung) auf zwei CPUs trennen, oder die Gcode-Prüfungen drastisch reduzieren.

Hinzukommt, das ich den Nano mit 3,6 V betreibe, um die diversen Pegelwandler am I2C bzw. SPI-Bus zu sparen (es gibt eine Umbauanleitung im Netz auf 3.3V, aber das ist für 16MHz Takt leicht ausserhalb der Spezifikation.
Der Umbau auf 3.6V ist nicht so doll, da es wohl kein SOT223 IC mit dieser fixen Spannung und gleicher Pin-Belegung gibt. Ich hab daher einen ..1117 mit zwei Widerständen einbauen müssen ...

Gruss mausi_mick

Muss mich doch mal wieder melden.
Es geht langsam weiter, ich bin dabei das Programm von Arduino (Nano) auf einen anderen (32-bit)Prozessor zu portieren,
da der Space doch etwas sehr knapp wurde, trotz Verwendung von SPI-Ram und externem EEProm.
Auch hatte ich Probleme mit der Schnittstelle (Rx/Tx), da verschwanden im Testbetrieb doch einige Messages von grbl.
(Es kommen z.B. bei Eingabe von $$ (Anzeige grbl-Parameter) doch einige Hundert Byte "aufeinmal" rüber , die abgefangen und z.T. auch angezeigt werden müssen. Ich weiss nicht, ob das auch so kritisch bei laufender Fräse ist, da sind die Quittierungen (ok) vermutlich etwa träger.
Ich habe zuerst mit einem STM32F103c8t6 gearbeitet (mit Arduino IDE), es war aber doch etwas schwierig, die Software für die verbleibende Hardware (ILI9341 Display incl. SD-Karte und 8x8 Keypad an MCP23017) anzupassen.
Deshalb habe ich mich jetzt für einen Teensy3.1/3.2 entschieden, der leider etwas teurer (ca 21€) ist.
Leider kann ich die rasant schnelle ILI9341-Software von PRJ nicht verwenden, da das/der? font von Adafruit nicht richtig passt: entweder ist die Schrift zu klein oder bei Skalierung 2 bereits sehr gross, sodass ich kaum was anzeigen kann. Es gibt da zwar noch andere fonts, die scheinen aber noch nicht integriert/verwendbar zu sein. Daher verwende ich die original UTFT-Lib, die aber leider HW-SPI nicht unterstüzt (Ich benötige jetzt einige Leitungen mehr, da vorher SD-Karte und LCD die SPI Anschlüsse MOSI / SCK gemeinsam hatten...).
Die Geschwindigkeit ist aber (bei 96MHz ! ) trotzdem beachtlich.
Der Teensy3 hat auch den Vorteil, dass ich nicht nur die TX und RX-Buffer (an grbl) anpassen kann, sondern ich kann die serielle Schnittstelle auch "priorisieren" (zwischen 0 und 255). Hab den Wert jetzt auf 8 gesetzt, das geht dann echt flott.

Das Speicherplatz-Problem ist auch vorbei, Tabellen mit z.B. Fehlermeldungen hab ich jetzt locker fest (ja was denn nun) im Programm unterbringen können.
Auch ist die Darstellung von bis zu ca 30 (srollenden) Nachrichten auf dem Display kein Problem, das jetzt übrigens auf 2.8" angewachsen ist. Die Touch-Funktion verwende ich aber nicht.

Werd aber noch einige Zeit zum Testen benötigen.

Gruss mausi_mick

...ich bin weiter sehr gespannt! :-)

Jetzt geht es wohl langsam etwas weiter, ich hab das etwas anders verteilt:
-einen Arduino Nano als Sender (SD-Karte bzw. Tastatatureingabe) mit Display, ext. EEPROM, SPI-RAM , Tastatur
-einen Arduino Nano als Empfänger von Fehlernachrichten etc. mit separatem Display
-den UNO mit der grb v9.j zur Ansteuerung der Motoren.

So hab ich noch Erweiterungsmöglichkeiten und zusätzliche Anzeigen

Als IDE verwende ich die 1.6.9, habe aber die seriellen Buffer (in hardware ...) auf 128 byte erweitert. Auch hab ich grbl (im Wesentlichen in report.h/c) leicht modifiziert (keine Fehlertexte, nur noch Nummern, die man dann auf dem Nano auswerten kann.
Das Problem mit den dubiosen Fehlermeldungen scheint behoben, verursacht wohl durch einen Bufferüberlauf (max 127 byte kann grbl buffern) .
Ich merke mir dazu, wieviel /eher wenig Buffer noch frei ist und erhöhe ihn, wenn ich eine Rückmeldung von grbl bekomme.

Ich habe die Aufteilung zwischen den beiden Arduino Nanos( dem G-Code-Sender und dem Empfänger der Nachrichten von grbl) noch etwas geändert:

Der Sender sendet jetzt nur die GCodes von der SD-Karte, aber nur soviel, dass der Buffer (128 Byte) nicht überläuft.
Bekommt er eine Nachricht/Quittierung von grbl ("ok"), prüft er, ob er die nächste G-Code-Zeile schon senden kann.

Der zweite Arduino NANO gibt eventuelle Fehlernachrichten von grbl auf dem Display aus, auf ihm kann man sich aber auch die grbl-Parameter ansehen bzw. modifizieren . Ausserdem kann man von ihm aus per Keyboard GCode Zeilen eingeben und an grbl senden.
Da das doch relativ mühsam ist, besteht auch die Möglichkeit, über einen Dreh-Encoder und wenigen Tastatur-Eingaben die wichtigsten GCodes (G00/G01) relativ einfach einzugeben.
Die x,-y, z- Positionen sowie die Vorschubsgeschwindigkeit (Feed) werden über den Drehencoder eingegeben, dessen Schrittweite auf 1mm oder 0,1mm gestellt werden kann .
Der Drehencoder behält auch die vorige Postion bei, wenn man z.B. von x nach y wechselt und wieder zurück. Er arbeitet mit Interrupts ("Change-Pin an A2 und A3") .
Das Keyboard (momentan 7x7) und das externe EEProm hängen anI2C Bus, das NV- RAM (23LCV..) am SPI-Bus.
Als Display verwende ich ein ILI9341 (2,8") aber nicht als HW-SPI (wird von UTFT nicht unterstützt, die Adafruit Lib ist zwar schnell, aber mir gefallen die fonts nicht). Werde aber eventuell das ILI9341 von Adafruit mal an SPI testen.

Gruss mausi-mick

Bei youtube hab ich mal 3 Videos geladen,
auf jog grbl 08 die Settings von $0 bis $27 (Anzeige wie bisher mit $$)
jog grbl 09 die Settings von $100 bis $132 (Anzeige mit $Y)
in jog grbl 10 ist die G-Code Generierung im "Simple-Mode" dargestellt mit Werteingabe x,y,z, feed über Drehencoder

Jog-10: https://www.youtube.com/watch?v=Drh636d-dyI


Jog-09: https://www.youtube.com/watch?v=9J3BEn3ThrU

Jog-08: https://www.youtube.com/watch?v=3qhKISY_-84