OK, GRBL is confuzzling me. I have it hooked up to a 4’ by 2’ table, and when I use jog, directions are all correct. The homing switches are in the top left position, but the sensible spot for (0,0) is bottom left… Is there a way to make that happen?
here’s my GRBL config:
$0=20 (step pulse, usec)
$1=25 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=0 (dir port invert mask:00000000)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=19 (status report mask:00010011)
$11=0.010 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=1 (homing dir invert mask:00000001)
$24=25.000 (homing feed, mm/min)
$25=500.000 (homing seek, mm/min)
$26=255 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=94.000 (x, step/mm)
$101=47.000 (y, step/mm)
$102=250.000 (z, step/mm)
$110=15000.000 (x max rate, mm/min)
$111=20000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=1000.000 (x accel, mm/sec^2)
$121=2000.000 (y accel, mm/sec^2)
$122=10.000 (z accel, mm/sec^2)
$130=1219.200 (x max travel, mm)
$131=609.600 (y max travel, mm)
$132=200.000 (z max travel, mm)
I’ve already set the homing direction invert mask. It homes. It finds the switches in the topleft corner, and then sits there… I get Idle,MPos:-1218.202,-1.000,0.000,WPos:-1218.202,-1.000,0.000
When I then try to cut something, it immediately moves to what it thinks is 0,0 (I think) which is near the top-right corner, and then slams into X Max because its not in the *&!#$%&^ actual 0,0.
G+ keeps partially eating my comments… Hopefully, it doesn’t clear up leaving the same thing (more or less) 3 times.
What I think I need is some G-code to update MPos, so that when $H is done, I can tell it “you’re at 0,609.6” and then I can do a “X0Y0” (if I understand things right… No guarantees!) to get the head to the spot I want it.
Does that seem right?
There is a command to set X0, Y0 I had it on universal gcode sender
$H
G91
X-75Y-535
G92
The above finds the limit switches, then moves to my 0,0 with a relative movement, then sets 0,0 , but the G92 seems to set the working position, not the machine absolute position.
I think that’s good enough for LaserWeb, but I’m not sure how to put that into the homing config. It doesn’t look like I can do multi-line in the homing field.
There was a post that +Peter van der Walt said you can do a / (slash) in between commands
That doesn’t seem to work in the homing field. The homing field automagically turns the \n into a \N
I tried doing it as a macro, and it breaks at the $H, too:
$X\nG91\nX100Y100\n$H\nG91\nX-75Y-535\nG92
So to sum up what happened with this:
- I created a macro called “before homing” that does some initialisation. Specifically, it moves X 10mm right.
- I do a home. This usually works!
- I created a macro called “after home” that moves the head to the correct home spot in the lower left. It uses G28 to go to the right spot, then G92X0Y0 to set it to be the working home.
The first macro is necessary because GRBL won’t home at all if it starts the homing sequence with a limit switch engaged, and the lower left corner has X limit engaged. If the machine was turned off with the head in the usual spot, then it won’t home when turned back on.
I spoke to GRBL devs, and to paraphrase, it works as designed, issue closed WONT_FIX.