[BUG] Incorrect offset applied to Bed level mesh when using a fixed Home Switch/Z stop and seperate level probe.

[Maker-Paul]

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

Yes, and the problem still exists.

Bug Description

When using a fixed stop for homing connected to default Z min and a probe connected to the default separate probe connector.

The bed level mesh is created relative to the fixed Z0 and therefore an unwanted offset between the fixed Z0 and the probe Z0 is added to the mesh values. This offset can be compensated for by setting a probe Z offset, but this offset is then inappropriately applied to the fixed Z stop/Homing switch when homing and therefore has to be removed for subsequent homing. Z values on the status screen are therefore very confusing.

I have included modified files in the upload section below as a possible fix. The readme file details the line numbers in the files where code has been added or changed. Hope this helps. Last upload of updated files 20th Feb 2025.

Bug Timeline

Not sure

Expected behavior

The probe should be used to establish the Probe Z0 reference for the purpose of creating the mesh points (the same as when only a probe exists and has been used to home)
Optional When a fixed Z stop/Home switch is used a probe offset is not needed as the nozzle offset is actually relative to the fixed stop so the menu option setting a probe Z offset could be removed and it would be more logical to enable the Z bed offset that is present in the menu when only a fixed stop is used.

Please note using just a Z stop or just using a probe both work as expected.

Actual behavior

I have to find the offset between the fixed Z Stop/Home switch and the Probe Z0. Then enter that value as a Z probe offset before I run a bed level. store the mesh and set the probe Z offset back to 0, then home the machine as a workaround way to set it up. I have enable bed leveling after homing enabled.
Because a Fixed Z stop/Home switch to probe Z0 is not a recognized offset the numbers can get very confusing.

Steps to Reproduce

1. Fit a fixed Z Stop and separate Level probe each connected to their respective default connectors
2. // #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and // #define USE_PROBE_FOR_Z_HOMING are both disabled
3. set the fixed Z stop switch physically to match the nozzle to bed paper pinch test. (this will mean the Fixed Z stop 0 to Probe Z 0 offset will be the same as the Z probe to nozzle offset or as near as)
4. If you run a bed level at this point and inspect the values you will see they are large.
5. run a Z offset wizard or enter the Z offset and then run a bed level.
6. save the results
7. set the probe Z offset back to 0 and save settings (No offset is needed with a fixed Home Z0 switch)
8. Home the machine. Enable the stored bed level mesh if not set to automatically restore it.

Version of Marlin Firmware

Latest Bugfix 2.1.x

Printer model

Tronxy XY2 Pro

Electronics

Stock

LCD/Controller

Stock

Other add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configuration.zip

PaulsBugfix.zip

Readme.txt

[borland1]

Maker-Paul,

Why are you using a mechanical limit switch for the Z-axis when your Z-probe can perform the same function?

[Maker-Paul]

Because a proximity probe though good for creating a level mesh varies with environmental changes and takes up to 30 minutes to stabilize after switch on (as it warms up). So its good for creating a level mesh but not good for setting a Z zero reference. A fixed Z stop will give a perfectly stable and repeatable Z zero reference but does nothing else. Horses for courses. As the machine can support both I prefer to have a dedicated sensor doing the job its best at and not having to accept a compromise. I can use my machine day after day simply by telling it to print without having to redo Z offsets. In fact I won't have to enter a Z offset at all (if the bug is fixed).

…

On Mon, 10 Feb 2025, 19:12 borland1, ***@***.***> wrote: Maker-Paul, Why are you using a mechanical limit switch for the Z-axis when your Z-probe can perform the same function? — Reply to this email directly, view it on GitHub <#27680 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMBPEPK5RXA3TYC5I5PDMST2PD23FAVCNFSM6AAAAABWY6AOMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBYHE4TEMJXHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Maker-Paul]

I have successfully edited G29.cpp to correct the error at least for ABL Bilinear mesh. It only required 4 lines of code and 1 line edited to make it work. I have edited config.h by adding a new compiler directive to enable my changes called USE_PROBE_FOR_MESH_REF.

As I don't use git and have definitely not extensively tested it, I am not going to be so presumptuous as to try and submit the code officially as a fix. But I am more than happy to let any Marlin developer have the file as it will at least provide a method.

My printer now does perfect first layers every time simply by selecting the file to print. Homing is part of the print file custom Gcode and restore level after homing is enabled in config.h.

Re-leveling is only required after physical adjustments and as the frame mounted Z end-stop/Homing switch provides a real Z zero homing point there is no need of any probe z offset or offset wizards. I am using an adjustable mount for the frame mounted Z end-stop/Homing switch which allows better than 0.01mm adjustments for setting the switch physical position so the nozzle just pinches a piece of paper when homing. Assisted tramming still works as it should..

