search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.19k stars 19.21k forks source link

[BUG] Z_MIN_POS is declared to be a travel limit but is instead used as Z0. In consequence, (a) probe z offset changes with Z_MIN_POS (b) bed leveling does not work. #25365

Open Tehvan opened 1 year ago

Tehvan commented 1 year ago

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

Yes, and the problem still exists.

Bug Description

I'm on UBL (bugfix-2.1.x, 071F0094) Running G29 P1 probes the bed. Great. However, I get a mesh with values like -1.1, -1.2, etc. That is not supposed to happen. I set the probe Z offset meticulously and it is true to within 0.1mm. Something (about the first probe?) (that sets the zero for the mesh?) is not executing properly. (Is the first probe point being hijacked somehow? G29 P1 gives a 6x6 mesh but supposedly 37 points were completed.)

Bug Timeline

No response

Expected behavior

Mesh is generated with values "very close to zero" as per the manual.

Actual behavior

Mesh is generated with values over 1mm from zero.

Steps to Reproduce

I have an inductive probe, so i've enabled PROBING_HEATERS_OFF, WAIT_FOR_BED_HEATER, and WAIT_FOR_HOTEND. I had the bed temperature set to 110C throughout the process and print. The heater options being enabled extends the time for each probe a fair bit--it takes maybe 5 seconds per probe. I found it curious that it probed the first point almost instantaneously and then moved on to take the normal amount of time for probe point 2. This makes me suspect probe point 1 is used as a "home" probe but is not executed like a normal probe (initial approach, back-off, and then slow approach) thus offsetting the whole mesh by some amount. I ran G29 P5 and then G29 P6 C[-mean of the center 4 points, ex. +1.175] to correct the issue. Guess what, despite correcting over 1mm, my ASA laid down perfectly.

Version of Marlin Firmware

bugfix-2.1.x, 071F0094

Printer model

X5SA Pro (loosely)

Electronics

SKR 1.4

Add-ons

No response

Bed Leveling

UBL Bilinear mesh

Your Slicer

Slic3r

Host Software

OctoPrint

Don't forget to include

Additional information & file uploads

Configuration.zip

Tehvan commented 1 year ago

It doesn't look like the first probe should be any different. https://github.com/MarlinFirmware/Marlin/blob/ef3f484d3ca620272f849b913851541b54b51c09/Marlin/src/feature/bedlevel/ubl/ubl_G29.cpp#L766-L773 https://github.com/MarlinFirmware/Marlin/blob/ef3f484d3ca620272f849b913851541b54b51c09/Marlin/src/feature/bedlevel/ubl/ubl_G29.cpp#L794-L805 I may have to check the behavior of the first probe again. Perhaps I was distracted and it was "normal" and the issue is in post-processing? But that doesn't explain why we get 37 probe points but only a 6x6 grid. Perhaps the probe count on the GUI and terminal are (incorrectly) counting an intial homing probe as a probe?

Tehvan commented 1 year ago

I'm closing this because I'm 90% sure the problem is my (hypersensitive) inductive probe. Variables that change the trigger point of the inductive probe are bed temp, (probably) chamber temp, and (maybe) nozzle temp.

Tehvan commented 1 year ago

I'm now running a CR touch (optical sensor) and getting the same issue. So looks like the 10% chance wins. The bed has soaked for over 30minutes so temperature is not an issue. Mesh was zeroed G29 P0 and UBL turned off (G29 D). G28 was run immediately before probing so that is not an issue. Verified G28 is correct by moving the nozzle to the bed and the position is 0. I ran the probing twice, just to show the consistency:

First Run: Recv: Bed Topography Report: Recv: Recv: ( 1,329) (319,329) Recv: 0 1 2 3 4 5 6 7 8 9 Recv: 9 | . . . . . . . . . . Recv: | Recv: 8 | . . . . . . . . . . Recv: | Recv: 7 | . . -1.32 -1.23 -1.19 -1.15 -1.17 -1.23 . . Recv: | Recv: 6 | . . -1.20 -1.14 -1.09 -1.06 -1.07 -1.10 . . Recv: | Recv: 5 | . . -1.14 -1.08 -1.05 -0.99 -1.00 -1.02 . . Recv: | Recv: 4 | . . -1.15 -1.07 -1.01 -0.98 [-0.99] -1.00 . . Recv: | Recv: 3 | . . -1.17 -1.08 -1.02 -0.99 -0.99 -1.02 . . Recv: | Recv: 2 | . . -1.26 -1.16 -1.07 -1.00 -1.01 -1.08 . . Recv: | Recv: 1 | . . . . . . . . . . Recv: | Recv: 0 | . . . . . . . . . . Recv: 0 1 2 3 4 5 6 7 8 9 Recv: ( 1, 1) (319, 1) Recv: Recv: ok

