The makerspace I belong to built an openbuilds ox. We used the Spark Concepts xPro V3 (GRBL V0.9) controller. I think everything is hooked up right because I can use Universal Gcode sender to move it around and homing seems to work. The problem is when I try and generate gcode from a model. I'm currently using Fusion 360 and generate a simple object and using CAM, I generate a Face path. Simulating it in Fusion 360 looks good. Now here's where I think I'm stumbling. I try to run the Post Processor on it to generate gcode. I've tried a couple processors. The first was the stock, Generic GRBL but that didn't work, then I found GitHub - Strooom/GRBL-Post-Processor: Start and tried to use the OpenbuildsGRBL.cps but when it starts, it flies off in the X direction until it hits the table and I stop it. Any links to documentation or videos on what I should be doing here would be really helpful. I've attached the generated file (1.nc) so you can see what it's generating. Also, below is my settings from the board (in case that matters at all): $$ $0=10 $1=25 $2=0 $3=6 $4=1 $5=0 $6=0 $10=3 $11=0.020 $12=0.002 $13=0 $20=0 $21=0 $22=1 $23=3 $24=25.000 $25=1000.000 $26=250 $27=5.000 $30=1000 $31=0 $32=0 $100=200.000 $101=200.000 $102=200.000 $110=1500.000 $111=1500.000 $112=1000.000 $120=20.000 $121=20.000 $122=20.000 $130=600.000 $131=760.000 $132=52.000
flies off in Z direction, you mean? Z is vertical. in the Gcode, it is this line G53 G0 Z-10 you say homing works. however, from what you say it is not set correctly. Z home is at the TOP of travel, far away from the table. for SAFETY! G53 G0 Z-10 is telling it to move to 10mm below that height,. Unless you have a very tall part that will not interfere with the material at all. G53 always moves in Machine Co-ordinates After homing you set the top of the material as the Work Coordinate Z = 0 There are 6 Work Coordinate system, G54 to G59, this program uses the default G54. When you hit the 'Reset Z' button in UGS it sets this for you unless you have changed WCS by issuing a G55/G56/G57/G58/G59 I just ran this code in Candle feeding GRBL1.1 and it works perfectly. LinuxCNC Documentation Wiki: CoordinateSystems The conventions for Machine co-ordinates and homing exist for safety. they also guide software writers as to what to expect from a machine and just about every Gcode generator will make the same assumptions based on the convention, ie, home is left-back-top, and that at least G54 has been set for the job at hand.
Sorry if there was some confusion, not the first thing it does. The first thing it does is the Z bits which seem to work fine. After that it starts to move the X and Y but it seems as if it's trying to go to a point outside of the table. I suspect it's that our table is smaller than that the post processor is designed for but I don't see where to change that. Thanks for the link to the Coordinate Systems, I'll be sure to read up on that.
oh, ok. The Gcode is in millimeters. if you have, somehow, forced GRBL to stay in inch mode, then the first X move is to 25 INCHES, which may be much bigger than your machine (-: how exactly you might force grbl to stay in inch mode I don't know except you may have set up a filter on the G21 line (tells it to use millimeters, every Gcode file should have its own setting for this, G21 for mm or G20 for inch) UGS can filter lines. Maybe you added one by accident?
So I've made a little bit of progress, seems my steps/mm were off which was part of it. The other part I'm still confused about and I suspect one of my settings is off. First, the CNC is laid out so that if you look from the top, the limit switches are in the bottom right corner. Running the homing sequence Moves it into this lower right corner. So to zero, the z-axis goes up until it hits the limit switch and then specifying 'G53 G0 Z-10' goes down to a MPos to -10 and 'G64 G0 Z-10' goes down to MPos to -13. I think this is right. Then I tried to debug the X position. The coordinates that it reports is an X of -595.005 and a Y of -755.016. If I go to the other side, by decreasing x, I can get to about X-40 which is the end of the table. So I realize that I can reset the Zero and in using the Work position (G54), then the X25.128 command works fine but this also resets the Y which would break the Y-18.109 part of the command. Should I have this setup differently?
The standard for homing is the top right corner, so that the whole of the work surface is 'negative'. This is what GRBL expects unless you mess with the settings in config.h Read this Set up the Homing Cycle · gnea/grbl Wiki · GitHub Also, make sure X + movement moves tool right Y + movement moves tool back Z + movement moves tool up away from the table. a video how can two 10mm movements go to -13? I recommend turning off homing entirely and make sure the machine works without it. After turning off all homing options, move the tool to back, right, top and reset GRBL (close and open your GUI is enough). Now the machine co-ordinates are correct and the entire workspace is negative. jog the tool to the 0,0,0 point on the workpiece (that you set in Fusion) and set XY and Z to 0, this will set the G54 workspace correctly. raise the tool a bit by jogging now run your Gcode and it should work correctly. if not, make this basic setup work correctly first , before enabling homing. Also, if you have not followed the correct wiring for the home switches, you will most likely have interference issues Wiring Limit Switches · gnea/grbl Wiki · GitHub
