[BUG] Firmware resets while homing

[thespooniest]

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

Yes, and the problem still exists.

Bug Description

The firmware resets early in the homing process. If the axes started near their zero point, the firmware actually acts as though the switches weren't there, continuing to grind into the zero point until the firmware resets. But if the axes start far from their zero points, the firmware will reset anyway, a few seconds after they begin to move, even if they haven't hit their endstops yet.

Bug Timeline

This started on 10/24/2022, not long after Input Shaping merged in.

Expected behavior

I expected the homing process to complete normally.

Actual behavior

If the axes start close to the zero point, they will grind against the endstops for a second or two before the firmware resets. If the axes start far from the zero point, the firmware still resets a second or two after movement begins, even if they have not reached the zero point.

Steps to Reproduce

1. Compile Marlin with Input Shaping enabled.
2. Upload the firmware and reset the printer.
3. From the main menu, choose Motion->Homing->Auto Home.
4. Observe the results.

Version of Marlin Firmware

bugfix-2.1.x, 2022-10-24

Printer model

Creality Ender 3 Pro

Electronics

BigTreeTech SKR Mini e3 v3

Add-ons

BLTouch 3.1

Bed Leveling

UBL Bilinear mesh

Your Slicer

Cura

Host Software

OctoPrint

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Marlin.zip

[thisiskeithb]

Using the same firmware build, does recompiling with Input Shaping disabled fix the issue?

[thespooniest]

Yes, it does.

…

On Tue, Oct 25, 2022, 1:45 AM Keith Bennett ***@***.***> wrote: Using the same firmware build, does recompiling with Input Shaping disabled fix the issue? — Reply to this email directly, view it on GitHub <#24927 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANCHFOL2A5F4AOHP3TAWZDWE5XYRANCNFSM6AAAAAARNTF3XY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Foxies-CSTL]

Hi, I had this problem and it was related to the lack of RAM. The end of compilation showed me 97% usage and it was not enough.
Now it's up to 85%. Maybe a way forward and look carefully at the conditions regarding the input shaping #24797.

[ellensp]

Already checked that from provided configs

Checking size .pio/build/STM32G0B1RE_btt/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  15.2% (used 22420 bytes from 147456 bytes)
Flash: [=====     ]  52.6% (used 275544 bytes from 524288 bytes)

[cbagwell]

I have same board but also have about 10 hours of prints with input shaping enabled and no resets seen. I do see the homing grinding into the edge when it starts close to edge or if I abort a print using menu but I see that with input shaping not compiled in as well and its not 100% reproducible.

The main difference I saw in configs is I do not have UBL enabled so it might help to isolate if you test with bilinear enabled.

Also, just an FYI. I noticed you had a typo in BLTOUCH_HS_MODE define so not sure how that is being treated during compile.

[tombrazier]

I do see the homing grinding into the edge when it starts close to edge or if I abort a print using menu but I see that with input shaping not compiled in as well and its not 100% reproducible.

@cbagwell and @thespooniest are you both using sensorless homing?

@thespooniest Is homing speed the same with and without IS enabled? And when the firmware resets, do you get a message saying "homing failed"?

@thespooniest What default_env do you have in platform.ini? And once we have the answer, @cbagwell do you have the same?

[thespooniest]

I am not using sensorless homing. As part of this process I did discover that I'd forgotten to remove the DIAG jumper on my mainboard (as you're supposed to do with the SKR Mini e3 v3), but removing it does not seem to have fixed the problem: the motor still grinds if homing starts too close to zero, and the board still resets after a second or two either way.

Homing speed seems to be the same with and without IS enabled, at least on X and Y. I don't know about Z, because the firmware resets before reaching that part. I don't get any message, either onscreen or through OctoPrint: the firmware just resets.

My default_env is default_envs = STM32G0B1RE_btt

[cbagwell]

I'm not using sensorless homing as well and also default_envs = STM32G0B1RE_btt.

My wild guess is if I disabled QUICK_HOME then it might resolve the homing issue (but I haven't taken time to test that idea yet). That's because It moves diagonal until it hits the X end stop then Y movement stops while X starts grinding. I haven't reviewed the code yet but I assume that means it has entered some state where its should be backing back up but is confused and maybe its that concurrent Y movement that is causing the confusion.

I see the reference BTT Mini E3 V3 config has QUICK_HOME commented out but I carried it over from my CrealityV422 config file. Maybe its commented out for a reason?

In my case, I eventually get a homing failed message but I do not see a reset and have to power cycle manually to recover.

But mine of course is just an inconvenience since an average home does work and I can use IS.

[thespooniest]

I tried disabling QUICK_HOME. It didn't solve the reset issue.

The motor grinding changes, but isn't fixed. If I start far from the zero point, the board resets a second or so after the homing starts, even though it hasn't hit the zero point, just like before. If I start a medium distance from the zero point, the head eventually hits zero and begins to grind, but the board resets a second or two after homing starts, again like before.

But if the head starts very close to zero, it will grind until it generates a "Homing Failed - Please Reset" error. This halts the printer, which prevents the automatic reset that the other situations have.

[thespooniest]

Possible clue. As I attempted to change the nozzle, I told the printer to move the extruder -10mm. This also caused a spontaneous reset. Perhaps it has something to do with input shaping while moving an axis into the negatives?

(And I also broke my thermistor, so I may not be able to do tests for myself for a couple days. New one arrives Thursday ).

[tombrazier]

I have a SKR Mini v3 coming my way, so will try to replicate.

[tombrazier]

But for now @cbagwell can you build with @thespooniest's exact config and see if it replicates for you?

[cbagwell]

I was able to reproduce the reboot on first try with attached config files. Still the biggest difference between my config is UBL is enabled so that would be my next guess to toggle off.

I'll try to do more testing in a few hours or at least upload a diff of my working config.

[cbagwell]

My printer ended up being used for prints so I wasn't able to debug... so I'll attach diff between my no-reset config and the reset config. In addition to UBL, here are some items that jumped out at me that are X/Y related:

• SKEW_CORRECTION
• ADAPTIVE_STEP_SMOOTHING (brought up a lot in HOMING failure discussions on this board)

minie3v3.zip