[Maker-Paul]

Glad you got it working.

Mechanical limit switches are generally less accurate than a capacitive or inductive probes, however the homing accuracy is more limited by a combination of the lead screw thread pitch and your Z-axis stepper motor's micro-stepping resolution (1/16 stepping vs. 1/256 stepping).

It's easier to adjust the Z-offset, than a mechanical Z-axis limit switch, when adjusting the print's first layer squish. You might run some test prints using a first layer mesh test print, to see if you have your mesh properly dialed in. I am more familiar with Cura Slicer, but Prusa Slicer might also have similar built-in tools for generating single layer mesh test print files.

Since you XY2 Pro is a bed slinger, you might want consider replacing the factory bed springs, with similar, but thicker springs (higher spring constant). The weak stock springs tend to loosen up from constant vibrations as print time accumulates. Also smaller diameter thumb screws are less likely to get accidentally bumped out of any proper adjustment.

Hi Borland1. I do feel a bit like I'm having to defend this. I have to disagree with almost every assertion you have made but I'm glad at the same time that your interested.

Even a cheap mechanical limit switch can certainly achieve a repeatability better that 0.01mm. Its the repeatability that matters in this application because what we are interested in is the relative position to other components in this case the nozzle. So it doesn't matter whether the measurement is mm, inches, standard cabbages or a piece of paper. As I have already said my switch is mounted on an adjustable mount that lets me adjust its position relative to the bed just by turning a thumb wheel with a resolution of 0.5mm per revolution. It takes a minute to literally dial in the Home position using the paper pinch test. Once it is set it stays set day in day out. Of course I could use a higher quality switch or optical trigger that would be highly accurate, is easily available and also cheap but I haven't found that to be necessary. As for the mechanical accuracy of lead screws and micro stepping resolution, these are both outside the remit of this modification or the bugfix and have been addressed separately on my machines.

A proximity sensor which may have a higher resolution, which is what I think your confusing with accuracy., but has appalling long term repeatability. My proximity sensors trigger point varies by up to 2mm depending on temperature. That doesn't matter for comparative measurements where all the reading are gathered within a short enough time that the environment cant have significantly changed. A proximity sensor will only give accurate repeatability once it has settled but not during the first half hour of being switched on and not from day to day.. So creating a mesh is fine, but will my home position be the same tomorrow morning as it is at 4oc in the afternoon. I can guarantee it won't be. That is why so many people constantly have to reset the Z offset every time before they start a new print. As my firmware modification/bug fix means the unwanted fixed Z/Home switch to probe offset is measured as the first thing a bed level routine does the unwanted offset is taken off the mesh values with the same accuracy as the mesh measurements themselves. the result is that my machines home position on the status screen with the mesh applied is Z 0. The produced mesh has values both slightly above and slightly below zero with a range of about 0.2 mm as would be expected from a PEI sheet on a magnetic base with a warped hot plate. The fix doesn't change the relative values of the mesh points to each other as the same value is applied to all points. All it does is move the mesh down to the zero plane.

It is not easier to drill down menu options to adjust a Z offset than it is to move a thumb wheel by 1 notch. especially when having the homing switch set properly eliminates the need to ever have to set a Z offset either with the wizard or any other method allowing the menu options to be simplified and the status screen to show the actual Z value. I have enabled a Bed Z menu option to allow the Fixed Z stop/Home switch to be deliberately set a little above the bed if wanted. the extra clearance allows homing and bed leveling to keep the nozzle clear of the bed even if there is a bit of set oozed plastic. the bed Z setting does the same as it does when there is only a fixed Z stop. As it is an offset between the fixed Z stop and the bed it doesn't change with environmental changes. In practice I haven't found the Bed Z option necessary as setting the Fixed Z stop using the paper pinch test works perfectly well and I'm pretty good at making sure my nozzle is clean before I home or level.

I have of course carried out many first layer mesh test prints. I am now at the point where I can deliberately adjust my bed level, set the home position, run a bed level and do a mesh test print without any further adjustments and its perfect every time, even with the bed badly out of tram.

I have three XY2 Pros all highly modified including bed springs. I started experimenting with using separate Z stop and probe 5 years ago but because of the restrictions of proprietary firmware the only way I could implement it was with a physical switch to change between them. The result was stable machines that would work for weeks without having to mess with them but they were not easy to set up. This latest machine (I picked up two wrecks for £30 on the local buy and sell) is as easy to use as the most expensive consumer grade machines (Bamboo Labs) Easy to set up! Stays set! Thanks to Marlin finally bringing it together (all be it I have had to bug fix it myself at the moment) This set up is as close as it gets to true automatic bed leveling and much better than the Sunlu I have with a BL touch

