SO3: Homing Fail Alarm

Software
1

greetings,

i installed my limit/homing switches and enabled $21 and $22 as directed.

using UGS, whenever i connect to the SO3, i automatically get an alarm error. when i send $X to unlock the machine, then try $H to home — the Z axis goes down (-Z) by about a millimeter, and everything stops.

with $22 disabled, i get no alarm, i can jog the machine properly in all axis, and all the switches work perfectly when physical limits are reached; in all axis.

also, enabling $20 makes no difference.

here are some screen shots:

image.jpeg2592×1936 2.03 MB

image.jpeg2073×1548 1.84 MB

thank you!

kev

2

Limit switches installation page ( http://docs.carbide3d.com/article/67-shapeoko-3-limit-switch-installation ) says to enable only the homing cycle $22=1. Why you need to enable both hard limits $21=1 and homing cycle $22=1?
I installed my limit switches too but enabled only the homing cycle $22=1. Have I done wrong?
I’m newbie btw…

3

thank you for your reply!

if i do not enable hard limits, then my limit switches don’t work and my separate axis can crash into the mechanism itself.

i’d like to get everything running regarding the switches, but will take hard limits over homing any day.

4

Did you try to enable homing cycle in carbide motion without enabling hard limits and then run $H to see if it works? I used UGS too a few times but never attempted to use my limit switches with it.

I use my limit switches in CM by enabling only the homing cycle and everything is fine. I will try to do this later in UGS too because I’m curious if I get the same error with you.

5

i have a SparkFun SO3 and i love it because it is red, so carbide motion is not available to me (different controller boards).

also, “homing only” is for the carbide homing switches, which are not full +/- axis limit switches… but +axis only… so of course i want hard limits enabled.

furthermore, UGS hasn’t the overhead of CM, and therefore is a simpler method of testing any SO3/GRBL maker CNC for basic setup and routines.

my SO3 works perfectly, except when i enable $22 and try homing.

thanks for your help!!

6

twforeman did a kit, and it worked perfectly for me. Unfortunately the license isn’t compatible w/ the wiki. Check his Etsy store?

Or try bCNC?

Make sure the machine isn’t on the switches when starting.

Have you grounded everything in a star topology?

7

It looks like you have $23 set to ‘1’. This inverts the direction of homing for the X axis. I’m not sure why this would cause your issue, but I would set it to ‘0’.

The machine is supposed to start in alarm state when you have homing enabled. This is to force you to do a homing cycle right away.

You shouldn’t need to unlock the machine before homing, just send a $H and it should home.

Homing should work no matter what control software you are using. It’s all internal to Grbl. I have used both UGS and bCNC and have had no homing issues.

1 Like
8

his kit is the one i installed — highly recommended.

i have manually centered the spindle, so i’m no where near tripping the switches.

as far as grounding goes, i simply attached the switches to their proper connection points on the controller board.

as i’ve said, i can run the machine and all limit switches work perfectly. if i enable $22 (homing cycle), and send $H, the Z axis lowers by a millimeter (it should start to rise) and i get a homing failure alarm.

thanks for your input!

9

okay, yeah… i set $23 to 0 and still the same problem — homing failure alarm.

thanks for the additional info on the homing sequence; i am still getting the same error. here is a photo of it from a fresh start:

image.jpeg2592×1936 2.68 MB

thank you!

EDIT: i saw that $3 was set to 6, so i changed it to 0, now when i send $H the Z axis goes up by about a millimeter, then i get the homing fail alarm

repeated sends of $H finally get it to the Z+ limit switch where it does its proper back-off thing. then, both the X and Y axis move about 1mm simultaneously, and everything stops… and i get the error again.

like the Z axis, i can keep sending $H and Z will check itself, then X and Y move as described… and again the error.

i imagine doing this for about 20 minutes might actually home the thing?

by setting $3 to 0, however, when jogging the machine around normally the X and Z axis are reversed.

here are my current grbl settings:

$0=10 (step pulse, usec)
$1=255 (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=255 (status report mask:11111111)
$11=0.020 (junction deviation, mm)
$12=0.010 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=1 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=25.000 (homing feed, mm/min)
$25=500.000 (homing seek, mm/min)
$26=100 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=40.000 (x, step/mm)
$101=40.000 (y, step/mm)
$102=40.000 (z, step/mm)
$110=500.000 (x max rate, mm/min)
$111=500.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=25.000 (x accel, mm/sec^2)
$121=25.000 (y accel, mm/sec^2)
$122=400.000 (z accel, mm/sec^2)
$130=425.000 (x max travel, mm)
$131=465.000 (y max travel, mm)
$132=64.000 (z max travel, mm)

10

Okay, you’ve solved part of the problem.

I just re-flashed my machine and ran into the same issue with the Z going the wrong way. I ended up setting $3=3. This is a bit mask for direction and 3 means reverse X & Y but not Z. This way the X and Y will home to the upper right and put the work area in all negative space - which is supposed to be the default.

The fact that you are getting a homing fail error is interesting. When I mis-set my $3 I got one of those when the Z moved too far without hitting a switch. I would suggest that your max travel is set too low, but it looks fine. You could try jacking up $130-$132 and see if it helps.

I don’t see anything else in your settings that looks wrong to me. So I’m kind of stumped.

11

i tried raising those numbers and it didn’t help… but i set $3 back to 6 so my normal jogging, etc. goes in the correct directions.

then i had to change the value in $23 (homing dir invert mask) to 7 so they would run properly during homing as well. so “00000000” became “00000111” in binary — and i believe the last three bits represent Z, Y, X?

anyway, i had noticed that many of my grbl settings were not the recommended SO3 settings, so i changed them and my axis are moving very much faster now!!

i still cannot home properly, but verified that if i move everything within a few mm’s of being homed, then send $H a few times, it will contact all the switches and pull-back… and i finally get an “ok”.

so it’s an inconvenient work-around to mostly home it manually, but at least i know if the three axis could travel more than about a mm at a time that the end of the homing cycle behaves properly.

thanks again for trying to help me!

12

Kevin,

Not sure if you ever figured your issue out, but I was having the same problem. My solution (through a bunch of trial and error) is changing $5=1 (limit pins invert, bool) and $23=3 (homing dir invert mask:00000011). This makes the Z-axis move up and the X & Y move to the lower left corner. Change $23=0 (homing dir invert mask:00000000) for upper right. Before changing $5, I was doing exactly what you described doing, but it would always hit the limit and then travel the wrong way (crash). Hope this helps.

Kyle

2 Likes
13

Kyle, I have searched for the solution for the past 3 days, finally came across your post. I followed your settings and my Shapeoko 3 (sparkfun) is homing properly now with Direction invert set to 6 and homing invert set to 0. I overlooked the limit pin setting which ended up being the culprit.

Thanks a bunch for your help!