Marlin: Homing and auto bed leveling problem

[it9ozs]

Hi everybody, I have a problem with my firmware 1.1.9.
I'm using a CR-10S and Marlin 1.1.9 configured, but 9 times to 10, i had this error: Homing Failed, printer healted please restart.
This happens when i make an auto homing or before printing or after printing!...
Other strange thing: during Auto bed leveling (bilinear with original bltouch), my primter sometimes start to probe in a wrong point and continuing probing, X axis, would be go over max X position.

What can I do?

I posted my configuration.h and configuration adv.

thanks
CR-10S Config.zip

[Thairay]

I got the same issue with the wrong starting point but only after I canceled a print from octoprint. I got the homing failed error too, but not as frequent as you describe it.
It seems like it's a similar issue to #11553

[JordanGohan]

I'm too with the same problem.

[marcio-ao]

This may be related to #11626?

[marcio-ao]

Try enabling ENDSTOP_NOISE_FILTER in Configuration_adv.h and see if it makes a difference for you.

[it9ozs]

Thans marcio-ao....I will try when come back from my holidays.

[bistory]

FYI, auto-leveling using a bltouch clone (TriangleLab one) that was working in 1.1.8 and not in 1.1.9 anymore is ok when I enable Noise filter ! 🥇

[it9ozs]

Thanks tuo so much....i Will try...😊

[Kaibob2]

I also had this strange homing behaviour after upgrading to 1.1.9 from 1.1.7. Up to then i didn't even know i had a noise issue. My Printer is completely homebuild and i suspected the optical endstops were NC but they are NO which makes them much more sensitive for noise.
Anyway, enabling ENDSTOP_NOISE_FILTER fixed the homing issue perefctly, but i would suggest to make the Noise filter intensity configurable in configuration.h.
Maybe with an additional line like //#define ENDSTOP_NOISE_FILTER_INTENSITY X where X is a value from 1 to 7
Modifying the intensity value endstop_poll_count = 7; in Endstops.cpp is inconvenient and hard to find for the normal user.
The description text in Endtstops.cpp is perfect and should then move to configuration.h too.

[it9ozs]

Hi guy's, thanks for your help. I solved my problem after enable the endstop noise filter.
Now I would understand why my z_offset change it self... I mean...the setted value is the same, but sometimes I need to change going down because results much higher and first layer haven't grip on the bed....if I level only the corners, print good, if I use auto bed leveling have this issue.

[rraymakers]

Looks like the ENDSTOP_NOISE_FILTER enables also solved this problem on my Ender 3.
This problem started at the same time the under-voltage warning in my OctoPi disappeared. Related? Not enough data to say.

[RemiDeluxe]

Hello, what i have to do to enable the ENDSTOP_NOISE_FILTER? I Updated my CR-10S via firmware updater in octopi. I got the hex file from printed solid. How can I access to the configuration file to enable the option?

[Babbott173]

Same problem but mines on the Y axis on my CR10S BLtouch. just like Github#11626. besides enabling filtering is there a fix yet? is this a bug?

[it9ozs]

Yes, disable filtering and will fix the problem

[boelle]

@it9ozs so problem solved? if so maybe click the green close button below

[it9ozs]

Yes...sorry...problem solved...thanks to all...

[Babbott173]

Don't settle for ENDSTOP_NOISE_FILTER guys!!! I meant to get back to you all but I found out the actual problem. Do all of you have cable extensions??? that is the common denominator here. separate your switch and motor wires from the bundle and BAAAM....no more HALT! i just had to do it for my Y axis. Thanks for your help everyone!

[marcio-ao]

@Babbott173: Sure, separation is always a good alternative if you can manage to do it without ending up with a mess of wires :)

Shielded cables would be even better or maybe twisted-pair differential signalling... :-D

[Kaibob2]

For me, disabling Endstop Interrupt feature fixed this issue perfectly. My best guess is, that on every EMI induced false Endstop trigger the interrupt is triggered and i guess there are quite a lot in rapid succession. This might cause the movement to stutter because each interrupt wants to be served.

[github-actions[bot]]

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.