Some background questions:
Can you run these commands in Console and return the results here?
$I
$$
$#
?
I installed the limit switches on the back right side. I would like the machine to home there so the gantry is out of the way at job completion.
This is a custom built chassis. It was working fine (and still is) except for the homing issue. I added the switches to the machine. I am using GRBL 1.1 downloaded from Github and I configured it for this machine.
$$
$0=10
$1=25
$2=0
$3=0
$4=0
$5=0
$6=0
$10=0
$11=0.010
$12=0.002
$13=0
$20=0
$21=1
$22=1
$23=1
$24=250.000
$25=500.000
$26=250
$27=1.000
$30=1000
$31=1
$32=1
$100=42.950
$101=40.500
$102=250.000
$110=2000.000
$111=2000.000
$112=500.000
$120=50.000
$121=50.000
$122=10.000
$130=200.000
$131=500.000
$132=200.000
ok
$I
[VER:1.1h.20190830:]
[OPT:V,15,128]
Target buffer size found
ok
$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok
?
<Idle|WPos:-131.898,-257.407,300.000|FS:0,0|Ov:100,100,100>
ok
I don’t see any smoking guns here that would prevent it from moving. Some oddities and things that might need sorting later on.
negative coordinates - you’ll likely need to set a coordinate offset so that you’re not working in a negative quadrant
$23=1 ; is there a reason why you’ve inverted the X-axis homing direction? By default GRBL will attempt to home in the positive direction for both axes which is what you want in this case.
Again, neither of these things should prevent movement.
Try this, can you disconnect the limit switches and try power cycling? Be ready to stop the machine to prevent crashing in case things do move.
I disconnected the switches. Same thing happens. I never tried using the “home” button as I knew there were no switches. I was hoping that there was a setting in LB I was missing but it seems my issue is elswhere.
As for the $23=1 I set it to that trying different setting and checking results. I’ll set it back to 0
Sigh! Don’t know what to check now. May just have to go without switches.
A bit confused…
Added switches and your problem begins?
There is only a configuration difference between no switches and switches. If you did not do anything other than plugging in switches, in the correct place, that should not affect machine operation.
Did it work properly when you powered it up immediately after the switch installation. Meaning could you move it as normal? This was before you modified any of the $variables?
Did you use Lightburn to modify the $ variables or did you do it via the console?
At this point, I’d recommend restoring the original, working grbl configuration from your backup.
Most of these machines ‘lock’ the motors to prevent loosing where they are during processing. What kind of sound are you hearing, they should be engaged already.
@jkwilborn This is a brand new build. @Billr94 is saying that everything other than homing is working. He’s not getting any movement for the homing cycle which is weird.
@billr94 this could possibly be a software thing. Try loading the custom GRBL build from laserGRBL (v.1.1h, custom, XY Homing 20190830). You can find it here:
Flashing Grbl Firmware – LaserGRBL
Thank you berainlb, I think you are right. I did some searching last night and discovered that when homing, the Z axis homes first, then X,Y. The X,Y axis does not move until Z is homed. Since my machine has no Z axis to home, it times out and throws the error. The fix is to edit the config.h file and delete or comment out the Z axis homing command.
I will update my firmware and am confident that will fix the issue.
Seems like a moment where you say “DUH”!
Yeah, I was suspecting potentially the Z-Axis issue but wasn’t certain based on your setup.
You may want to try the pre-built firmware from laserGRBL before compiling your own. It also has homing location set to machine origin.
What a nightmare!!! I uploaded the firmware and now when I go to move the X axis to the right say 50mm, the Y also moves 50 mm back. Both X and Y move when only the X is supposed to. LB now shows an error: Expected command letter [0.9j.20160317:]. I have no idea what this means and why the axis’s are doing this. I have tried different GRBL flashed with the same result. I even tried using GRBL laser and it won’t even connect to the machine.
This has to be a bad flash. What firmware did you first try to flash? How are you doing the flash? What board are you using?
Did you try going back to the firmware you had been on until now? If it’s not working correctly then for sure a corruption in the flashing process.
I have an Arduino Uno with CNC shield. I flashed with the GRBL 1.1h but when I open it in LB, it says it is GRBL 0.9i. I know I flashed the correct version as I deleted all the other versions I tried so I wouldn’t get any more confused than I am now!
Odd. Do you have any other devices plugged in? Maybe wires getting crossed?
What are you using to do the flash?
OK…I think I almost have it. I got the flash to work. Both X and Y move as they should. I have LB setup to have “home” at the back right of the machine. When I trigger “home”, the X axis moves to the right and homes X. (perfect)! However the Y axis moves forward ( instead of back). I then triggered the arrows to move the Y axis back and forth and the arrows move the Y correctly so the motors are NOT wires wrong.
What is $23 set to? I feel like this should be $23=0 but based on what you’re saying it might need to be $23=2.
I had it on $23=1. I did not know you can set it to 2. I could not get things to work right. I would try reversing the motors and the homing would work but then the arrow movement was backwards. I tried resetting the origin to the front left, try homing it and the Y would work but the X was backwards! I kept trying various combinations and finally just gave up! I turned off homing and set everything back to the way it was. I have been working on this for hours! I will try $23=2 tomorrow. Too aggravated tonight.
Put everything back to the way it was set $23=3.
If you previously had $23=1 this needs to be 3, not 2 as I previously indicated.
If all motions other than homing direction was working correctly then that setting should resolve it.
That worked!!! Everything seems to work as it should. HOWEVER… and there is always a “however”, After homing LB does not “0” the axes’s. Is there a way to have LB home everything than set the X, Y to zero out?
After homing don’t move the laser and type this in console and send results please.
$I
$$
$#
?
Also, confirm the dimensions of your working area.
$I
[VER:1.1h.20190830:]
[OPT:V,15,128]
Target buffer size found
$$
$0=10
$1=25
$2=0
$3=0
$4=0
$5=0
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=1
$22=1
$23=3
$24=25.000
$25=1000.000
$26=250
$27=1.500
$30=1000
$31=1
$32=1
$100=42.950
$101=40.500
$102=250.000
$110=2000.000
$111=2000.000
$112=500.000
$120=50.000
$121=50.000
$122=10.000
$130=1000.000
$131=1000.000
$132=200.000
$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
?
<Idle|MPos:-998.510,-998.494,0.000|FS:0,0|WCO:0.000,0.000,0.000>
I’m guessing your machine dimensions are not 1000mm x 1000mm. If they are then disregard.
If they are not then change these values to match your dimensions:
$130=[x-dimension]
$131=[y-dimension]
Then to fix your offset do this:
$10=0 ; this will have your machine report work coordinates, not machine coordinates.
G10 L2 P1 x-[x-dimension] y-[y-dimension] ; replace with what you used for $130, $131