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.
:
Verschoben durch Moderator
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
Wenn es ein Problem mit der englischen Punkt-Komma Einstellung ist, ist vielleicht auch noch das Tastatur Y Z Layout daran beteilingt?
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
Zugegeben, bei CAM-Tools kenne ich nicht genügend, um das zu wissen. Ich hatte nur schon oft das Problem mit anderen Tools, die aus Amiland stammen.
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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
Georg schrieb: > Vielleicht solltest du makerCAM wegschmeissen? Warum sollte man den Falschen bestrafen, wenn grbl Schuld ist ?
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
ok vielen Dank. ich versuche mein Glück einfach mal mit anderen CAM Programmen, beziehungsweise versuche mit inkscape direkt einen G-Code zu erzeugen.
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
Hier gibt es eine Liste mit alternativen GCode Sendern und anderen Tools: http://www.shapeoko.com/wiki/index.php/Communication_/_Control
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
MaWin schrieb: > Grbl ist open source, den bug könnte ja jemand fixen, nur mit Leuten wie > dir wird das natürlich nichts. Im Gegensatz zu dir habe ich dafür ein Programm geschrieben, das mit o.g Code einwandfrei funktioniert. Soviel bla bla von solchen wie du wird's nicht. Auch hier gilt: wenn man nicht über Thema weiß, einfach Klappe zu halten! sven schrieb: > Man darf den GRBL-Buffer nicht überlaufen lassen - da muss der > GCode-Sender aufpassen So ises! Der Buffer ist nur 128 Byte lang. Eine Nachkommastelle zuviel könnte ihn zum Überlauf bringen. Nemesis schrieb: > Wie muss man sich den Sender real vorstellen? http://zapmaker.org/2014/05/grbl-controller-3-6-1-released-for-windows/ http://www.jtronics.de/software/jcnc-cnc-steuerung.html Beitrag "Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" ... Das von Albert geschriebene Programm funktioniert mit o.g. Code einwandfrei und mit Abstand das beste Programm, was ich bis jetzt getestet habe.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.