Pros
Cheap readily available components, will work on any board with at least 1 unused end stop socket, easy to implement (with the bug fixed firmware). doesn't require a fast mother board. brings any machine as close as possible to the elusive promise of ABL.
cons
Not widely accepted as many people perceive a proximity sensor to be an upgrade and resist the idea of fitting a mechanical switch as being somehow a retrograde step, even though each excels in its own role.

Pros and cons of other alternatives
BL touch and clones :- Roughly the same mechanical accuracy as my solution, Not affected by environment changes, mechanically complex, prone to damage, expensive, difficult to implement as a non stock upgrade on many machines.

Bed distance sensor :- (This is the future) Should be environmentally stable but I haven't tested it. Still requires a Z offset but should stay set. compensates for state of the bed in real time so no mesh, requires a capable fast mother board, expensive at the moment, complex to implement as a non stock upgrade.

I really do feel I have the best easily implemented solution to a problem that plagues so many 3D printer users. Its affordable easy to install and simplifies the operation of existing machines even for non enthusiast operators.

[thinkyhead]

When a Z endstop is not perfectly aligned to the Z0 position, there is the option to use the M206 Z Home Offset position, or if the Z endstop is at a known fixed position relative to the bed, the Z_MIN_POS and/or MANUAL_Z_HOME_POS can be set to that known position.

There may be some shortcomings to M206 (cc: @InsanityAutomation) and to homing and leveling in general, and we will definitely be revisiting the overall UX for setup and calibration following the release of 2.1.3. That will include a single Z offset that applies to the ABL mesh and is automatically calibrated from the mesh results to minimize distortions in the print when using Leveling Z Fade.

Try experimenting with M206 to see whether it has the effect you are looking for, and with adjusting your Z_MIN_POS and/or MANUAL_Z_HOME_POS, and we can continue discussion here whether the existing features are sufficient. I'm not sure if we'll need the workaround exactly as proposed by #27714, but it could point to some corrections we need to make to the existing features to make them more consistent.

[Maker-Paul]

 Thank you Scott for taking the time to look at this.   

For clarity the bug only affects a use case where both a proximity probe and fixed stop are used together. I have carried out over 300 firmware updates testing all the available combinations of config.h setting and code modifications to confirm and "fix?" the bug. Frankly I'm shocked my main board, so far, hasn't just bricked itself.

I think there are 3 things to consider . It's a deep rabbit hole so I have tried to separate the actual bug from the other issues.

1. The Bug...... I am as certain as I can be that the original programmer's didn't intend the difference between the Z stop position and the trigger height of the probe to be added on to all the mesh values. As you pointed out in an ideal machine the Z stop would align with Z zero but in practice it may well have its own offset to Z zero, making that difference even more complicated to understand. Using any of the available config options to try and compensate also affects the true home position set by the fixed stop, producing Z values on the status screen that are very difficult to understand. The only solution that worked was to either quantify that difference and take it off or not add that erroneous difference in the first place effectively making G29 work as if there is only a probe used for both homing and creating a level mesh. In the end I found the simplest solution was to not add it on in the first place, as that doesn't add any further distortion caused by floating point rounding when calculating values to compensate.
2. The UX..... There are as you have said inconsistencies with the Z offset being referred to as "Probe Z offset" and "Bed Z" in different menu's options. I presume that this was to try to include some descriptive reference to the device used for homing in each case. Most users will use the term "The Z offset" as the only Z offset, for the purposes of printing, is the distance between the nozzle and the Z zero plane (Bed). For the User interface all menu options could be called either Home Z offset or Nozzle Z offset. I used the predefined title "Home Z offset" in my alternative menu option because it is generic.
3. The Code.... This is where the rabbit hole gets deep. I found that apart from the user interface using different titles for Z offset setting. The code I looked at uses at least four different named variables to apply offset values across the different leveling modes. I think from looking at the code there are nuances between different parts that indicate the code may have been written by different people at different times with subtle differences in approach. This adds massive complexity to any code alteration. For someone on the outside like me, who also doesn't have the historical familiarity with the code it makes it very difficult to reverse engineer.

