[BUG] Homing Failed : Printer Halted randomly occurrs, even with no change to the firmware.

[ghost]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

Every so often, my printer seems to act up and starts saying "Homing Failed : Printer Halted".

This happens with the exact same firmware. No changes happened with the firmware.

When I want to print and the printer homes, or if I manually do a G28, the error shows up.

Other times, it works just fine. I can home the printer, use G28, and everything is fine.

I have posted several issues at this point. Is the board that I received problematic?

Bug Timeline

Just upgraded to SKR mini e3 V3.0

Expected behavior

It should always, consistently home without a problem. It should not occasionally throw "Homing Failed : Printer Halted"

Actual behavior

After some time, it starts a streak of "Homing Failed : Printer Halted" whenever I try to home the printer.

I have not found any specific correlation to this problem.

Steps to Reproduce

1. Try to home the printer.

Version of Marlin Firmware

Marlin 2.0.9.3

Printer model

Creality Ender 3

Electronics

SKR Mini e3 V3.0

Add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

Configuration.zip

[ellensp]

when homing it moves the bed size and if it doesn't hit and endstop it fails
to test this is issue. move hotend to furthest point from endstop. power off. power on, home axis
It this fails every time your bed settings/travel limits are not correct

[ghost]

Thanks for the reply.

So, nothing moves on the printer when I try to home it. Nothing happens. The screen seems to freeze for a moment, and then it shows "Homing Failed : Printer Halted".

Because of this, I'm not sure I can apply your suggestion.

What is also strange is that I did not change anything to my printer. Firmware, electronics, wiring, and everything is the same. Then, all of a sudden, it starts throwing the error, even though, a few moments before, I was able to home it without any problems.

[ellensp]

then it is very unlikely to be a firmware issue

[ghost]

Is it my board?

[Roonster78]

I've upgraded 3 of my printers fro, the SKR MINI E3 V1.2 to the SKR mini E3 V3.0 and updated them to the latest bugfix.
While G28 is working fine, G29 fails on all 3 printers very often. Before the print starts, bed leveling (ABL bilenear) fails randomly on the 3x3 grid and needs 2 to 3 retries to complete the leveling.

The (original) BLtouch 3.1 is directly connected to the BLtouch Port, Z-MIN Stop port on the board is not used an commented out. I've rechecked the wiring/connectors of all 3 BLtouch over the whole weekend several times to rule out any hardware issue.

Found a similiar (closed) issue #18526
Will test ENDSTOP_INTERRUPTS_FEATURE and give feedback. <- Don't know if it helps but I'm frustrated right now.

Configuration.zip

EDIT: Nope, slightly better but still fails on all 3 machines (always at the second / slow probe). If I configure it to just a single probe per grid point, it works normally.

[Roonster78]

So I may found the culprit. I've read through this (closed) issue: #18598 and I've commented out ADAPTIVE_STEP_SMOOTHING and now the bed leveling works again (2 attempts+extra probing) reliably, even at high feedrates.
Tried it on all 3 machines and did 10 test runs per machine without any fail or false trigger. As soon as I reactivate ADAPTIVE_STEP_SMOOTHING again, all 3 machines are failing randomly while leveling the bed and two machines crashed the nozzle into the bed. May ADAPTIVE_STEP_SMOOTHING is an issue again with the SKR mini E3 v3.0?

[Arakon]

I can confirm this issue. I just swapped from a v2.0 to a v3.0 board and every now and then, the pin will deploy, but not retract and trigger a "Probing failed". An UBL mesh ended up looking like this:

I'm using the latest bugfix release. I use the same exact settings as with 2.8.0.2 and 2.9.0.3 on the V2.0 board, which both caused no issues whatsoever.

Configuration.zip

Edit: Tried with ADAPTIVE_STEP_SMOOTHING disabled and was able to complete an M48 run, which failed every time before. Now generating a new mesh.
Edit 2: Mesh generation went through twice without issue. So yes, disabling ADAPTIVE_STEP_SMOOTHING seems to fix the issue.

Mesh with ADAPTIVE_STEP_SMOOTHING disabled:

[descipher]

Based on what I saw in the code and the fact that the STM32G0x CPU is 64Mhz I think ADAPTIVE_STEP_SMOOTHING is too aggressive on the CPU consuming more than 50% while XYZ step movements are active. On v2.0 the STM32F103RCT6 CPU is 72Mhz so it appears to keep up with the heavy IRQ load.

[ghost]

M502 followed by M500 seems to have suppressed the problem for me, at least for now.

[Arakon]

M502 followed by M500 seems to have suppressed the problem for me, at least for now.

Done this every time I updated to no avail, on my end.

[thisiskeithb]

Done this every time I updated to no avail, on my end.

Your issue is unrelated.

[Roonster78]

@thisiskeithb If this issue is related to the STM32G0x CPU and ADAPTIVE_STEP_SMOOTHING as @descipher described, I would recommend an update to the configuration file of the SKR mini E3 V3.0 board or at least a warning, when compiling the firmware.

So: Will ADAPTIVE_STEP_SMOOTHING improved in the future to be less agressive and we can activate the feature again in a later Firmware release or do we have to live without this function?

THX

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.