Hi David, Thanks a lot for your reply. I'm using Arduino UNO R3 + CNC shield V3.0 The version of GRBL is v0.9 (but not sure and I don't know how to check it sorry!!!) And as GUI I'm using Universal GCode Sender V1.0.9 Thanks again!!!!
Dear Peter. Really apreciate your reply. I will check all the things you mention and I will give feed back. Many thanks Juanjo
When you reset your Arduino it should tell you the grbl version. Current version is 1.1, so perhaps you should upgrade. gnea/grbl
However, some of the pins have changed on newer versions of GRBL compared to when the CNC shield V3.0 was designed. gnea/grbl
So glad to receive so many help from all of you !!!!!! I will check everything and also update GRBL version. I will tell you about it. Juanjo
Hello all, How are all the cool kids generating GRBL g-code to mill PCB's now a days? I'm using an Arduino Uno with GRBL 1.1 as a controller. I've used the Openbuilds Control software successfully to mill out some simple projects. I've also used ChiliPeppr successfully as well. Now I am hoping to use my mill for something real. I've seen some Eagle plugins that work as ULP's but they all appear to be several years old and made before Eagle was acquired by Autodesk. Can GRBL g-code still be extracted from Eagle or is there an easier way? Jet
Awesome! Doesn't work for me. I can't open copper_bottom.gbr - An unknown error occured:TypeError: Cannot read property 'primitives' of undefined. I can open copper_top.gbr, the silk screen and solder mask files. Just not copper_bottom.gbr (attached). Did I make my board wrong? Set something wrong in the CAM Processor? Using Autodesk Eagle Version 9.3.2 on Linux.
Dear Openbuilds Community! I've been doing progress on my project, and I would like to share my thoughts with you, since something is not working, and I've tried everything it came into my mind, so maybe you guys can give me another point of view: Objective: "Self-working" machine - When I press a Start button attached to a "Start" pin, on the ESP32 CNC Shield (The Updated ESP32-Based Grbl CNC Control Board Is Now for Sale!) The machine should run the .gcode stored on the SD and go home when it finishes. What I've done? - Uploaded the Gcode on the SD card, and actually running it using $FM -> $F -> $F=/mygcode.ncc. I found out that this codes are defined inside a switch (System.cpp), which reads for $ commands, and then depending on the next character it jumps onto one action, or another. So what I programmed (in my head was clear, but it seems it was not...) was: Added a global variable (volatile bool GlobalStart, included it into the needed thread, and used it into the following interruption: CONTROL_CYCLE_START_PIN, which when detects a Change on the START pin, goes to the following function: isr_control_inputs. Once there, I added a subroutine to check if I went inside isr_control_inputs from my variable, and if so, I set up my global variable to True. Finally, I add a watch on the main program, that activates when the variable = 1, and then instead of sending $FM, $F... I discovered what each one of this means, so I directly send the "inside" part of the code: ex: if (GlobalStart=1) { sdmount (); // equals to $FM delay1000 // No idea how to code "wait until you receive ok" - Then the $F=/mygcode.ncc , too long to paste it here. I'm doing something wrong, maybe I didn't undestand how do interruptions go, maybe I didn't declare the variable in a correct way, but it does not do the job... Any ideas? By the way, I've noticed my ESP32 pass away after printing 8 times in a row from SD card, no matter what I do, anyone else experienced that? Thanks!
I prefer linear code if I do not need interrupts. Would it be easier to just "busy-wait" in Setup, polling until you see the cycle-start button, then mount the SDCard, open the file, etc... Then only the main loop will run. You could perhaps even auto-reboot your system when the job completes..
Hai I am have a problem using the absolute and relative mode. I am Using GRBL 1.1f and the universal code version 2 . The code is exactly the same but the result is different . In absolute mode I draw a circle but in relative mode the last part(1/4) of the circle is wrong. I like to use the relative mode to add a standard code G90, xxxxxxxxxxxxxxxxxxG91yyyyyyyyyy,G90xxxxxxxxxxxxxx,G91yyyyyyyyyyyy etc. I do not understand why the circle in relative mode is not complete? G17 G21 G90 G94 G54 G10 L2 P1 X-120.4 Y-38.5 Z-49 G00 X-0.0 Y0.0 Z+20 G90 G00 X-0.0 Y-0.0 G90 G00 X-0.0 Y-0.0 Z+10 G90 G00 Z-0.0 G90 G1 X+4 Y-0.0 Z-0 F20 G90 G1 Z-0.3 F20 G90 G3 X-4 Y-0.0 I-4 J0.000 G90 G3 X+4 Y-0.0 I+4 J0.000 G90 G1 Z-0.6 F20 G90 G00 X-15 Y-15 Z+10 G91 G00 X-0.0 Y-0.0 G91 G00 X-0.0 Y-0.0 Z+10 G91 G00 Z-0.0 G91 G1 X+4 Y-0.0 Z-0 F20 G91 G1 Z-0.3 F20 G91 G3 X-4 Y-0.0 I-4 J0.000 G91 G3 X+4 Y-0.0 I+4 J0.000 G91 G1 Z-0.6 F20 G91 G00 X-0 Y-0 Z+10 G90 etc
I think you need to make use of the fact that the G90/91 codes are modal, ie you only need to set them once. (so are G0/1/2/3 and F, once you set a feedrate you don't need to repeat it) Not many GUI's or Gcode previewers will actually show relative code properly....bCNC does not, nor does ncviewer.com refer to G Codes G17 G21 G90 G94 G54 ; absolute in effect ;G10 L2 P1 X-120.4 Y-38.5 Z-49 ; NEVER do this in code! use the buttons on the GUI so set up your work co-ordinates G00 X0.0 Y0.0 Z+20 ; draw a circle using absolute co-ordinates G00 X0.0 Y0.0 G00 Z10 G00 Z0.0 G1 X4 Y0.0 Z0 F20 ; this will scrape the surface G1 Z-0.3 ; cut 0.3 deep G3 X-4 Y0.0 I-4 J0.000 ; top half of circle G3 X+4 Y-0.0 I+4 J0.000 ; bottom half of circle G1 Z-0.6 F20 ; cut down to -0.6 G0 Z10 ; raise Z out of cut! ; without this the next line would have cut a sloping trench to -15,-15 at rapid speed, is that what you wanted? ; go to -15,-15 G00 X-15 Y-15 Z+10 G91 ; switch to relative G00 X-0.0 Y-0.0 ; go nowhere G00 X-0.0 Y-0.0 Z+10 ; go 10 more up , now at +20 absolute G00 Z-0.0 ; go nowhere G1 X+4 Y-0.0 Z-0 F20 ; move X by 4 G1 Z-0.3 F20 ; move Z down by -0.3 G3 X-8 Y-0.0 I-4 J0.000 ; draw top half of arc, 8 units diameter G3 X+8 Y-0.0 I+4 J0.000 ; draw bottom half of arc, 8 units diameter G1 Z-0.6 F20 ; move Z 0.6 down into cut, now at 19.4 absolute G00 X-0 Y-0 Z+10 ; move Z up 10, now at 29.4 absolute G90 ; switch to absolute hope this helps
Tanks I am starting and after a lot of try's the code becomes a mess. I will study your remarks and see it makes sense But you think that the problem is the viewer! Thanks a lot for your remarks
Hello folkes Can anybody explain me in very simple way for what is function " Restore Origin" in GRBL Candle? Any example would be perfect Thanks in advance
Hello, So I really don’t know if this is the correct forum. I use grblmain with arduino nano and Cnc shield v4, thing is that my experiments are with the cheap byj48 motors and I think that the 10uS pulse is to fast. Just my thinking. Thing is that I tried changing default pulse width parameters in defaults.h to 20uS but on the oscilloscope it looks like the pulse stays 10uS. So What am I doing wrong?..
Pulse length isn't (specifically) changed at compile time, which is where defaults.h would come in. With a vanilla grbl hex installed on the Arduino, send $0=20 over serial after communication has started.
Greetings! I was wondering if someone could aid me with a GRBL Command I'd like to make for my CNC / Laser Engraver Setup? This is my CNC's Z-Axis Slide with both a Spindle and the Docking Port for a Laser Engraver mounted to it: With a project including Milling AND an Engraving Operation, there's obviously a need to change Offsets when switching from one tool to the other and while I've certainly managed to do that using two Macros in UGS-Platform I kind of feel like the way I did it might not be the most desirable one: Change from Laser to Milling: G53 G0 Z-1; G90 G0 X0 Y0; G0 X-54.6 Y-60.79 Change from Milling to Laser: G53 G0 Z-1; G90 G0 X0 Y0; G0 X54.6 Y60.79 The G53 G0 Z-1; G90 G0 X0 Y0 portion is actually another Macro I use instead of UGS-Ps Return to Zero command which is kinda terrible when the Z-Axis Home is the top of the Spoilboard and not the Workpiece. In both cases it will: Raise the Z-Axis to Z-1 Home the OLD Tool to its Work X0 Y0 Coordinates. Apply the X&Y-Axis Offsets for the NEW tool to be then positioned above the Work X0 Y0 Coordinates. What I'm missing in both Macros is for the then Offsetted X&Y-Axis to be reset to 0 to continue with the next Operation - For now, I have to do this myself which is meh as I'm running the risk of forgetting to do it. Does anyone know how to incorporate an Axis Zeroing Command into the Macro or know of an entirely different solution? Maybe, without the need to move the Machine itself move the current Work Coordinates?
I agree with Rob, use G54 work coordinates for the router and G55 for the laser. A similar macro could set the laser offset uinto G55 automatically for you after you set the G54 zeros. Then, when you generate Gcode for the router cuts you need to include a 'G54' at the beginning of the file. And for the laser code you need to include a G55 at the beginning. Note that once you start using this you should always include a G54 or G55 in all router/laser files you generate, never trust yourself to remember to set the right mode. (-:
I had to brush up my knowledge on G5x and how exactly it works and, from my understanding, I don't REALLY like the workflow it requires and what I'd be using it for. One of the other reason being the requirement for the macros to also be making the switch from Milling Mode ( $32 = 0 ) to Laser Mode ( $32 = 1 ) which is not something I'm capable of having automatically done in the Post Processor - Such a manual Input ( the Macro ) would also act as a checklist to help me mentally prepare for the Laser and its dangers - Ya kno'... Hit the Macro, confirm reLocation, put on the Glasses, snap the Laser to the Docking Plate and off we go... The "Package" is all concentrated in one location the moment I need it as opposed to some parts being tied to the use of G5x while in Fusion 360 ( maybe on another day! ), then some during the initial stage of setting up the Work Piece and later while doing the switch from Milling to Laser or vice-versa.
Sounds like you have a fairly specific setup then. I don't believe it's considered good practice, generally speaking, to use G53/G28 machine coordinate commands for general use. They're typically reserved for machine-specific movements like toolchanges and cycle-end dog-leg movements to avoid sidewalls. This is probably partially because they're non-modal, so using a G53 once doesn't affect your actual work coordinates, which are G54. But since they're offset from each other (ie. your work touchoffs are not placed at your limit switch positions), that could be a problem. Standard practice would be to use G54 for your primary tooling- the spindle, presumably. G55 would be a constant offset from this, likely programmed directly into the machine (power cycles, etc. notwithstanding). G54 is your standard workspace and is what Fusion will spit out by default (There's a reason you see a "G17 G20 G40 G49 G54 G80 G90 G94" or similar line at the top of your G-Code, setting all the modal parameters). When you switch to laser, you'd issue a G55 block by itself followed by a $32 block, which should be picked up by grbl just fine (you can mix g-code and config commands in manual serial input, at least, I'd experiment there just to double-check). Then, if you want to have time to put glasses on, you'd want to add an M1 on the next line (some controllers require a separate "optional stops" button to be pressed for the machine to pay attention to M1s, make sure grbl accepts these before putting it into production code, I don't recall having cause to use any yet). That would be the "industry standard" method, at least. You may need to write an additional post-processor to find your G54 and G55 blocks so that you can insert the other appropriate machine codes. I'd personally make a little text file editor in Python, something simple and adjustable/extendable, if it's something you expect to be doing in high volume. To actually zero your current coordinate system it should be G92 X0 Y0 Z0, iirc. That will zero G54 coords, though, remember, not machine coords. Because zero on the machine is your machine home switches (possibly adjusted to get negative workspace). You don't change that, that's so the machine knows where it is. The only way to change those is re-homing the machine, which shouldn't actually change any numbers (by more than 0.5mm or so, anyway).
'Z Axis Home' I now wonder exactly what you mean by this. Actual machine home (G53) must always be Z as high as possible for safety. All Gcode generators expect this. But I expect you mean 'Z axis work offset zero'. in which case you are doing the right thing, my macro (I use bCNC) does this Code: G53 G0 Z0 G0 X0 Y0 which safely goes to the work zero I have another which safely goes to machine zero (home) Code: G53 G0 Z0 ; note I do not have home switches so I can go to actual 0, switches may need an offset) G53 X0 Y0 Agreed, we must automate this to obviate mistakes. So, given that you are positioning the tool and then hitting the 'set zero' buttons (I am not sure of the exact names for UGS platform, I have not used it for a long time) you are in fact setting the G54 work offsets. Good. Lets remind ourselves of the offset numbers Change from Laser to Milling: G0 X-54.6 Y-60.79 Change from Milling to Laser: G0 X54.6 Y60.79 Since we don't know the absolute offsets we cannot use G10 commands, so we are stuck with G92. I don't like G92 as it has pitfall sideeffects but lets try it anyway. to quote the web page: So, set the milling tool zero then.... Milling to laser macro: Code: G21 G90 ; always specify units and mode, you might have run an inch file just before this, or left it in G91 G53 G0 Z-1 G0 X0 Y0 G92 X-54.6 Y-60.79 G0 X0 Y0 ; should position the laser over the work 0,0 Laser to milling : (just remove the G92 offsets) Code: G21 G90 G53 G0 Z-1 G92.1 ; remove offset G0 X0 Y0 ; should position router over work 0,0 I have just tried this in bCNC and it appears to do the right thing (but bear in mind I do not have my actual router here, just a bare Arduino board). Since I do have a laser module at home that I should have connected already this is a good thing to be thinking about (-: But now, let us consider changing between laser off and on mode. To change a $ setting GRBL has to rewrite EEPROM and one should never do this within a Gcode program. But in our macro is just fine but we must add a little trick Milling to laser macro: Code: G21 G90 ; always specify units and mode, you might have run an inch file just before this, or left it in G91 G53 G0 Z-1 G0 X0 Y0 G92 X-54.6 Y-60.79 G0 X0 Y0 ; should position the laser over the work 0,0 $32=1 G4 P0 Laser to milling : (just remove the G92 offsets) Code: G21 G90 G53 G0 Z-1 G92.1 ; remove offset G0 X0 Y0 ; should position router over work 0,0 $32=0 G4 P0 The dwell command forces a buffer sync so that any following commands are not waiting for the EEPROM write and remain properly synchronized. I know that when you set up a camera in bCNC it offsets the camera using G92 so maybe the two cannot be mixed there, I will have to be careful.
Hi Sonny, I hope you are able to assist. I'm fairly new to the whole CNC concept but have a slight understanding. I have tried to run a simple drilling program and everything works fine except when i come to do the circle (G02 line) i get an invalid G codeID:26. I looked up what the error code means but to be honest have no clue what seems to be the problem or what i need to add to the line. Just for information if you need it i am using a 5mm cutter to drill 5mm holes at certain co ordinates and then a 8mm hole at the G02 line co ordinates. Here is my program: G00 X-40 Y8.0 F2000 G01 Z12 F1000 G00 Z-10.0 F1000 G00 X-100.0 F2000 G01 Z12 F1000 G00 Z-10.0 F1000 G00 X-139.50 Y40.0 F2000 G01 Z4 F1000 G02 I1.5 F1500 G01 Z8 G02 I1.5 G01 Z12 G02 I1.5 G00 Z-20 F1000 G00 Y60.0 G01 Z12 F1000 G00 Z-12.0 F1000 G00 X0 Y0 F2000 M30 Thanks in advance for your help.
G02 must have both X and Y parameters (in G17 mode). It should (perhaps must) also have both I and J parameters. You can find grbl's error responses and their meanings here: gnea/grbl The specific requirements of G02 are easy enough to Google.
Hi, you appear to have written that code yourself. that is pretty hardcore (-: but it is a good way to learn. However, maybe you should use something like Sketchup and the SketchUcam plugin to generate your Gcode. Reading Gcode that works is a good way to get into it. SketchUcam Howto - YouTube also, your Z appears to be upside down. negative Z is always 'drilling into the work'. CNC machines follow the 'right hand rule' for tool motion. ie when the we say Z moves negative it means the tool is moving toward/into the material. A gantry machine is obvious, but a moving table machine is not so obvious since the table must move 'the other way' so that the tool motion obeys the rule. If your machine does not obey the rule you will have great difficulty generating Gcode for it since everything expects the rule to be followed.
