[BUG] "Z-leveling enforced" during mesh bed leveling after upgrading to 3.14.0

[adamdport]

Printer model

MK3S/+

MMU model

No-MMU

Firmware versions

3.14.0

Upgrades and modifications

mosquito hotend

Printing from...

SD Card

Describe the bug

Since upgrading to 3.14.0 firmware, I'm no longer able to do mesh bed leveling. I get a "Some problem encountered, Z-leveling enforced..." error. After reading the release notes, I tried changing it from 3x3 to 7x7 and it still fails. The printer worked fine before upgrading, and downgrading back to 3.13.3 resolves the issue (mesh bed leveling works fine without any other changes).

I saw several comments (https://forum.prusa3d.com/forum/postid/717374/) in the forums about others having the same issue, but I couldn't find any github issues about it so I thought I'd create one. Thanks.

How to reproduce

Try to do mesh bed leveling, either from a print job, or even from a cold printer from the "calibration" menu

Expected behavior

mesh bed leveling succeeds

Files

No response

[StarWitch]

I'm also experiencing this error with 3.14.0, on an MK3S+.

[3d-gussner]

Did you run the Z and/or XYZ calibration? See release notes

To get the best results with this feature, it is recommended to run a Z calibration to update the default mesh information in the EEPROM. The default mesh is used outside of the probed print area and also for determining bad points that need to be rechecked.

[3d-gussner]

@adamdport As you have a mosiqutio hotend, do you use a custom build firmware? When yes which one do you use? Do you have a different extruder body?

[leptun]

@3d-gussner is correct. The printer might have old Z calibration data in the eeprom. Starting with firmware 3.14.0, we have tightened the tolerance for correctly measured points since it would be a pretty bad idea to use region MBL with old eeprom data, as there would be a misalignment between the "inside" and "outside" areas of the region MBL. We may consider relaxing the thresholds to the old values when 3x3 MBL is used as there is no "outside" area in that case, so an aligned Z gantry and valid eeprom data is less important.

Do note that starting with fw 3.14.0, the printer also informs you that you need to run Z calibration after 2 successive failed alignments of the Z gantry during MBL, which would indicate that the MBL data in eeprom needs to be updated. Instructions are provided on screen and the print is aborted in that case.

Please let us know if running Z calibration doesn't fix your issue as that would mean the thresholds are too tight even with valid eeprom data (even though during testing we haven't identified this as being a problem).

To avoid confusion regarding terms, running "Z calibration" means going to the calibration menu and clicking on "Calibrate Z". This is different to the Z gantry alignment that happens during a failed MBL probe. Z calibration also aligns the gantry, but in addition to that it also does a slow 3x3 MBL which gets saved to eeprom.

[adamdport]

@3d-gussner @leptun I do not use a custom build firmware. The release notes say "The feature is now linked to 7x7 MBL. So when the user enables 7x7 MBL, this feature also gets enabled automatically" in the paragraph preceding the "it is recommended to run a Z calibration" note. Since I do not use 7x7, I assumed it did not apply to me.

I recalibrated Z (Calibration -> Calibrate Z) and confirm that mesh bed leveling now succeeds on 3.14.0. Thanks for the help.

[leptun]

Thanks for confirming! I will bring this up to the team and most likely we will also update the release notes to fix this source of confusion.

[3d-gussner]

@adamdport Can you please consider to close this issue as it it solved?

[sinjindog]

I just upgraded to 3.14.0 on a stock MK3S+. I an unable to do mesh bed level with the new firmware. I am also unable to complete a z calibration without errors as well. Rolling back to 3.12 or 3.13 resolves the issue. & x & is enabled. It seems like the tolerances are too tight for the levelling to complete. I have had zero issues with printing over the last 2.5 years with this machine. The odd time during the 7 x 7 levelling at the start of a print the pinda may stop and take a second reading on the odd spot but I have great first layers and no other issues. Anyone else having this problem?

[leptun]

