Marlin: [BUG] LEVEL_CORNERS bed leveling causes axis crashing

[adboll]

Bug Description

MOTION --> BED LEVELING --> LEVEL CORNERS, causes X Y and Z motor crashing into normally working endstops.

My Configurations

Marlin 2.0.5.3, MKS SGEN L, TMC2209 in UART with sensorless homing disabled,.9 angle Neva 17 motors, Tevo Tornado gold

Steps to Reproduce

1. Perform normal Auto Home SUCCESSFULLY
2. Perform Motion --> Bed Leveling --> Level Corners
3. Crashing motors like it tried to home again this time it ignores endstops.

Expected behavior:

1. Maybe one extra SUCCESSFUL home in case one wasn't performed manually prior to Level Corners.
2. NOT CRASH into endstops.
3. Perform travel to corners for proper manual bed leveling

Actual behavior:

1. Level Corners crash into endstops
2. May recover and continue on but then XYZ references may or may not be off.

Additional Information

My endstops taking a beating everytime this happens and can't level bed efficiently without working command.

Configuration.zip

[XDA-Bam]

I see you set all your corner insets (#define LEVEL_CORNERS_INSET_LFRB) to zero. Have you tried setting them a bit higher? Perhaps to 5 or 10?

[adboll]

That was a troubleshooting step. They were all at stock 30. It appears to try to rehome at start of command but ignores working physical endstops.

-------- Original message --------
From: XDA-Bam [e-mail]
Date: 6/5/20 7:28 PM (GMT-06:00)
To: MarlinFirmware/Marlin [e-mail]
Cc: adboll [e-mail], Author [e-mail]
Subject: Re: [MarlinFirmware/Marlin] [BUG] LEVEL_CORNERS bed leveling causes axis crashing (#18207)

I see you set all your corner insets (#define LEVEL_CORNERS_INSET_LFRB) to zero. Have you tried setting them a bit higher? Perhaps to 5 or 10?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/18207#issuecomment-639915579, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP3B2PNXUAP7BYG5NILWIKTRVGERTANCNFSM4NURP2PA.

[adboll]

I also posted a video in the Marlin firmware

-------- Original message --------
From: XDA-Bam [e-mail]
Date: 6/5/20 7:28 PM (GMT-06:00)
To: MarlinFirmware/Marlin [e-mail]
Cc: adboll [e-mail], Author [e-mail]
Subject: Re: [MarlinFirmware/Marlin] [BUG] LEVEL_CORNERS bed leveling causes axis crashing (#18207)

I see you set all your corner insets (#define LEVEL_CORNERS_INSET_LFRB) to zero. Have you tried setting them a bit higher? Perhaps to 5 or 10?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/18207#issuecomment-639915579, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP3B2PNXUAP7BYG5NILWIKTRVGERTANCNFSM4NURP2PA.

[adboll]

Anyone looking into this?

[adboll]

I figured this out!!!! A setting that I originally set caused this! However, I do think a code change is due or at least sanity_check.h for this issue. Why? Because of the fact the algorithm should always take into account physical end stops and not try to drive past them.

In configuration.h

I messed up when converting from Marlin 1.1.9 to Marlin 2.0.x and undefined this setting because of my math background (origin of X and Y always 0,0, well not in 3D printer land):
AN ADDITIONAL CODE COMMENT WOULD BE GOOD HERE AS WELL
Something like: Unless using printer(s) such and such,etc., most printers do not use bed center defined as X=0 and Y=0
// The center of the bed is at (X=0, Y=0)
#define BED_CENTER_AT_0_0

In conditionals_post.h, using the above setting (when defined) works BUT does not play well with bed size, physical end stops, and when used in LEVEL_CORNERS calculation. After chasing down what LEVEL_CORNERS was using as a bed reference X_MIN_BED it all became VERY clear. As the first corner it was trying to drive X and Y beyond their stops IGNORING the hard end stops and then slams them!
Put some sort of check in for physical end stop violation when implementing or using the following variables
// Get the linear boundaries of the bed
#define X_MIN_BED (X_CENTER - _X_HALF_BED)
#define X_MAX_BED (X_MIN_BED + X_BED_SIZE)
#define Y_MIN_BED (Y_CENTER - _Y_HALF_BED)
#define Y_MAX_BED (Y_MIN_BED + Y_BED_SIZE)

Although I fixed my setting error, because of these settings ignoring physical end stops, I recommend leaving this open as a bug and making the changes recommended.

[kaywu9453]

I have the same problem, close #define BED_CENTER_AT_0_0 and execute AUTO HOME, the nozzle will return to the middle of the bed. Execution of LEVEL CORNERS X axis will not stop at the end point.
The machine model is ender3 PRO

[thisiskeithb]

Because of the fact the algorithm should always take into account physical end stops and not try to drive past them.

You’ll need to enable ENDSTOPS_ALWAYS_ON_DEFAULT if you want your endstops to always be on as they’re only enabled while homing.

I messed up when converting from Marlin 1.1.9 to Marlin 2.0.x and undefined this setting because of my math background (origin of X and Y always 0,0, well not in 3D printer land):
AN ADDITIONAL CODE COMMENT WOULD BE GOOD HERE AS WELL
Something like: Unless using printer(s) such and such,etc., most printers do not use bed center defined as X=0 and Y=0
// The center of the bed is at (X=0, Y=0)

define BED_CENTER_AT_0_0

Correct. The front left corner is 0,0 on cartesian machines, so this should only be enabled for deltas (scara and polar too?)

I have the same problem, close #define BED_CENTER_AT_0_0 and execute AUTO HOME, the nozzle will return to the middle of the bed. Execution of LEVEL CORNERS X axis will not stop at the end point.
The machine model is ender3 PRO

See my advice above and disable BED_CENTER_AT_0_0. If you want your hotend to home in the center, enable Z_SAFE_HOMING since it defaults to X_CENTER, Y_CENTER.

[adboll]

Thanks for the reply! I guess I didn't quite understand the ENDSTOPS_ALWAYS_ON_DEFAULT or glazed over it when initially setting up 2.0.x.

Not to criticize too much, but I was trying to think of a use case when you wouldn't want ENDSTOPS_ALWAYS_ON_DEFAULT defined. I could not think of any off the top of my head. Weird feature, but OK.

I appreciate the support!

[wnypoker]

Did the issue look something like this? I think I might have a similar issue.

https://streamable.com/ok4e1h

I think enabled ENDSTOPS_ALWAYS_ON_DEFAULT is helping to stop the X/Y axis crash.

But I can't get the probe to start closer to the front left corner after it does the initial centering.

Any ideas?

Thanks.

[sjasonsmith]

After reading through this, it seems that the problems can be avoided by disabling BED_CENTER_AT_0_0, but there are some underlying issues. Usually this flag would be used for Delta machines, but I'm going to mark this one as a bug, with the following reasoning:

1. If BED_CENTER_AT_0_0 is supported on cartesian machines, bed leveling mechanisms should account for this, or at least report a build-time error if they are incompatible.

2. If BED_CENTER_AT_0_0 is not supported on cartesian machines, then that needs to be more obvious and fail at build-time.

[thisiskeithb]

If BED_CENTER_AT_0_0 is supported on cartesian machines, bed leveling mechanisms should account for this

Since slicers/hosts treat 0,0 as the front left corner on cartesians, I’d assume using BED_CENTER_AT_0_0 would only shift the entire print into the back right corner + off the build plate.

or at least report a build-time error if they are incompatible.

I think this makes the most sense.

[sjasonsmith]

Since slicers/hosts treat 0,0 as the front left corner on cartesians

Well, Cura let's you specify center-origin for any printer you want, and PrusaSlicer appears to let you enter any coordinate you want as the origin. Based on that, I don't think the combination of cartesion and BED_CENTER_AT_0_0 is at least logically invalid. Whether it is valid in practice or not is another question.

[boelle]

@adboll
Please test the bugfix-2.0.x branch to see where it stands.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

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