Grbl-LPC not homing Z on $H

Background: I am Giving up on MKS DLC V2 and I put the SBASE 1.3 on my CNC router. Even though I originally bought the SBASE to run grbl-LPC, it was still running the Smoothieware that shipped with it, and it kind of worked for a while, but I none of the senders I tried actually talked reliably to it, including UGS and Candle. I tried current Smoothieware as well as updates to UGS, both 2.0.7 and 2.0.9, platform and classic, and Candle wasn’t configurable to talk to Smoothieware and UGS kept telling me that grbl wasn’t done booting when I selected Smoothieware. (I occasionally got it to work by first telling it to connect with grbl, then disconnect, then connect with Smoothieware, but that wasn’t reliable and became less so.) I even updated the computer I was running on to Fedora 35 with all updates to make sure it wasn’t the OS on the computer…

So now I put the latest grbl-LPC on it; the bbba813 sbase build from the releases page. Now UGS can talk to it, at least partially, though the DRO never displays anything, as if it never recognizes the position reports. Candle seems to recognize them correctly. So far, so good.

My machine homes X and Y to the lower left (1st quadrant), and Z to highest position. (When working I zero to top of stock=0 and -Z to cut stock. I don’t really care about machine coordinates as long as they can be consistent.)

$H homes X and Y, but not Z. If I disable soft limits, Z moves in the correct direction when I jog, so it’s not that Z is not connected correctly. But I can’t get it to home Z. I have tried $23=3 and $23=7 to see if that has an impact on what it tries to do, but the Z axis never moves during homing.

I have also connected a dumb terminal and confirmed that the home switches are reporting right; e.g. that normally I see |Pn:P| and that I can individually trigger the stops and see |Pn:PX| |Pn:PY| and |Pn:PZ|

I’m really not sure what to do next to figure out why Z is not homing.


Are you using a pre-compiled Binary, or compiling GRBL yourself? This might be a long shot but in the grbl config before compiling (I’m not exactly sure where as I’m not at my computer right now) there is a setting for the homing cycle. It dictates which axes are homed, and in what order. Something like cycle0, cycle1, cycle2…

EDIT: Looks like it should be working, unless it got changed. This is from a version of GRBL-LPC I downloaded Nov. last year.

From config.h

Also, have you tried issuing the $HZ command to see if Z will home by itself?


I’m normally a build-it-myself person but I grabbed the binaries @cprezzi published on github. It realize now that he mentioned that the defaults were set up for a K40. I was thinking about laser mode being on, but didn’t think at all about not homing Z!

I had no idea that $HZ was available. I see in grbl/config.h that it is disabled by default. I’ll be changing that and doing a custom build that defaults to my config settings. :relaxed:

I’ve now read config.h and defaults.h and am more educated.

The new build works correctly, and has individual axis homing included. Thank you for pointing me to this!

Also, I needed $23=3 — I wasn’t clear on how it was interpreted. Here’s the config I used in case it is ever useful to anyone else…


Cool! Glad I could help!

1 Like

Small hint:
$10=3 is not valid. Since grbl version 1.1 the status report mask only allows 0-2. This might be the reason why UGS doesn’t show DRO values.


Oh. Thank you. So I wonder what it’s actually reporting then? I mean, I see the reports coming through. Does UGS parse the output of $$ and use it to interpret?

I don’t know if UGS expects wpos or mpos. In LaserWeb we read wpos ($10=0) to update the DRO.