@sinjindog Please hold on for release 3.14.1. We have made some changes which should address the issues for most users. See #4765.
But your issue report confuses me somewhat. You mention that Z calibration can't pass. That sounds wrong so I'd like to rule out some potential issues:

• How were you running Z calibration? Going to "Calibration -> Z calibration"?
• Did you have the steel sheet on the bed during the Z calibration? It has to be installed (improvements for this coming in 3.14.1)
• Could the Z POM nuts be installed upside down? This is the main culprit for failed Z calibrations as the Z axis is shorter by a few mm.
• Where exactly does the Z calibration fail? During the slow probing or during the movement from top of Z to bottom of Z

[sinjindog]

Thanks for the reply: Answers are next to your questions. @sinjindog <https://github.com/sinjindog> Please hold on for release 3.14.1. We have made some changes which should address the issues for most users. See #4765 <#4765>. But your issue report confuses me somewhat. You mention that Z calibration can't pass. That sounds wrong so I'd like to rule out some potential issues: - How were you running Z calibration? Going to "Calibration -> Z calibration"? Yes. - Did you have the steel sheet on the bed during the Z calibration? It has to be installed (improvements for this coming in 3.14.1) Yes, tried with steel sheet, satin sheet and textured sheet - Could the Z POM nuts be installed upside down? This is the main culprit for failed Z calibrations as the Z axis is shorter by a few mm. Factory built printer with nuts instal;led correctly. - Where exactly does the Z calibration fail? During the slow probing or during the movement from top of Z to bottom of Z Not sure exactly what you are asking but will expand below... To add a little more information the printer is a 2.5 year old factory built one with 357 days, 11 hours and 22 mins of print time. The printer has gone through many nozzles and many z calibrations and I have never had a calibration or mesh level fail until firmware 3.14.0. I always have great first layers and have no other issues with the printer. I was running firmware 3.12.xx without issue and received an email about 3.14.0 the other day from your mailing list and thought I would give it a try. I proceeded to install 3.14.0 and tried to print a benchy sliced in Prusaslicer 2.8.0. The printer started as normal and started probing the new smaller area as expected for leveling. After it had probed 3 spots the printer then gave an error, and the z axis moved all the way to the top of the gantry and then all the way back down and continued probing another few spots. Then it said that "some error had occurred" and gave a failure message related to z- leveling enforced.. Sorry I didn't take a picture so don't have the exact message. If it happens again I will copy it for you. I tried to print the iterm again and it failed again but after probing the 6th or seventh spot and the same action of the z axis going all the way to the top happened again. I did a google search and found a few people in the forums with the same issue that were unable to resolve it and then one message referring to github. The github issue seemed to be resolved by forcing a new z calibration. So I went into the calibration menu and selected z calibration as I have done many times before. The calibration started as normal using my previous value of -1.053. About half way through the probing for the calibration again there was an error message and the z axis moved all the way to the top and then back down. It then continued and did this two or three more times. Once the probing finished the printer then just stopped and said some error had occurred again. Sorry I didn't write it down, will do next time. I then proceeded to delete the values for all three sheets, smooth, textured and satin that were in memeory as the github message mentioned that the eeprom values may be off. I then tried to do a z calibration again and the same issue occurred but it happened at different probing spots. After four or five more tries I gave up and tried firmware 3.13.xx. As i now had no z height value saved I ran the z calibration again and had no issues. I then proceeded to load up a few newley sliced gcode files including the one I wa testing 3.14.0 with and printed for a total of about 25 hours without further issue. I will try 3.14.1 when I get a chance and report back. Thanks for your questions.

…

On Fri, Sep 20, 2024 at 12:36 AM Alex Voinea ***@***.***> wrote: @sinjindog <https://github.com/sinjindog> Please hold on for release 3.14.1. We have made some changes which should address the issues for most users. See #4765 <#4765>. But your issue report confuses me somewhat. You mention that Z calibration can't pass. That sounds wrong so I'd like to rule out some potential issues: - How were you running Z calibration? Going to "Calibration -> Z calibration"? - Did you have the steel sheet on the bed during the Z calibration? It has to be installed (improvements for this coming in 3.14.1) - Could the Z POM nuts be installed upside down? This is the main culprit for failed Z calibrations as the Z axis is shorter by a few mm. - Where exactly does the Z calibration fail? During the slow probing or during the movement from top of Z to bottom of Z — Reply to this email directly, view it on GitHub <#4762 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLMZZ3APTTZKQAFLXIWANMDZXO67DAVCNFSM6AAAAABNIZEUVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRSHEZTQNJYGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[leptun]

