Marlin
Marlin copied to clipboard
MarlinFirmware
[BUG] (Soft Endstop (Z_MIN_POS) for Z axis interfers with (NOZZLE_TO_PROBE_OFFSET) Z)
Did you test the latest bugfix-2.0.x code?
Yes, and the problem still exists.
Bug Description
Changing Soft Endstop Z_MIN_POS in Configuration.h affects NOZZLE_TO_PROBE_OFFSET for the Z axis.
Bug Timeline
2.0.9.3 December 30, 2021
Expected behavior
I expect NOZZLE_TO_PROBE_OFFSET will not change when changing Soft Endstop Z_MIN_POS.
Actual behavior
When Soft Endstop Z_MIN_POS is changed, then NOZZLE_TO_PROBE_OFFSET needs to be incrementally changed by the same amount.
Steps to Reproduce
Trial 1
Configuration.h #define Z_MIN_POS 0
G code entered in Octoprint Terminal M502 M500 M851 Z0 M211 S0; turn off soft endstop G28 M500 M501 M851; Terminal shows NOZZLE_TO_PROBE_OFFSET { 25.0, 27.1, 0 } M211; Terminal shows Soft Endstop (Z_MIN_POS) Min: X0.00 Y0.00 Z0.00 Max: X300.00 Y295.00 Z300.00
Result: the measured offset from bltouch probe to nozzle is -2.0mm (which is expected)
Trial 2
Configuration.h #define Z_MIN_POS 2
G code entered in Octoprint Terminal M502 M500 M851 Z0 M211 S0; turn off soft endstop G28 M500 M501 M851; Shows NOZZLE_TO_PROBE_OFFSET { 25.0, 27.1, 0 } M211; Shows Soft Endstop (Z_MIN_POS) Min: X0.00 Y0.00 Z2.00 Max: X300.00 Y295.00 Z300.00
Result: the measured offset from bltouch probe to nozzle is 0.0mm (expected measured to be -2.0mm)
Trail 3
Configuration.h #define Z_MIN_POS -5
G code entered in Octoprint Terminal M502 M500 M851 Z0 M211 S0; turn off soft endstop G28 M500 M501 M851; Shows NOZZLE_TO_PROBE_OFFSET { 25.0, 27.1, 0 } M211; Shows Soft Endstop (Z_MIN_POS) Min: X0.00 Y0.00 Z-5.00 Max: X300.00 Y295.00 Z300.00
Result: the measured offset from bltouch probe to nozzle is -7.0mm (expected measured to be -2.0mm)
Summary Z_MIN_POS = 0 and NOZZLE_TO_PROBE_OFFSET = 0, the measured offset from bltouch probe to nozzle is -2.0mm (which is expected) Z_MIN_POS = +2 and NOZZLE_TO_PROBE_OFFSET = 0, the measured offset from bltouch probe to nozzle is 0.0mm (expected measured to be -2.0mm) Z_MIN_POS = -5 and NOZZLE_TO_PROBE_OFFSET = 0, the measured offset from bltouch probe to nozzle is -7.0mm (expected measured to be -2.0mm)
Version of Marlin Firmware
2.0.9.3
Printer model
Two Trees Sapphire Plus
Electronics
Stock MKS Robin Nano V1.2 (mks_robin_nano35)
Add-ons
No response
Bed Leveling
No Bed Leveling
Your Slicer
No response
Host Software
OctoPrint
Additional information & file uploads
No response
I have changed Z_PROBE_LOW_POINT to -10 and performed the same test again. The result was the same. Changing Z_PROBE_LOW_POINT to -10 did not change the result.
I believe my testing shows there is a bug. When Soft Endstop Z_MIN_POS is not zero, then NOZZLE_TO_PROBE_OFFSET needs to be incrementally changed by the same amount.
I assume Z_MIN_POS should not affect NOZZLE_TO_PROBE_OFFSET. If my assumption is incorrect, then I have confirmed a bug.
What is the purpose for setting z_min_pos other than zero? I would think the offset works correctly here but setting z_min_pos to something other than zero seems very strange. In each case you have a z-probe offset of 0 If you set the physical location to -5 then the probe will need to move to -5 to touch where the physical layer is. The hotend would be @ 0mm above the physical plane in this case. The actual distance between the probe and the hotend are equal if the offset is zero. If the probe is not actually at 0 then the difference on contact with the plane is the offset.
What is the purpose for setting z_min_pos other than zero?
Here is what the Marlin configuration definition states:
Usually the [XYZ]_MIN_POS values are set to 0, because endstops are positioned at the bed limits.
The word "Usually" indicates there are use cases to have a Z_MIN_POS other than zero. The fact that developers went thru the work to createZ_MIN_POS also indicates there is a use case they were considering.
@thinkyhead here is another person experiencing this same bug. Should the bug tag be added to this issue?
issue #23796
@thisiskeithb since another person is experiencing the same bug, should this bug be considered verified?
The fact that developers went thru the work to create
Z_MIN_POSalso indicates there is a use case they were considering.
Developers like me? Not necessarily. Go back to Marlin 1.0.0 and there isn't much to indicate any intent or use case. I struggle to come up with one off the top of my head….
It sounds like we should simply use 0 in some places where Z_MIN_POS is now being used. Hopefully someone digs into the code to fix it up so that Z_MIN_POS can be whatever is preferred. But, we may end up needing to assert that Z0 (native machine space) is where the bed is found.
Result: the measured offset from bltouch probe to nozzle is
Where is the "measured offset" coming from? Are you referring to the Z Probe Offset Wizard?
Z_MIN_POS can be useful to allow a nozzle below Z in cases where a wiper pad is installed off the bed to the side, parking or probe/tool stowing and other considerations. Its likely that in the case where the Z_MIN is not 0, you also want a manual home position defined, especially if homing with a probe that is reading the bed.
Yes, Z_MIN_POS could be used as mentioned. But obviously the code never was written that way. In this case the OP implies the offset is no longer correct when Z_MIN_POS is set to a negative value. That is not correct. The Z probe offset is clearly the distance between the probe and nozzle surface contact and not the value of the Z_MIN_POS define. The code would need changes to work correctly with a negative value. The implied intent is not a bug it’s an FR.
But obviously the code never was written that way. In this case the OP implies the offset is no longer correct when Z_MIN_POS is set to a negative value.
If what you are stating is the intent, then please update the definition of Z_MIN_POS to show the value should never be negative. If I would have known that up front, I would have saved many hours of chasing my tail to discover the value does not work when negative.
https://marlinfw.org/docs/configuration/configuration.html
Thank you for your hard work with making Marlin what it is.
@thinkyhead @descipher
But obviously the code never was written that way. In this case the OP implies the offset is no longer correct when Z_MIN_POS is set to a negative value.
If what you are stating is the intent, then please update the definition of Z_MIN_POS to show the value should never be negative. If I would have known that up front, I would have saved many hours of chasing my tail to discover the value does not work when negative.
https://marlinfw.org/docs/configuration/configuration.html
Thank you for your hard work with making Marlin what it is.
On idex systems, a value below 0 is actually required in conjunction with a manual home position in order to allow tool offsets to function.
Are there any slicers that generate gcode for a negative Z plane?
No, it came about a couple years ago when it was more strictly enforced, and prevented the tool offset shift when bringing the second tool below 0 prior to a coordinate shift. The workaround was to set z min to -3 and manual home to 0 giving a 3mm tool tolerance.
No probe involved, so yes you could that. I can think of other ways to address a tool alignment problem but I suspect it's more a design issue.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Maybe I have the same issue, but I'm not sure. I'm currently trying to find out why the z-offset wizard does not lower the nozzle to the point where the probe touches the surface.
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.
@thinkyhead @descipher
I can understand that making a change to support a negative value for Z_MIN_POS is not desirable. If that is the case, then please update the definition of Z_MIN_POS to show Z_MIN_POS should not be negative.
https://marlinfw.org/docs/configuration/configuration.html#movement-bounds
Simply adding a sentence (as shown in bold below) can save a user an enormous amount of troubleshooting time.
These values specify the physical limits of the machine. Usually the [XYZ]_MIN_POS values are set to 0, because endstops are positioned at the bed limits. Z_MIN_POS should never have a negative value. [XYZ]MAX_POS should be set to the farthest reachable point. By default, these are used as your homing positions as well. However, the MANUAL[XYZ]_HOME_POS options can be used to override these, if needed.
I appreciate your support.
@thinkyhead @descipher
I can understand that making a change to support a negative value for Z_MIN_POS is not desirable. If that is the case, then please update the definition of Z_MIN_POS to show Z_MIN_POS should not be negative.
https://marlinfw.org/docs/configuration/configuration.html#movement-bounds
Simply adding a sentence (as shown in bold below) can save a user an enormous amount of troubleshooting time.
These values specify the physical limits of the machine. Usually the [XYZ]_MIN_POS values are set to 0, because endstops are positioned at the bed limits. Z_MIN_POS should never have a negative value. [XYZ]MAX_POS should be set to the farthest reachable point. By default, these are used as your homing positions as well. However, the MANUAL[XYZ]_HOME_POS options can be used to override these, if needed.
I appreciate your support.
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.
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.