X andy Y stop switches not registered in octoprint

What is the problem?

When using the autohome function, x home and y home in octoprint the limit trigger switch is ignored carriage smashed into the frame.
All my print jobs start with an auto home command but now the carriage smashes into the trigger and I get a home error. The autohome function does work from the printers menu.


What did you already try to solve it?

Tested the wire and switch with the multimeter both work fine.
Tested if the x move to the to the switch would also surpass the limit, it did not. (iphone app)
Tested just x home, it ignored the switch and crashed.
Tested the home function of the printer itself, that works fine.
read a thread about the absence of an sd card could trigger this bug. inserted a formatted sd card, confirmed it could be read. did not fix the problem.
rand a m119 command, even though manually triggering the triggers myself, the m119 reply remained "open" confirming the trigger is ignored by octoprint.
(Even-though I made a completely custom controlerbox case for my cr-10s the current configuration and firmware did work before the case mod.)

Have you tried running in safe mode?


Did running in safe mode solve the problem?

dont know.

Systeminfo Bundle

System Information

Please copy/paste the following when requesting support on the forums or when opening a new bug report:

browser.user_agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
connectivity.connection_check :
connectivity.connection_ok : true
connectivity.enabled : true
connectivity.online : true
connectivity.resolution_check : octoprint.org
connectivity.resolution_ok : true
env.hardware.cores : 4
env.hardware.freq : 1200
env.hardware.ram : 917016576
env.os.bits : 32
env.os.id : linux
env.os.platform : linux2
env.plugins.pi_support.model : Raspberry Pi 3 Model B Rev 1.2
env.plugins.pi_support.octopi_version : 0.15.1
env.plugins.pi_support.throttle_state : 0x50000
env.python.pip : 20.3.3
env.python.version : 2.7.13
env.python.virtualenv : true
octoprint.safe_mode : false
octoprint.version : 1.6.0
printer.firmware : Marlin TH3D U1.R2.B5
systeminfo.generator : systemapi


Additional information about your setup

Version 1.6.0, cr10s custom controlbox case Chrome, OSX mojave, 4 relay switch to for safety with psu control plugin.


The correct thing is that your endstop is not ignored by OctoPrint they are ignored by the printer firmware. Your M119 response is correct, the firmware is not reading the endstop. But OctoPrint has no control here, so this is a firmware 'bug' or misconfiguration somehow.

Aside from the bug where having/not having an SD card impacts it, there may be others - try and update your firmware or roll back to a known working version.

but if the firmware is ignoring the end stop, why doesn't it when I use the home function in the printer menu? that is the firmware right? or am I mixing stuff up.

That is the firmware, correct. Welcome to the world of firmware bugs... The communication over serial is often handled differently, and that's what you're seeing here.

The thing that I find so weird is that I have run succesful prints with this firmware version before my case-mod. Im going to try and recompile the firmware to see if that helps. I would like a safe way to test if what im doing helps because crashing every time is damaging the belt and steppers.

I would test it with the belt disconnected if you can, and press the endstop manually. Can't think of any other way to do it reliably without damaging the printer.