So I went into the calibration menu and
selected z calibration as I have done many times before. The calibration
started as normal using my previous value of -1.053

This sounds to me like the "First layer calibration" which is used to calibrate the Z offset of the probe. That is unrelated to the Z calibration that is the fix for this particular issue.
This is the calibration that the error message instructed you to run:

Please try running this instead and see if the issue is resolved. Running the first layer calibration does NOT update the eeprom mesh, so this is what should be run instead.

Also, so that we may address what caused this confusion, are you using any translation of the firmware? It may be that the wording of the error message in a translation is problematic and confuses the user.

[sinjindog]

I actually did both the first layer calibration and also the z calibration. Sorry for the vague descriptions. I kind of tried everything I could find.

…

On Sun, Sep 22, 2024, 11:35 Alex Voinea ***@***.***> wrote: So I went into the calibration menu and selected z calibration as I have done many times before. The calibration started as normal using my previous value of -1.053 This sounds to me like the "First layer calibration" which is used to calibrate the Z offset of the probe. That is unrelated to the Z calibration that is the fix for this particular issue. This is the calibration that the error message instructed you to run: image.png (view on web) <https://github.com/user-attachments/assets/ef748a18-7151-4320-9431-9b1486b2d037> Please try running this instead and see if the issue is resolved. Running the first layer calibration does NOT update the eeprom mesh, so this is what should be run instead. Also, so that we may address what caused this confusion, are you using any translation of the firmware? It may be that the wording of the error message in a translation is problematic and confuses the user. — Reply to this email directly, view it on GitHub <#4762 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLMZZ3D4VLMMT3W4BT7AJLLZX35W7AVCNFSM6AAAAABNIZEUVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRWHA4DKNJYGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[leptun]

Did you first run Z calibration first and then First layer cal or the other way around?

[sinjindog]

Z calibration first then first layer calibration. The first layer calibration carried over from the last firmware 3.12.x

…

On Sun, Sep 22, 2024, 11:41 Alex Voinea ***@***.***> wrote: Did you first run Z calibration first and then First layer cal or the other way around? — Reply to this email directly, view it on GitHub <#4762 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLMZZ3GCTL57RH773DGSO2DZX36L7AVCNFSM6AAAAABNIZEUVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRWHA4DOOBVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gasrovescio]

I own 2 MK3s+ and I had to go back to the previous firmware because they both have the "leveling" problem.

[gasrovescio]

I don't understand why the error is not detected right away but halfway through the leveling especially in the middle of the plate. I tried to reset, recalibrate everything with Wizard and do the Z calibration and the first layer .

[leptun]

The mesh that is saved in eeprom (the one that is measured during Z calibration) is compared to what is currently being probed during Mesh bed leveling (G80). These two meshes are aligned by the Z home position which is close to the bottom left most point. So if the calibration data does not match the measured points it will trigger further away from that area where the two are aligned.
I've further relaxed also the 7x7 thresholds for 3.14.1 to avoid this kind of issue in the future and the 3x3 thresholds have been reverted to the old values from 3.13

[thornygravy]

awesome, having this problem as well

[gasrovescio]

I find the problem solved in firmware 3.14, I have reset the layer grid to 3X3 instead of 7X7! it is not a definitive solution, also because in very large or numerous prints this can lead to problems with a homogeneous first layer or detachment from the plate.

[leptun]

@thornygravy @gasrovescio Please hold on for fw 3.14.1. It is currently in testing and it should resolve this issue for both 3x3 and 7x7.

[SleepyDogSoftware]

Did 3.14.1. ever get released? The website still show 3.14.0