Second Run: Recv: Bed Topography Report: Recv: Recv: ( 1,329) (319,329) Recv: 0 1 2 3 4 5 6 7 8 9 Recv: 9 | . . . . . . . . . . Recv: | Recv: 8 | . . . . . . . . . . Recv: | Recv: 7 | . . -1.33 -1.24 -1.19 -1.16 -1.19 -1.25 . . Recv: | Recv: 6 | . . -1.20 -1.12 -1.10 -1.05 -1.08 -1.11 . . Recv: | Recv: 5 | . . -1.16 -1.08 -1.03 -0.99 -1.01 -1.03 . . Recv: | Recv: 4 | . . -1.16 -1.08 -1.02 -0.95 [-0.99] -1.02 . . Recv: | Recv: 3 | . . -1.19 -1.10 -1.03 -1.00 -1.01 -1.03 . . Recv: | Recv: 2 | . . -1.28 -1.18 -1.09 -1.02 -1.03 -1.10 . . Recv: | Recv: 1 | . . . . . . . . . . Recv: | Recv: 0 | . . . . . . . . . . Recv: 0 1 2 3 4 5 6 7 8 9 Recv: ( 1, 1) (319, 1) Recv: Recv: ok

So there is nothing wrong with my probe's consistency. Ergo, I'm reopening this issue since it does appear to be a bug. I also want to apologize to all inductive sensors for my bias in blaming them for the issue.

Tehvan commented 1 year ago

I like to be able to move Z slightly into the negative to that I can manually probe the bed if the z-offset is wrong. The bug is that leveling uses Z_MIN_POS as the zero position for the mesh. I'd love to understand the reasoning behind that decision.

define Z_MIN_POS was set to -1 previously

I set it to -2 and guess what the mesh is? Recv: Bed Topography Report: Recv: Recv: ( 1,329) (319,329) Recv: 0 1 2 3 4 5 6 7 8 9 Recv: 9 | . . . . . . . . . . Recv: | Recv: 8 | . . . . . . . . . . Recv: | Recv: 7 | . . -2.35 -2.24 -2.20 -2.18 -2.24 -2.28 . . Recv: | Recv: 6 | . . -2.24 -2.11 -2.09 -2.09 -2.10 -2.15 . . Recv: | Recv: 5 | . . -2.17 -2.08 -2.03 -2.02 -2.05 -2.09 . . Recv: | Recv: 4 | . . -2.17 -2.08 [-2.03] -2.01 -2.02 -2.07 . . Recv: | Recv: 3 | . . -2.23 -2.10 -2.08 -2.02 -2.04 -2.09 . . Recv: | Recv: 2 | . . -2.32 -2.17 -2.10 -2.09 -2.09 -2.16 . . Recv: | Recv: 1 | . . . . . . . . . . Recv: | Recv: 0 | . . . . . . . . . . Recv: 0 1 2 3 4 5 6 7 8 9 Recv: ( 1, 1) (319, 1) Recv: Recv: ok

Look familiar?

Tehvan commented 1 year ago

Looks like this is a result of sk8board's issue being ignored #23434.

Tehvan commented 1 year ago

@sk8board: You are correct that it is a bug. The manual states "Set the XYZ distance from the nozzle to the probe trigger-point." https://marlinfw.org/docs/gcode/M851.html A workaround is to set MANUAL_Z_HOME_POS 0 as per @InsanityAutomation https://github.com/MarlinFirmware/Marlin/issues/23434#issuecomment-1138743180 @descipher was confused and incorrect https://github.com/MarlinFirmware/Marlin/issues/23434#issuecomment-1046152390 https://github.com/MarlinFirmware/Marlin/issues/23434#issuecomment-1105375991

Tehvan commented 1 year ago

The relevant code appears to be here: https://github.com/MarlinFirmware/Marlin/blob/8d3142911c017b542f1b55e9d2c09b68beacadd9/Marlin/src/inc/Conditionals_post.h#L316 As per @thinkyhead https://github.com/MarlinFirmware/Marlin/issues/23434#issuecomment-1105336006 A possible fix would be #define Z_HOME_POS TERN(Z_HOME_TO_MIN, 0, Z_MAX_POS)

github-actions[bot] commented 1 year ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

Tehvan commented 1 year ago

yeah, still active. And narno2202's mention was a typo on their part.

