Hallo ich habe eine kleine CNC fräse gebaut, welche ich über einen
Arduino in Kombination mit der Grbl Software ansteuern. Als G-code
Sender benutze ich den universal G code Sender.
Die Ansteuerung der verschiedenen Positionen klappt ziemlich gut.
Allerdings habe ich das Problem, dass nicht alle G-code files bei mir
funktionieren. Einen handschriftlich generierten Code wie :
(mit universal G-code Sender ausgeführter Code)
Grbl 0.9j ['$' for help]
>>> G17G20G90G94G54>>> G0Z0.25>>> X-0.5Y0.>>> Z0.1>>> G01Z0.F5.>>> G02X0.Y0.5I0.5J0.F2.5
ok
funktioniert.
G codes welche ich mit makerCAM generiert habe machen nur irgend ein
Unfug mit der Z Achse, ansonsten nicht wirklich ihren job:
>>> G21G90G40>>> (follow path 1)>>> G0Z1>>> G17>>> M3>>> G0X17,7396Y16,1269
ok
ok
ok
ok
>>> G1Z-1.5F800>>> G1X19,2157Y16,1269F1500>>> G1X20,6675Y16,1269>>> G1X22,0964Y16,1269>>> G1X23,5051Y16,1269
ok
ok
error: Expected command letter
>>> G1X24,8883Y16,1269
ok
>>> G1X26,2487Y16,1269
error: Expected command letter <<<<<<<<<???? Warum ist der Befehl
falsch?
Hat jemand eine Erklärung oder einen Tipp?
Schoneinmahl vielen Dank im voraus für eure Unterstützung.
Im normalen Editor stehen in beiden Fällen punkte.
hier noch mal ein teil des zweiten Codes.( im Editor)
G21 G90 G40
(follow path 1)
G0 Z1
G17
M3
G0 X17.73959390862944 Y16.126903553299492
G1 Z-1.5 F800
G1 X19.215736040609137 Y16.126903553299492 F1500
G1 X20.66751269035533 Y16.126903553299492
G1 X22.096446700507613 Y16.126903553299492
G1 X23.50507614213198 Y16.126903553299492
G1 X24.888324873096444 Y16.126903553299492
G1 X26.248730964467004 Y16.126903553299492
G1 X27.586294416243653 Y16.126903553299492
G1 X28.903553299492387 Y16.126903553299492
Manchmal machen englische/amerikanische Programme auch Probleme mit der
Codierung (Ansi / Utf8). Die Codierung der Datei (so kenne ich das)
lässt sich mit dem Notepad++ anzeigen. Andere Tools/Wege kenne ich
leider nicht.
Felix A. schrieb:> Manchmal machen englische/amerikanische Programme auch Probleme mit der> Codierung (Ansi / Utf8).
Eigentlich sollte ein Bohr- oder Fräsprogramm nur pures 7-bit ASCII
enthalten. Und das ist eine der wenigen Sachen in der IT, die nicht
umstritten ist.
Georg
CNC-Fräser schrieb:> Im normalen Editor stehen in beiden Fällen punkte.
Dann ist dein normaler Editor wohl defekt.
Vielleicht muss man auch Koordinaten nicht mit 17 Stellen Ungenauigkeit
vorgeben.
danke für die Hilfe.
>Vielleicht muss man auch Koordinaten nicht mit 17 Stellen Ungenauigkeit
vorgeben.
Wie kann ich den G-code erzeugen ohne, dass ich alle Stellen per Hand
änder muss?
CNC-Fräser schrieb:> Es liegt wirklich an der länge der Koordinaten.
Dann ist grbl fehlerhaft,
denn der G-Code Standard sagt
A number consists of (1) an optional plus or minus sign, followed by (2)
zero to
many digits, followed, possibly, by (3) one decimal point, followed by
(4) zero to
many digits - provided that there is at least one digit somewhere in the
number
Numbers may have any number of digits, subject to the limitation on line
length (oftmals 80 oder 256).
(Zeilennummer und Labels sind auf 5 Stellen begrenzt)
CNC-Fräser schrieb:> Wie kann ich den G-code erzeugen ohne, dass ich alle Stellen per Hand> änder muss?
Normalerweise kann man die Anzahl der Nachkommastellen eingeben. Und
erzähl nicht dass deine Fräse auf 1 millionstel Atomdurchmesser genau
fräst.
Das Programm ist sowieso absurd: das sind lauter kleine Teilstücke einer
Geraden, 2 Zeilen reichen dafür.
Vielleicht solltest du makerCAM wegschmeissen?
Georg
In verschiedenen Quellen wird erwähnt, dass man für GRBL die Anzahl der
Nachkommastellen auf 4 begrenzen sollte - ich finde bloss keine ;-)...
Entsprechende Preprozessoren (z.B. bei Estlcam) machen das auch.
Gruß
Sven
Michael B. schrieb:> CNC-Fräser schrieb:>> Es liegt wirklich an der länge der Koordinaten.>> Dann ist grbl fehlerhaft,> denn der G-Code Standard sagt...
Der Fehler liegt an G-Code Sender!
Tany schrieb:> Der Fehler liegt an G-Code Sender!
Wenn der Standard sagt, dass dort beliebig viele Ziffern stehen dürfen,
notfalls bis zum Zeilenende, dann ist der Reader fehlerhaft, wenn er
nach 17 Ziffern abbricht.
Grbl ist open source, den bug könnte ja jemand fixen, nur mit Leuten wie
dir wird das natürlich nichts.
Man darf den GRBL-Buffer nicht überlaufen lassen - da muss der
GCode-Sender aufpassen "This briefly stores up to 127 characters of data
received from the host PC until Grbl has time to fetch and parse the
line of G-code. "
Also nach 4 solcher Zeilen: "G1 X28.903553299492387 Y16.126903553299492"
(da die 5. nicht mehr reinpasst), wenn die Maschine nicht schnell genug
ist die Koordinaten abzufahren.
Hier steht's:
https://github.com/grbl/grbl/wiki//Interfacing-with-Grbl#writing-an-interface-for-grbl
CNC-Fräser schrieb:> mit universal G-code Sender ausgeführter Code
Wie muss man sich den Sender real vorstellen?
Ist das ein Programm, Gerät oder sonstige App?
Link?
sven schrieb:> wenn die Maschine nicht schnell genug> ist die Koordinaten abzufahren.
So was dürfte es garnicht geben. Die ganz uralten Maschinen lasen den
Lochstreifen Satz für Satz ein, der blieb eben stehen, bis der Satz
verarbeitet war. Und seit einigen Jahrzehnten wird ohnehin das ganze
CNC-Programm in den Speicher eingelesen.
Georg
Michael B. schrieb:> Dann ist grbl fehlerhaft,> denn der G-Code Standard sagt>> A number consists of (1) an optional plus or minus sign, followed by (2)> zero to> many digits, followed, possibly, by (3) one decimal point, followed by> (4) zero to> many digits - provided that there is at least one digit somewhere in the> number>> Numbers may have any number of digits, subject to the limitation on line> length (oftmals 80 oder 256).
Arduino UNO Steuerungen wie GRBL oder Estlcam müssen mit 2048 Byte RAM
auskommen - da tut jede unnötige Nachkommastelle die als Text
zwischengespeichert werden muss weh.
G-Code ist in der Realität eher ein Pseudostandard - es schaut zwar
alles irgendwie ähnlich aus - nur im Endeffekt halten sich nicht mal
Industriesteuerungen an die ursprüngliche DIN Spezifikation. Deswegen
schleppt jedes CAM Programm auch eine ellenlange Liste mit
Postprozessoren mit, da Code A auf Steuerung B oft einfach nicht
funktioniert.
Fazit: beim schreiben von G-Code bzw. verwenden von CAM Programmen muss
man immer die Eigenheiten der Steuerung berücksichtigen.
Christian
Christian K. schrieb:> Arduino UNO Steuerungen wie GRBL oder Estlcam müssen mit 2048 Byte RAM> auskommen - da tut jede unnötige Nachkommastelle die als Text> zwischengespeichert werden muss weh.
Sie muss ja nicht.
Niemand hindert den Programmierer daran, beim Empfang der Ziffern z.B.
nach der 5. Stelle einfach keine weiteren Ziffern mehr zu speichern
sondern nur noch einen Exponenten hochzuzählen.
Dafür muss man natürlich programmieren können und richtige
Entscheidungen bei der Implementation des Standards fällen.
Faulheit und "wir bohren dort weil dort das Brett am dünnsten ist"
gelten nicht als Ausrede, obwohl ich hier in dem Thread viele Leute
sehe, die mehr Mühe in die Ausreden als in die Lösung stecken.
