This is going to be a little hard to explain, I got a grbl board to rebuild a laser that was given to me, I am by no means new at this I have built a few grbl machines, but I went to run this and motions and kinematics are correct but when I click home I get alarm 8, with no response from the endstops, after the alarm has reset if I hit any if the endstops it gives me alarm 1, hard limit, so what I am wondering is how can the pull up not sense homing while the endstops are triggered, but it can use them for hard limits, help, I have been at this for a week, haven’t change homing masking, is the only thing I haven’t changed
A few questions to better understand the situation:
- What actually happens when you press the home button? Is there any movement at all? Do you hear anything from the steppers?
- Does the laser home when you first turn on? If not, what exactly happens?
- In what configuration have you wired the endstops? What time of switches have you used for this?
- What controller board are you using?
- What GRBL firmware are you using?
- DId you compile the firmware yourself or this was pre-built?
- Is this a 2-axis system?
- What corner do you intend the machine to home to?
Please post the following:
- Full screenshot of LightBurn with error message
- Output of console for:
$I
$$
$#
?
No it doesn’t home before or after connection or after start up, when the larm resets I can jog, and engrave normally, however the problem begins when I tell it to go home, it just freezes, itried soft limits in combination with hard limits, but I keep on getting the same error, and as you.can see the pull ups on the board work fine since I get the alarm 1 when I hit the endstop manually
While you’re working through the other questions one thing I need to ask.
What’s the intent of this configuration for homing direction inversion?
$23=15
Wrong number, I will correct,
Last set if answers, I am running a cnc shield with a nano, I compiled the grbl, i tried using other compiles, I get no motion when I ask for homing, I have xzy mins hooked to test and no motion or trigger, however I can hard limit the machine, meaning that if I moved it pass the endstop it stops motion and rest automatically which tells me the pull up is working but I am missing something in firmware, I have been working with grbl and marlin for about ten years and I have never have anything like this before
There was a very similar issue here the other day. Please review and circle back.
You can start reading from about here:
Tried with no result, I am pulling my hair out
Can you explain exactly what you’ve tried and what the results were? Systematically please.
Sure, I went to the website downloaded the specific release of grbl, opened to config.h to change the the homing from z the x and y, to just x and y, then uploaded it to the board, the results were the same, I send it home, no motion, I manually engaged the enstops, no result, I waited it for reset, once reset I tested the endstops for hard limits and once again they showed alarm 1: , after this I jogged the x and the y towards the endstops to make sure it was engaging and once again the motors stop right at the endstop, I am truly confused
Which website, which release? The file I specified was a binary. There should not have been any config.h file to change.
Are you familiar with GitHub?
Download the binary from here:
LaserGRBL/02-v1.1h-custom, XY Homing-20190830.hex at master · arkypita/LaserGRBL · GitHub
I’m assuming that the .h file is only used during compilation. At least when I was compiling grbl it was. So the above sequence would not change the binary. Some of these do read a configuration file when they boot, but most are not a .h file.
It is complaining about the homing sequence.
When a grbl controller is up and running it will detect when any of the limit switches becoming active.
Your ‘testing’ only shows that the limit switches are connected, not that they are ‘properly’ connected.
However, during homing, it must ‘look’ specifically for that axis limit switch exclusively.
Indicating a limit switch wiring problem.
If X & Y were swapped, you would get this failure. It would still ‘sense’ the trigger as a fault during normal operation. Leading to a false assumption they are connected and working properly. 
They may simply be mislabeled on your board. My Woodpecker has x, y & z labeled inputs. However, it turns out they are really z, y & x. Right to left engineer and a left to right user, board label.
You may still have the Z issue, but steps in the right direction.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.