github-actions[bot] commented 1 year ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

Tehvan commented 1 year ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

Still ongoing

github-actions[bot] commented 11 months ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

Tehvan commented 11 months ago

still

On Thu, Nov 2, 2023, 8:39 PM github-actions[bot] @.***> wrote:

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/25365#issuecomment-1791784061, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHDBXKCK33RUHFT6CXR2TY3YCRDNZAVCNFSM6AAAAAAUYOX7CGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJRG44DIMBWGE . You are receiving this because you modified the open/close state.Message ID: @.***>

github-actions[bot] commented 8 months ago

Greetings from the Marlin AutoBot! This issue has had no activity for the last 90 days. Do you still see this issue with the latest bugfix-2.1.x code? Please add a reply within 14 days or this issue will be automatically closed. To keep a confirmed issue open we can also add a "Bug: Confirmed" tag.

Disclaimer: This is an open community project with lots of activity and limited resources. The main project contributors will do a bug sweep ahead of the next release, but any skilled member of the community may jump in at any time to fix this issue. That can take a while depending on our busy lives so please be patient, and take advantage of other resources such as the MarlinFirmware Discord to help solve the issue.

Tehvan commented 8 months ago

ignoring a problem doesn't make it go away

On Sun, Feb 4, 2024, 5:40 PM github-actions[bot] @.***> wrote:

Greetings from the Marlin AutoBot! This issue has had no activity for the last 90 days. Do you still see this issue with the latest bugfix-2.1.x code? Please add a reply within 14 days or this issue will be automatically closed. To keep a confirmed issue open we can also add a "Bug: Confirmed" tag.

Disclaimer: This is an open community project with lots of activity and limited resources. The main project contributors will do a bug sweep ahead of the next release, but any skilled member of the community may jump in at any time to fix this issue. That can take a while depending on our busy lives so please be patient, and take advantage of other resources such as the MarlinFirmware Discord to help solve the issue.

— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/25365#issuecomment-1926069347, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHDBXKCK2K3AK26PX52HZP3YSA2ANAVCNFSM6AAAAAAUYOX7CGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRWGA3DSMZUG4 . You are receiving this because you modified the open/close state.Message ID: @.***>

Tehvan commented 5 months ago

Same issue here #26932

Tehvan commented 5 months ago

Same issue here #26766

ellensp commented 5 months ago

Simple question, can your hotend go below the beds surface? No? then why do you have #define Z_MIN_POS -1 saying the hotend can travel 1mm into the bed?

Presuming you did this so the probe could go below Z0, this is the wrong way to attempt to do this, it has very bad consequences.

You don't lie to the machine about its travel limits. You tell it you can exceed the minimum Z limit by disabling #define MIN_SOFTWARE_ENDSTOP_Z

Tehvan commented 5 months ago

@ellensp No, but my Z axis can and that is the parameter at issue.

I'm not lying to the machine about it's travel limits. The Z axis does travel 1mm below Z0 without damage. Why are you recommending that I disable a security feature and risk damage to my machine? I get that you deal with a LOT of stupid stuff (thank you btw) and it is easy to get into the habit of throwing out solutions and seeing if they stick. But that is not a good solution.

But speaking about lying, what about lying to users? It is a big reason why I still care about this issue after over 14 months. Why is nozzle_to_probe_offset not actually the nozzle to probe offset but rather the nozzle to travel limit offset? Do you realize that right now every time someone adjusts the springs on their bed the "nozzle to probe offset" has to be adjusted? But there is another lie to users. Please read the description on #25564 about Z_MIN_POS. I'm grateful to you and especially to @thinkyhead for Marlin, but these two lies are problems and ignoring them isn't going to make them go away. More users are, like me, going to trust those lies and then be very frustrated because bed leveling isn't working.

ellensp commented 5 months ago

You have USE_PROBE_FOR_Z_HOMING the probe always probes the bed the probe point is either level with the hotend or the probe point is lower than the hotend. the bed surface is by definition z0

you cannot have Z_MIN_POS -1 ! The hotend would be embedded into the bed

descipher commented 5 months ago

Hmmm .. confused and incorrect

InsanityAutomation commented 5 months ago

You have USE_PROBE_FOR_Z_HOMING the probe always probes the bed the probe point is either level with the hotend or the probe point is lower than the hotend. the bed surface is by definition z0

you cannot have Z_MIN_POS -1 ! The hotend would be embedded into the bed