I would love to help if I can and if you think it would be of use. But can I ask you, with your lead developer hat on, is there any written specification or guides for how specific parts of the code is meant to work or any partnering scheme where I can ask someone who knows answers to relevant questions about the internal function of the code. I followed your previous advice to use discord and that was where someone suggested I should create my own fork and submit a pull request. So this is the first time I have cloned a repository and used git (another big learning curve) so I apologize if I have made any mistakes. Unfortunately I found that on Discord and worse Facebook I can't tell if comment is coming from a well meaning end user with an opinion, or a developer with intimate knowledge. Discord and Facebook both invite well meaning end users to comment and start a debate about the virtues of the Bl-touch.
I'm asking this because for example. In principle I can't think of any good reason to store anything but the bed variations in the level mesh. So I would expect the mesh to only have values slightly above or below the mesh Z zero. Then I thought maybe its done because doing several calculations to compensate for Z offset, Z zero position or mesh variations inside the main loop would have disastrous timing consequences gobbling up machine cycles. So adding all the once only values together before printing starts and doing only one calculation in the main loop would make sense.. If that is what's happening then the mesh is doubling up as a sort of buffer for other values. A question like "Is that how the code is meant to work" is a question that's just to deep for discord or Facebook.

Once again Scott thank you for all you do. I have no idea how you can keep on top of something so complex that covers such a diverse range of machines.

Regards Paul

[thinkyhead]

I'm not sure of anyone's made a video on all the details of homing and leveling and probe calibration, so we just might have to make it ourselves. In the meantime I'll just go over the theory and basics here to make sure all the bases are covered and we have a map of how to proceed. Maybe we can feed this to Copilot to get some helpful hallucinations….

In the most basic form, when the Z endstop is not at exactly 0 we have offsets to specify what the homed Z position actually is. Endstops are notoriously imprecise compared to probes, and since bed probing is also in relation to the probe, not using the probe for homing is an invitation to cumulative errors, especially in setups that require periodic tramming, and those with beds that expand and change shape significantly when heated.

Of course, we want to make it possible for the corrected Z home position to be set for the Z endstop so that Z0 aligns as closely as possible with with the "most representative height" of the bed surface. This is generally the Z0 as measured in the center of the bed, though this varies from bed to bed.

And of course we also want to allow for a generally-adjustable M206 Z that works for a variety of common cases and does the "right thing" as it is changed. It is meant to be the lowest level adustment at the hardware level to account for the off-position of the Z endstop and nothing more.

You should find after G28 that you can move the nozzle over to the center of the bed and then down to Z0 and it should just touch the bed. Is that is the case?

• If so then everything is set, and now you just need to calibrate your M851 Z value.
• If not, then we need to look at G28 before we look at anything else.

To calibrate M851 Z you should heat up the bed and use the Z Probe Offset Wizard for best results. This ensures that the probe offset is at its most accurate. You may also want to run the X Axis Twist Compensation if there is any chance the X gantry might be off, or if the probe might not be aligned perpendicular to the bed throughout the probing process. Eliminating these mechanical factors is essential to getting a smallest-magnitude mesh centered closely around zero. (Once we have a global Z offset added to the ABL Bilinear mesh in a future version of Marlin the magnitudes will be minimized automatically.)

---

Let's get a log of what you see in the course of doing the stuff above so we can analyze the output…

• Download Marlin bugfix-2.1.x to test with the latest code.
• Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
• Connect to your printer from host software such as Cura, Printrun or Repetier Host.
• Send M502 and M500 to ensure your default Configurations are applied.
• Test Procedure:
  • Reboot the machine.
  • Issue the command M111 S247 to enable maximum logging.
  • Perform a G28 to do your standard homing procedure.
  • Do a G29 to probe the bed. This will also enable bed leveling.
  • Do Tramming, Probe Z Offset calibration, etc., save with M500, and
    repeat these steps so we can compare results before and after.
• Completion:
  • Do any other moves or commands needed to reveal problems. Take notes.
  • Copy the log output into a .TXT file and attach it to your next reply.

From the log file we should hopefully get a better idea of what's going on with our Z offsets and endstops maths, we can compare with the solution in your PR, and hopefully fix a fundamental aspect of the machine geometry.

[Maker-Paul]

Hi Scot please find attached test results. I am sure experienced Marlin developers can come up with a more elegant piece of code so I wont be at all put out if my proposal only serves as a pointer. If it is of use there are a couple of short comings. I haven't made any attempt to store my "Home Z offset" value so what value was applied to the mesh can show in the menu option across reboots. I haven't attempted to rewrite the "Z offset wizard" to work appropriately with my "Home Z offset" value. Apart from that, when the fix is applied, all the other config,h options like Z_MIN_POSITION work as normal.

Notes.and.overview.txt

Z-stop_and_and_probe-no-fix-Debug.txt