<p>My Ender 3 Pro running the below firmware has suddenly started to ignore all endstops, causing stepper motors to skip and causing damage.</p>
<pre><code>FIRMWARE_NAME:Marlin bugfix-2.1.x (Jul 10 2024 11:45:28) 
SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin 
PROTOCOL_VERSION:1.0 MACHINE_TYPE:2024-07-10 11:43AM 
</code></pre>
<p>Video link: <a href="https://vimeo.com/983623557?share=copy" rel="nofollow noreferrer">https://vimeo.com/983623557?share=copy</a></p>
<p>Interestingly, M119 reports that the endstop trigger status is being detected correctly, below is the log before and after manually triggering x_min:</p>
<pre><code>Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: open
Recv: z_probe: TRIGGERED
Recv: filament: TRIGGERED
Recv: ok
[...]
Send: M119
Recv: Reporting endstop status
Recv: x_min: TRIGGERED
Recv: y_min: open
Recv: z_min: open
Recv: z_probe: TRIGGERED
Recv: filament: TRIGGERED
Recv: ok
[...]
</code></pre>
<p>M503 log:</p>
<pre><code>[...]
Send: M503
Recv: echo:; Linear Units:
Recv: echo:  G21 ; (mm)
Recv: echo:; Temperature Units:
Recv: echo:  M149 C ; Units in Celsius
Recv: echo:; Filament settings (Disabled):
Recv: echo:  M200 S0 D1.75
Recv: echo:; Steps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z400.00 E93.00
Recv: echo:; Max feedrates (units/s):
Recv: echo:  M203 X500.00 Y500.00 Z5.00 E25.00
Recv: echo:; Max Acceleration (units/s2):
Recv: echo:  M201 X500.00 Y500.00 Z100.00 E5000.00
Recv: echo:; Acceleration (units/s2) (P&lt;print-accel&gt; R&lt;retract-accel&gt; T&lt;travel-accel&gt;):
Recv: echo:  M204 P500.00 R500.00 T1000.00
Recv: echo:; Advanced (B&lt;min_segment_time_us&gt; S&lt;min_feedrate&gt; T&lt;min_travel_feedrate&gt; X&lt;max_jerk&gt; Y&lt;max_jerk&gt; Z&lt;max_jerk&gt; E&lt;max_jerk&gt;):
Recv: echo:  M205 B20000.00 S0.00 T0.00 X10.00 Y10.00 Z0.30 E5.00
Recv: echo:; Home offset:
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:; Auto Bed Leveling:
Recv: echo:  M420 S1 ; Leveling ON
Recv: echo:; Material heatup parameters:
Recv: echo:  M145 S0 H185.00 B45.00 F255
Recv: echo:  M145 S1 H240.00 B70.00 F255
Recv: echo:; Hotend PID:
Recv: echo:  M301 P23.59 I1.24 D112.30
Recv: echo:; Bed PID:
Recv: echo:  M304 P222.39 I34.75 D948.84
Recv: echo:; Z-Probe Offset:
Recv: echo:  M851 X36.20 Y-4.70 Z-1.91 ; (mm)
Recv: echo:; Filament load/unload:
Recv: echo:  M603 L0.00 U100.00 ; (mm)
Recv: echo:; Filament runout sensor:
Recv: echo:  M412 S1 ; Sensor ON
Recv: ok
[...]
</code></pre>
<p>M211 output:</p>
<pre><code>Send: M211
Recv:   M211 S1 ; ON
Recv:   Min:  X0.00 Y0.00 Z0.00   Max:  X235.00 Y235.00 Z250.00
Recv: ok
</code></pre>

CC BY-SA 4.0
2024-07-13T19:43:33.730Z
Did you upload a new firmware or did the old firmware suddenly fail? From your rest it seems as if the endstop pins are different! You say you trigger Z-min, but `M119` reports X-min to be triggered!
0scar
CC BY-SA 4.0
2024-07-13T20:01:24.180Z
I'm sorry, it was a typo, I triggered x_min. I don't recall having uploaded new firmware, but I'm not completely sure.
user84207
CC BY-SA 4.0
2024-07-13T21:04:13.337Z
Interestingly, if I try using the LCD "move axis", x=0 is reached before the real x_min is triggered.
user84207
CC BY-SA 4.0
2024-07-13T21:17:25.493Z
Auto-home from the LCD works as expected. I noticed the commands in octoprint are actually sending negative X-axis values: `Send: G0 X-10 F6000`
user84207
CC BY-SA 4.0
2024-07-13T21:19:58.887Z
The manual control tab appears to override the endstops, allowing for movement into negative values, but outside of the manual control tab things appear to be working normally.
user84207
CC BY-SA 4.0
2024-07-14T06:35:39.110Z
Send an `M503` and see what value `M211` has. With `M211 S0` movement beyond endstops is enabled, this is usually only used in determining the Z-offset when using a probe, otherwise you could damage physical endstops or your printer.
0scar
CC BY-SA 4.0
2024-07-14T06:44:27.327Z
P.S. negative values are possible, this implies that you have an offset from the endstops to the origin (0, 0) of the build plate. Negative values are only possible when there are offsets defined, if not, you travel beyond the endstop trigger point.
0scar
CC BY-SA 4.0
2024-07-16T01:07:48.857Z
There was no `M211` line in the `M503` output, but `M211`  indicates that software endstops are enabled and  all the mins are at 0, edited the question to add those logs. If software endstops are enabled and `>=0`, does that mean I shouldn't be able to move left after manually triggering `x_min`?
user84207
<creality-ender-3><marlin><endstop>
Marlin suddenly ignoring all endstops?
user84207
# Marlin suddenly ignoring all endstops?

