[BUG] Sensorless homing on delta printers with bump and backoff

[Sewyboowy]

Bug Description

I am using a delta printer with 2209 drivers and sensorless homing, which I have just managed to get working using bugfix 2.0.x. When I set x, y, z home bump to 0 (as suggested in Configuration_adv.h , the x and y carriages attempt their second homing run, however, they are of course already homed, which causes my y stepper to grind. This does not happen on the first homing run, ie, the carriages move and detect their collision correctly. When setting home bump to 10, each carriage completes its first run successfully. Then, the x and y carriages complete their second run correctly, however, the z carriage appears not to attempt a second run, so it stays 10mm away from its endstop.
I have also tried using the homing_backoff feature. When doing so, the first run for each carriage is successful, however, I have had the second run fail badly for both the y and z carriages on separate occasions, where the relevant stepper starts skipping steps and starts speeding up (skipping steps faster and faster) when the carriage hits its endstop.

My Configurations

myconfigs.zip

Steps to Reproduce

1. Home delta printer on all axis
2. Can do with bump of 0 or 10 and homing_backoff as described above

Expected behavior: Carriages home and stop, or all back off for a repeated "bump", or return to backoff distance

Actual behavior: Not all axis attempt a repeated bump or grind if bump=0. With backoff set, stepper on one axis accelerates on second bump.

Im happy to provide any more information I can!

[sjasonsmith]

There is another recent issue that is probably related to what you are seeing. You might want to look at that.
#16366

If the information in that issue is correct, then it verifies that enabling backoff is likely to cause issues on delta, as you noticed.

As for the bump...as far as I can tell it should not be attempting a bump if you have it set to 0.0. It should cause that entire section of code to be skipped.

[sjasonsmith]

Can you report the endstop height adjustments stored in M666? You probably need to use M503 S0 to get the current values. I'm not sure whether they are accessible through the menu.

[Sewyboowy]

Thanks!

I'll have a look at #16366 and see if I can replicate their results.
Just tried compiling with bump as 0.0 instead of 0 as I remember reading delta kinematics should all be floats, but got a compiling error. Left it bump as 0 or 10 (rather than 0.0 or 10.0) for now.

Regarding the M666, M503 does return the endstop adjustments. With bump set to both 0 and 10, I got
M666 x0.00 y0.00 z0.00

[sjasonsmith]

Regarding the M666, M503 does return the endstop adjustments. With bump set to both 0 and 10, I got
M666 x0.00 y0.00 z0.00

Well, that is one of my theories disproved :)
I thought maybe a positive offset in M666 was the source of the grinding, but it seems not.

[sjasonsmith]

I wish I could help debug it, but I've already got too many things going on right now. I don't use sensorless homing, but I suspect the behavior you are seeing will probably happen with endstops as well. Unfortunately not a lot of people are actively developing for delta, so anything outside the typical use-cases very likely has issues that need someone to volunteer to debug/fix.

[Sewyboowy]

Ok, thanks for your help anyway.

I was able to get the code from #16366 to work on my bugfix version (2.0.x) and now backoff does work as expected. I noticed that now, when I first power up the printer and home it, it acts perfectly, no skipped steps or anything (with a bump of 0). However, if i then home again, I get the same behaviour as last time. Looking more closely, each carriage reaches its end stop, stops and then rotates a small amount more (to move the carriage past the endstop). Furthermore, sometimes now it all homes perfectly anyway without me changing anything, literally homing twice in a row.

With a bump of 10, the homing acts the same as in my first comment, however, all carriages move down after homing so the z carriage stays offset from x and y.

It's sad deltas are being left behind by marlin, I presume that is just due to the increased popularity of Cartesian etc? Are there any plans to catch deltas up to the rest of the formats, or are people moving to other firmware for delta support?

Let me know if you have any other ideas!

[Sewyboowy]

To get the #16366 code working in the bugfix version, i had to change "Marlin.h" to "MarlinCore.h" in the delta.cpp file, just in case anyone needs to do that too.