You most certainly can, as thats somewhat like a static probe z offset always applied if not overridden with a manual z pos. In the case of older Lulzbot machines, the probe, which was the nozzle itself, actually hit raised washers above the bed. It then travels below 0 to embed the nozzle into the wiper pads on the side of the bed. You could also have the hotend itself retracted on a servo (which I recently discussed with an OEM as a standard operation to allow the probe to be mounted higher to protect from damage), or as is common with piezo electric a spring loaded compression mechanism.

I have also seen Z - values for probe dock with euclid etc but those required a separate z home switch.

On a multi tool machine, its a common to set z_min_pos below 0 then use the manual home override to set the g28 position to 0. Otherwise a tool with a negative offset will get clamped trying to adjust and this sets the limit for lower adjustment by the second head.

Ill be on a business trip next week and ill try to sit down and review everything fresh on this when im stuck sitting at the hotel. Good bit of reading to consolidate across each issue listed... Perhaps we need clearer documentation around the methods to currently deal with this uncommon but not unheard of scenario.

descipher commented 5 months ago

The challenge here is not that you can certainly use Z_MIN_POS in negative space, its that changing the current state to address the claim will break many things and the gain ratio is not good with bed leveling issues. As far as I can tell, the current state goes back to 2019, this is not a bug its a configuration mix issue. Having the probe as a Z_HOME negates the ability to move to Z_MIN_POS = -1 because homing is a reference of 0 for bed leveling!

Tehvan commented 4 months ago

Do you realize that right now every time someone adjusts the springs on their bed the "nozzle to probe offset" has to be adjusted?

I'm not sure about this statement. I don't recall my thought process and it doesn't make sense now.

JJones780 commented 4 months ago

See if the changes mentioned in my comment in #22322 help? I didn't use the bugfix code as I assumed git had progressed... got it working anyways from 2.1.2.2.

thisiskeithb commented 4 months ago

See if the changes mentioned in my comment in #22322 help? I didn't use the bugfix code as I assumed git had progressed... got it working anyways from 2.1.2.2.

@JJones780: You are using a broken version of Marlin and misconfigured your probe settings.

2.1.2.3 was just released to fix several bugs found in 2.1.2.2, but bugfix-2.1.x is a year+ ahead of both of these releases.

JJones780 commented 4 months ago

Check out my Configuration issue 1062. It may still be valid. I checked against the newer releases including 2.1.2.3 and they are all missing the #define in Configuration_adv.h . It's possible there's now a default condition in the code such that the define is no longer required? I'll have a quick look through the code...

I'm glad 2.1.2.3 fixed the other issues?... a few days late to save me hours but glad it'll save others the time! I had seen comment about the bugfix release but being a year or more old had mistakenly assumed the git release was newer.
If it was called 2.1.2.2_bugfix , or I was more awake, I might not have made that mistake.

thisiskeithb commented 4 months ago

@JJones780: Not a bug, but configuration issue / misunderstanding.

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

github-actions[bot] commented 1 month ago

Greetings from the Marlin AutoBot! This issue has had no activity for the last 90 days. Do you still see this issue with the latest bugfix-2.1.x code? Please add a reply within 14 days or this issue will be automatically closed. To keep a confirmed issue open we can also add a "Bug: Confirmed" tag.

Disclaimer: This is an open community project with lots of activity and limited resources. The main project contributors will do a bug sweep ahead of the next release, but any skilled member of the community may jump in at any time to fix this issue. That can take a while depending on our busy lives so please be patient, and take advantage of other resources such as the MarlinFirmware Discord to help solve the issue.

Tehvan commented 4 weeks ago

I would be satisfied with a simple 'hey, if you set zmin to anything but zero bed leveling won't work' comment in the config.

On Sat, Aug 31, 2024, 8:59 PM github-actions[bot] @.***> wrote:

Greetings from the Marlin AutoBot! This issue has had no activity for the last 90 days. Do you still see this issue with the latest bugfix-2.1.x code? Please add a reply within 14 days or this issue will be automatically closed. To keep a confirmed issue open we can also add a "Bug: Confirmed" tag.

Disclaimer: This is an open community project with lots of activity and limited resources. The main project contributors will do a bug sweep ahead of the next release, but any skilled member of the community may jump in at any time to fix this issue. That can take a while depending on our busy lives so please be patient, and take advantage of other resources such as the MarlinFirmware Discord to help solve the issue.

— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/25365#issuecomment-2323114047, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHDBXKARAK2TGQ43363U7Q3ZUJYIVAVCNFSM6AAAAAAUYOX7CGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRTGEYTIMBUG4 . You are receiving this because you modified the open/close state.Message ID: @.***>