(Asked by: username_0 on 2024-07-13)

My Ender 3 Pro running the below firmware has suddenly started to ignore all endstops, causing stepper motors to skip and causing damage.

```
FIRMWARE_NAME:Marlin bugfix-2.1.x (Jul 10 2024 11:45:28) 
SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin 
PROTOCOL_VERSION:1.0 MACHINE_TYPE:2024-07-10 11:43AM 

```

Video link: <https://vimeo.com/983623557?share=copy>

Interestingly, M119 reports that the endstop trigger status is being detected correctly, below is the log before and after manually triggering x\_min:

```
Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: open
Recv: z_probe: TRIGGERED
Recv: filament: TRIGGERED
Recv: ok
[...]
Send: M119
Recv: Reporting endstop status
Recv: x_min: TRIGGERED
Recv: y_min: open
Recv: z_min: open
Recv: z_probe: TRIGGERED
Recv: filament: TRIGGERED
Recv: ok
[...]

```

M503 log:

```
[...]
Send: M503
Recv: echo:; Linear Units:
Recv: echo:  G21 ; (mm)
Recv: echo:; Temperature Units:
Recv: echo:  M149 C ; Units in Celsius
Recv: echo:; Filament settings (Disabled):
Recv: echo:  M200 S0 D1.75
Recv: echo:; Steps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z400.00 E93.00
Recv: echo:; Max feedrates (units/s):
Recv: echo:  M203 X500.00 Y500.00 Z5.00 E25.00
Recv: echo:; Max Acceleration (units/s2):
Recv: echo:  M201 X500.00 Y500.00 Z100.00 E5000.00
Recv: echo:; Acceleration (units/s2) (P<print-accel> R<retract-accel> T<travel-accel>):
Recv: echo:  M204 P500.00 R500.00 T1000.00
Recv: echo:; Advanced (B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_jerk> Y<max_jerk> Z<max_jerk> E<max_jerk>):
Recv: echo:  M205 B20000.00 S0.00 T0.00 X10.00 Y10.00 Z0.30 E5.00
Recv: echo:; Home offset:
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:; Auto Bed Leveling:
Recv: echo:  M420 S1 ; Leveling ON
Recv: echo:; Material heatup parameters:
Recv: echo:  M145 S0 H185.00 B45.00 F255
Recv: echo:  M145 S1 H240.00 B70.00 F255
Recv: echo:; Hotend PID:
Recv: echo:  M301 P23.59 I1.24 D112.30
Recv: echo:; Bed PID:
Recv: echo:  M304 P222.39 I34.75 D948.84
Recv: echo:; Z-Probe Offset:
Recv: echo:  M851 X36.20 Y-4.70 Z-1.91 ; (mm)
Recv: echo:; Filament load/unload:
Recv: echo:  M603 L0.00 U100.00 ; (mm)
Recv: echo:; Filament runout sensor:
Recv: echo:  M412 S1 ; Sensor ON
Recv: ok
[...]

```

M211 output:

```
Send: M211
Recv:   M211 S1 ; ON
Recv:   Min:  X0.00 Y0.00 Z0.00   Max:  X235.00 Y235.00 Z250.00
Recv: ok

```

**Tags:** creality-ender-3, marlin, endstop

> **Comments:**
> **username_1**: Did you upload a new firmware or did the old firmware suddenly fail? From your rest it seems as if the endstop pins are different! You say you trigger Z-min, but `M119` reports X-min to be triggered!  
> **username_0**: I'm sorry, it was a typo, I triggered x_min. I don't recall having uploaded new firmware, but I'm not completely sure.  
> **username_0**: Interestingly, if I try using the LCD "move axis", x=0 is reached before the real x_min is triggered.  
> **username_0**: Auto-home from the LCD works as expected. I noticed the commands in octoprint are actually sending negative X-axis values: `Send: G0 X-10 F6000`  
> **username_0**: The manual control tab appears to override the endstops, allowing for movement into negative values, but outside of the manual control tab things appear to be working normally.  
> **username_1**: Send an `M503` and see what value `M211` has. With `M211 S0` movement beyond endstops is enabled, this is usually only used in determining the Z-offset when using a probe, otherwise you could damage physical endstops or your printer.  
> **username_1**: P.S. negative values are possible, this implies that you have an offset from the endstops to the origin (0, 0) of the build plate. Negative values are only possible when there are offsets defined, if not, you travel beyond the endstop trigger point.  
> **username_0**: There was no `M211` line in the `M503` output, but `M211`  indicates that software endstops are enabled and  all the mins are at 0, edited the question to add those logs. If software endstops are enabled and `>=0`, does that mean I shouldn't be able to move left after manually triggering `x_min`?  

---

## 0 answers

