ALARM:9 Homing fail. Could not find limit switch within search distance

Hi all,

After installing limit switches on my sculpfun, I first ran into the issue that the switches were of the wrong type, I installed optical ones that give a high signal when triggered.
So I needed to update the GBRL firmware with inverted limit switches, because homing only made the machine travel the pull-off distance at first. I tried to get the switch inverted incpu_map.h because that is where i found the following:

#define LIMIT_MASK     ((0<<X_LIMIT_BIT)|(0<<Y_LIMIT_BIT)|(0<<Z_LIMIT_BIT))

Is this the correct place to change ? I used grbl-1.1h.20190825
It did something because the machine started but when pressing homing the motors lock-up, I read somewhere that this is because the newly flashed firmware is trying to home the Z-axis first, this can be cancelled in config.h by commenting

// #define HOMING_CYCLE_0 (1<<Z_AXIS)  

and uncommenting

 #define HOMING_CYCLE_0 (1<<X_AXIS)  // COREXY COMPATIBLE: First home X
 #define HOMING_CYCLE_1 (1<<Y_AXIS)  // COREXY COMPATIBLE: Then home Y

But still there is no homing action only ALARM 9.
If I move the laser by jogging to the edge, it halts when it sees the switch, so the switch is working correctly.

Does anybody know what I am missing out on, Thanks.

You could use and NO or NC switches, both need to be the same, but either will work…
I used optical on one of my little cnc machines and one day it threw a piece of debris across the sensor, it trashed the job… I’ve been using hall effect switches ever since…


The limit mask, is probably to tell the machine which limit pins will be used… I’d guess that

#define LIMIT_MASK     ((0<<X_LIMIT_BIT)|(0<<Y_LIMIT_BIT)|(0<<Z_LIMIT_BIT))

The |(0<<Z_LIMIT_BIT) could be removed, if you have no Z axes.

The others just tell it what order it will home them… Some controller run both axes simultaneously after it moves the Z stuff out of the way.


Both the home seek direction and limit/home active states are in the grbl registers… and can be set via the console with $ commands. All these could probably be set in the configuration…

The $ id’s and what they do are here

This is an old pocket copy, that I use as the axes direction control is a little more clear… This is outdated and is missing some values… Just be aware… it’s also a pdf, so remove the .txt extension.

GRBL_Settings_Pocket_Guide_Rev_B .pdf.txt (214.4 KB)

I don’t have one of these operating… SO I’m just assuming the change will disable the Z axes from homing…

Good luck

:smile_cat:

Thanks jack, that is a handy document!!

I was not sure whether to remove the Z Mask, it could bite me in the *ss if it is needed somewhere else in the code and not defined. I tried removing it now but it did not matter, it compiled but when homing it had the same behaviour

I did find another solution, by reprogramming the controller through the build in firmware from LaserGRBL. There is one with XY-homing enabled and that one works fine i discovered.

I was hoping to have i bit more control over the firmware I use, so any pointers are still welcome!!

Hi Miki,

you are making it far more complicated than necessary :slight_smile: You only need to recompile the firmware, if you use different types of switches and need to invert only some of them. If you just have a complete set of inverted limit switches, set $5=1. Done. No special firmware needed.

Here is some documentation on limit switches and I also provide a firmware that has been optimized for Sculpfun + limit switches: Limit Switches - Diode Laser Wiki

Edit: the section you are describing is not the correct one, everything is set in config.h:
Search for this line: #define INVERT_LIMIT_PIN_MASK

// Inverts select limit pin states based on the following mask. This effects all limit pin functions,
// such as hard limits and homing. However, this is different from overall invert limits setting.
// This build option will invert only the limit pins defined here, and then the invert limits setting
// will be applied to all of them. This is useful when a user has a mixed set of limit pins with both
// normally-open(NO) and normally-closed(NC) switches installed on their machine.
// NOTE: PLEASE DO NOT USE THIS, unless you have a situation that needs it.
#define INVERT_LIMIT_PIN_MASK ((1<<Z_LIMIT_BIT)) // Default disabled. Uncomment to enable.

The homing should be set to

#define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS))

Then both axis are homed simultaneously, it’s more time efficient.

Hi Melvin,

yes that is what I am doing now, after reinstalling the firmware through LaserGRBL i had to invert the switches through $5.

To be fair I wasn’t aware of that in the beginning that I could unfold more settings in the machine settings tab. I tried typing $5 in the console but it didnt recognize the command.

Thanks for pointing out the correct location for the limit mask, maybe that is the reason that my X and Y axis freeze up on initializing the homing sequence, maybe it is still awaiting the Z limit switch first. I will give it a go.

I have a firmware that has those changes already included: Firmware Update & Settings - Diode Laser Wiki

If you just put $5 in the console, it should usually report the value. If you put $5=1, it should be set. If this didn’t work, there might have been an issue with the firmware.

That is a nice WIKI page Melvin, THX. I took the V2 hex and uploaded to my S9 and it works perfect after inverting the switches with $5.

But did you only change the homing sequence or did you change other stuff related to the X, Y and Z axis.

After programming with your V2 hex and saving the settings to a file, I reprogrammed with a "clean"version from github where I only changed the homing sequence to XY, and after I inverted the switches and press the homing button it keeps comming back with alarm 9.
The only clue i have so far is that both X and Y are energized, it feels like it tries to home with speed 0.

There MUST be other settings not correct in the standard config or settings.h.

Any chance you can provide me with your config and settings file? The cpu_map.h and the defaults.h seem not to carry the issue.

THX

Actually, there is a dropdown at the firmware section called “list of changes”. It should include all changes I did compared to the original files. The rest should be identical. I can double-check tomorrow, but that list should be complete.

:grinning: :wink:

Thanks will work through it, if I find the culprit I’ll drop it here.

You’ll find it… we are here if you need us…

:smile_cat:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.