[Sewyboowy]

It's sad deltas are being left behind by marlin, I presume that is just due to the increased popularity of Cartesian etc? Are there any plans to catch deltas up to the rest of the formats, or are people moving to other firmware for delta support?

Just thinking that homing has never been an issue for me with normal endstop switches since I built my printer in 2015. Are issues arising again as Marlin 2.0 is still very new?

[sjasonsmith]

It's sad deltas are being left behind by marlin, I presume that is just due to the increased popularity of Cartesian etc?

I can't answer in any official capacity, as I'm just a random person on the internet who submits pull requests.

Volunteers come and go, and people tend to work on the things that most interest them or that they have on their own printers. Cartesian printers are by far the most common, so it is where most attention goes.

For sensorless homing specifically, not that many people seem to use it. I think the general consensus is that it is more trouble than it is worth, and switches are more reliable, although I'm sure someone will challenge me on that.

With nearly infinite possible configurations in Marlin, there will always be combinations that don't work right. When they are found, Marlin needs community members willing to jump in and help solve the issues. If no willing contributors are using deltas, issues are unlikely to get fixed.

[Sewyboowy]

Thanks for your help,

It looks like I may have to learn how I can help then! Currently, I have experience with python, r and arduino, which I used for my 3rd year (bachelors degree) thesis. I am unsure how a bug fix written, for example in #16366 may get incorporated into the main marlin branch, if that's even possible?
I am currently in my final year (of a masters degree) at university so I don't have much time, but it'd certainly be fun to tinker and see if I can do something useful!

[sjasonsmith]

for example in #16366 may get incorporated into the main marlin branch, if that's even possible?

I’m not sure what’s happening with that one. Once you think you have a fix for something it is more effective to post it as a pull request than to attach files to an issue. Attaching fixed files to an issue depends on someone else happening to pick them up and move it forward. I think there is a guide on marlinfw.org to getting started developing and posting pull requests.

[Sewyboowy]

Ok brilliant, maybe I'll see if I can re write the code in #16366 (they said it needed rewriting) and post a pull request. If that works out then I can start looking into the other homing issues. For now the homing is functional if a little annoying.

[DickyMcCockpants]

Sorry I was going to try and pull my code but I don't have experience with github and got busy with other stuff. Feel free to pull it. I'd also suggest re-downloading the latest 2.0 bugfix branch, copying the changes I made to delta and motion (not complicated) and then re-doing your config files from scratch starting from the delta example files. This solved many odd problems several times when too many changes are made. If it persists after that try and track down the position it thinks it is in and what makes it move the wrong direction from there.

[Sewyboowy]

Don't worry I have no idea what i'm doing with github!

Yeah I used your code in the bugfix branch, had to change "Marlin.h" to "MarlinCore.h" in the delta.cpp file but otherwise it worked perfectly. Good job!

This is my first marlin 2.0 setup so it's pretty freshly configured, although I did change quite a lot when trying to get sensorless homing to work, so maybe i'll start from scratch again.

[Sewyboowy]

I may have found another related issue. I've just got sensorless probing working now and for safety and increased accuracy it is recommended to do so at a low current. I've done with;

X_CURRENT_HOME X_CURRENT/3

with the same for y and z. Now, it feels as though the x and y carriages detect stall much more easily, which is great, but z feels significantly harder to stall than x and y. I know you can use M906 to get the motor current, but is there a way I can test the motor current whilst homing?

[boelle]

do you use 2.0.1 or bugfix 2.0.x ?

[Sewyboowy]

I have used both and getting the same issue

[sjasonsmith]

I posted PR #16657 to address the backoff issues. This is based on the changes from @DickyMcCockpants, but I had to manually merge the changes and probably dropped some of them.

At this point it's not clear to me which issues remain, and whether they are specific to sensorless homing or would apply to all delta machines.

[boelle]

closing since PR #16657 has been merged

we can reopen if the same issue is still there

[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.