Since updating, homing is not working as it should

Get Help
1

What is the problem?

Since updating Octoprint today, when I press "home" in controls, the machine makes a loud grating noise and I have to shut it off. Eventually showing "Machine Fault" error. This worked perfectly last night before update.

Interestingly this happens from any position once I press it. I can however move the axis manually in the Octoprint controls section and this works fine.

What did you already try to solve it?

Nothing - not sure what to do next

Have you tried running in safe mode?

No

Did running in safe mode solve the problem?

No

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

browser.user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0
connectivity.connection_check: 1.1.1.1:53
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.0
env.hardware.ram: 914010112
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 3 Model B Rev 1.2
env.plugins.pi_support.octopi_camera_stack: webcamd
env.plugins.pi_support.octopi_version: 0.18.0
env.plugins.pi_support.octopiuptodate_build: 0.18.0-1.7.3-20220120112925
env.plugins.pi_support.octopiuptodate_build_short: 2022.01.20.112925
env.plugins.pi_support.throttle_check_enabled: True
env.plugins.pi_support.throttle_check_functional: True
env.plugins.pi_support.throttle_state: 0x50000
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: True
octoprint.last_safe_mode.date: unknown
octoprint.last_safe_mode.reason: unknown
octoprint.safe_mode: False
octoprint.version: 1.9.3
systeminfo.generated: 2024-01-17T10:15:54Z
systeminfo.generator: zipapi

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

Running from Raspberry PI. Controlled through web browser on PC, connected by WIFI.

2

Can you try to home the axis one by one so we can figure out which one has the issue?

G28 X
G28 Y
G28 Z
3

So G28 Y is the only one working propery.

X axis is the main culprit with the bed grinding as it moves when homing.
Z axis seems to move in the opposite direction. Problem is, when I move the controls the up and down are working as they should.

4

Weird

Try

G28 X0
G28 Z0

Instead

5

G28 X0 just moved my Z axis up until I had to power off?

6

Was worth a try.
Some firmwares need the 0 for some reason.

I just noticed that you didn't try it in safe mode.
Please do that to rule out any plugin issues.

Does it work when you home the printer from the screen?

7

What firmware are you using. On what printer?
The systeminfo bundle could help too.

8

So I tried homing without octopi plugged in and getting the same type of homing errors. Does Octopi auto update the firmware of my printer as well as Octopi?

My printer is a Creality CR10s Pro. It also has BL touch 3 and it's been a long time but I believe I had to modify the firmware for that? I'm so out of the loop for how I set this up its been years.

9

Here is system bundle
octoprint-systeminfo-20240117144500.zip (423.8 KB)

10

Neither OctoPi nor OctoPrint update the firmware on the printer. The only thing that might affect the printer would be updated USB serial drivers, but that is unlikely.

11

I've noticed when switching on the printer. Even when the gantry is high. The readout is x0 y0 z0. This is without octopi plugged in.

I'm wondering did I have some G code to compensate for the BL touch 3 that was wiped maybe?

I then cannot move manually futher down past z0

12

That's normal. It's a security feature.

I'm not aware of any gcode that would do that.

I just don't get why moving the axis works when moving while homing it causes those weird issues.

I think at this point we can try unusual stuff.
Try to reset the printer to factory settings.

Run M502 followed by M500 in the terminal, restart the printer and check if that changed anything.

Also open the cover to the mainboard an check if all cables are still all the way plugged in.

13

We have also seen this issue in the past depending on if the SD card is present in the printer:

Might be worth ruling out by making sure there is an SD card in the printer, and that it is fully working.

14

Thanks I tried checking cables. All look good.
Tried M502 and then M500, reset and then tried again. Nothing changed.

I'm wondering how do I move the gantry down when its at the top now. Homing should bring it down while I have a BL touch installed?

15

I don't have an SD card in the slot, although to note my SD card slot has been damaged for a while now and I could only use octopi to send data to it. This has not been an issue in the past but possibly with this new octopi update it is now causing an issue?
Then again, that doesn't explain why its happened all of a sudden since doing the update if octopi does not modify the machines firmware.

16

I would agree with your final point, OctoPrint does not control how homing works on the printer so it would be unlikely that the OctoPrint update has impacted anything.

If the same issue happens when OctoPrint is disconnected (i.e. home from the printer's screen), then it is something to do with your printer firmware/hardware.

17

Just turn the Z stepper slowly by hand until the gantry is back down

18

I'm now thinking its time to replace the motherboard, as it had that faulty sd card slot anyway. Maybe theres a more stable refresh by now for the CR10s Pro? V1

19

Yes thanks forgot about that

20

Your stop switch is bad or wire broke off of it.