<p>For anyone looking I figured out what the issue was. Turns out that I had miswired the JST connectors coming from the switch to the board, having not double-checked and proceeding to connect wires to the board from the switch based on the color of the wires and my assumptions (black to ground, red to VCC, other color to signal). Actually for my switches black was VCC, red was signal, and the other color was ground. Thankfully it seems the board isn't worse for wear despite my errors in wiring previously, and now the printer is functional.</p>

CC BY-SA 4.0
2023-01-22T17:40:25.333Z
Thanks for posting the answer and glad you found it. I have never heard or had experience with such an issue, strange it worked individually but not sequentially. Please don't forget to accept the answer after 48 hours!
0scar
CC BY-SA 4.0
2023-01-22T19:39:54.853Z
Thanks Oscar I appreciate that, and will mark as complete the answer I submitted. Yeah this is the first time this happened for me but I'm glad despite my mistakes the board is still good. I saw your comment earlier about using the bubble level and I agree, just used it for coarsely resetting the position after experiencing the issue with the Z-axis motors and endstop.
Joseph Richards
CC BY-SA 4.0
2023-01-22T17:34:38.737Z
2023-01-22T17:38:13.493Z
2023-01-22T17:38:13.493Z
Joseph Richards
<p>I'm experiencing an issue with the auto homing where the Z-axis will ignore the endstop when I use the auto home button in Pronterface. Strangely, homing the axes individually I don't seem to have any issues, but when I use <code>G28</code> or home the axes sequentially I observe the Z-axis motors to continue moving the gantry down despite definitely having hit the Z-endstop. Below is a link to a video demonstrating this issue:</p>
<p><div class="youtube-embed"><div>
                <iframe width="640px" height="395px" src="https://www.youtube.com/embed/seLivJzvh0E?start=0"></iframe>
            </div></div></p>
<p>Triggering the Z-endstop manually (with my finger) the <code>M119</code> command shows &quot;TRIGGERED&quot;. I tested, starting from a high Z position and descending towards the endstop, manually triggering the endstop (with my finger) and I observed the Z-axis motors stop.</p>
<p>I used Marlin Bugfix 2.0.9.3.x preconfigured release from BTT's GitHub corresponding to this board (BTT SKR 3 EZ), only changing things like motor direction and build area so as to correspond to the printer.</p>
<p>I am able to copy/paste the <code>configuration.h</code> file if that will help.</p>

CC BY-SA 4.0
2023-01-22T08:26:03.803Z
P.S. a bubble level is useless for levelling the printer, see [here](https://3dprinting.stackexchange.com/a/7892/).
0scar
<marlin><homing><endstop><bug>
Auto Homing issue (Z-axis ignores endstop but individually homing each axis there is no problem)
Joseph Richards
# Auto Homing issue (Z-axis ignores endstop but individually homing each axis there is no problem)

(Asked by: username_0 on 2023-01-22)

I'm experiencing an issue with the auto homing where the Z-axis will ignore the endstop when I use the auto home button in Pronterface. Strangely, homing the axes individually I don't seem to have any issues, but when I use `G28` or home the axes sequentially I observe the Z-axis motors to continue moving the gantry down despite definitely having hit the Z-endstop. Below is a link to a video demonstrating this issue:

Triggering the Z-endstop manually (with my finger) the `M119` command shows "TRIGGERED". I tested, starting from a high Z position and descending towards the endstop, manually triggering the endstop (with my finger) and I observed the Z-axis motors stop.

I used Marlin Bugfix 2.0.9.3.x preconfigured release from BTT's GitHub corresponding to this board (BTT SKR 3 EZ), only changing things like motor direction and build area so as to correspond to the printer.

I am able to copy/paste the `configuration.h` file if that will help.

**Tags:** marlin, homing, endstop, bug
> **Comments:**
> **username_1**: P.S. a bubble level is useless for levelling the printer, see [here](https://3dprinting.stackexchange.com/a/7892/).  

---

## 1 answers

### Answer by username_0 on 2023-01-22. Score: 2 | Accepted answer

For anyone looking I figured out what the issue was. Turns out that I had miswired the JST connectors coming from the switch to the board, having not double-checked and proceeding to connect wires to the board from the switch based on the color of the wires and my assumptions (black to ground, red to VCC, other color to signal). Actually for my switches black was VCC, red was signal, and the other color was ground. Thankfully it seems the board isn't worse for wear despite my errors in wiring previously, and now the printer is functional.

> **Comments:**
> **username_1**: Thanks for posting the answer and glad you found it. I have never heard or had experience with such an issue, strange it worked individually but not sequentially. Please don't forget to accept the answer after 48 hours!  
> **username_0**: Thanks Oscar I appreciate that, and will mark as complete the answer I submitted. Yeah this is the first time this happened for me but I'm glad despite my mistakes the board is still good. I saw your comment earlier about using the bubble level and I agree, just used it for coarsely resetting the position after experiencing the issue with the Z-axis motors and endstop.  

---

