Prusa-firmware: MK2.5 - firmware 3.5.1 - Some problem encountered, Z-leveling enforced

[FormerLurker]

I've been reading about this issue with the MK3 and the previous firmware. However, my problems started after updating to V3.5.1.

I've been doing many small prints (1-2 hours) and several will complete without issue. Eventually I'll get this error message about "Some problem encountered, Z-leveling enforced" and I'll have to go through z leveling. Sometimes that fails 2 or 3 times. After I get the first message I'll get the error on nearly every print (sometimes multiple times) until I reboot the printer.

At first I thought this was a problem with my bed position or pinda adjustment, but the fact that it works so well for so long, then fails predictably indicates to me that this is likely a software problem.

Is there any data I can provide that would assist, or any tests I should run that could help pin down the issue? If so I'll gladly provide it.

Thanks!

[jhoblitt]

Are you absolutely sure that there print surface is [reasonably] flat? I would try loosening then retightening the screws in the heated bed assembly, making sure the heated bed is clean and making sure that the underside of the steel print sheet is also clean. I seen the infinite z-calibration triggered by even having the steel sheet being lifted slightly in one corner against the alignment pins.

[FormerLurker]

Thank you for your response!

The spring steel is definitely in place, and for the last round of parts I never removed it. If it were misaligned I wouldn't expect restarting the printer to fix the issue so reliably, but then again I haven't reviewed the code for this feature.

I will double check the entire Y axis as you suggest and more, and I will report back with my findings. I plan on giving it a thorough review, so it may take me a few days.

[jtnyansa]

So this also happens to me - I have isolated it to when I stop a print and then print again from SD. The extruder does not home to the left all the way and it starts matrix checking from the middle of the bed. I can reset this by powering down and manually moving the extruder to the left.

Happens all the time when I have a failed print.

[FormerLurker]

Ok, here is what I did to test the issue:

1. Removed heated bed, check for alignment, ease of motion. I slightly adjusted the position of the belt, but everything looked pretty good.
2. Re-attach bed. Loosely tighten all bed screws, then tighten them all the way one at a time.
3. Clean under steel spring sheet. That sucker is clean as can be!
4. Clean steel spring sheet. It is also very clean.
5. Make sure the bed is firmly attached (no wobble at all, it's down and solid).
6. Run XYZ calibration twice just to see if it would fail as Z leveling does. No problems, axis were parallel.
7. Adjust live Z, it's good enough!
8. Double check that the spring steel is down 100%, not caught on the screws in the back, and is parallel with the bed. It definitely was.
9. Attempt to print, the first one I tried failed during z leveling. Had to retry 3 times.
10. Reboot. First z level worked and print completed.
11. Remove and re-attach spring steel (in case I goofed in step 8).
12. Try another print. Z level failed, but worked after the first retry.

I tried several prints after step 12 above. Sometimes it completes, sometimes it fails. It seems to usually fail when the X axis is closer to the left size of the bed (where X=0). I am not sure what this means. I can't feel anything different about the left edge of either the X axis or the bed.

If it gave some indication of why it failed perhaps I could correct the problem. I will downgrade the firmware and retest if it would help, but only if it will help get to the bottom of things. This has been a time consuming project and I don't want to try things for no good reason. Please advise.

@jtnyansa, your issue sounds a bit different than mine. My printer looks to be performing mesh bed leveling properly, but fails for unknown reasons. Also, I have been printing via serial port (which makes me think I should try from SD and see if it's any different). You should probably create a new issue for your problem if you haven't already.

Thanks!

[lachesis]

I am experiencing a very similar situation to FormerLurker. Whenever I try to print on 3.5.2, I get the "Some problem encountered, Z-leveling enforced ..." error, then I am sent through multiple Z leveling attempts, always failing at the 4th point (middle Y, right X). An XYZ calibration claims my axes are perpendicular, and Z calibration always succeeds when run manually from the menus. I do not experience any issues on 3.4.0, but that is unsurprising as this error message was added in 3.5.0. As far as I can tell, you must hit one of these break conditions to hit that error:
https://github.com/prusa3d/Prusa-Firmware/blob/11d19879fc1bdf65ec650a288e8f1600ed05d8ce/Firmware/Marlin_main.cpp#L4502

I won't have a chance to work on the machine for a bit, but when I next have an opportunity, I am going to try to build my own firmware with kill_message added to the serial debug output.

[luckshot]

I'm not sure what the deal is. Same situation as described in this thread: Gets partway through mesh leveling and reports "some problem" and wants to re-level Z. After fighting with it for a couple hours today (calibrating, re-calibrating, adjusting PINDA, repeat again) I finally gave up on 3.5.2 and reverted to 3.5.1. With Mk2.5 firmware 3.5.1 my printer is back to printing normally without errors. This 3.5.2 firmware has some kind of issue. It looks like Lachesis is onto something. Hopefully someone at Prusa has the time to run this down before the next FW release.

[FormerLurker]

@luckshot, is the error occurring when it tests the 4th and/or 5th position? When mine fails, it's always in one of those two, but XYZ calibration never fails. I thought MAYBE it was that impossibly fat wiring bundle on the extruder touching the frame (I've spent LOTS of time trying to prevent that), but it doesn't even come close to touching after close inspection. I also printed a very large first layer to see if my bed is messed up, and it looked fine. I've had 2 startup failures today already out of 2 prints though.

[luckshot]

Usually on point 7 of 9. Once I saw it happen at point 3. After reverting
to 3.5.1 we have had no more problems, so just from an A/B comparison it
very much looks like the 3.5.2 firmware itself is the problem. The only
reason we even attempted the firmware update was because the printer
indicated there was new firmware available.

On Thu, Feb 21, 2019, 10:41 AM FormerLurker [e-mail]
wrote:

@luckshot https://github.com/luckshot, is the error occurring when it
tests the 4th and/or 5th position? When mine fails, it's always in one of
those two, but XYZ calibration never fails. I thought MAYBE it was that
impossibly fat wiring bundle on the extruder touching the frame (I've spent
LOTS of time trying to prevent that), but it doesn't even come close to
touching after close inspection. I also printed a very large first layer to
see if my bed is messed up, and it looked fine. I've had 2 startup failures
today already out of 2 prints though.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/1503#issuecomment-466094467,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0dxpLOCzOwNDof92IAcogJHvlSAFdQks5vPto8gaJpZM4aj2H-
.

[jwveldhuis]

Same here, MK2.5 3.5.2 + MMU2 1.0.4.
After the update the 9-point Z calibration fails most of the time and needs a lot of attempts to get passed..

[2blane]

I had this same issue. Z calibration would error out on me at points 7, 6, and 1 (every point on the right side of the board). The issue turned out to be a problem with the trapezoidal nuts fitting inside the x-end-idler plastic part. The trapezoidal nuts would spin smoothly, but when they were put inside the x-end-idler there was some pressure as the fit was too tight. This caused friction and the z-axis would get ever so slightly out of alignment. I sanding the fitting and the trapezoidal nut now spins smoothly even when inside the x-end-idler. The problem has been resolved for me.

For me, it wasn't an issue with the PINDA. My PINDA worked fine. It also, wasn't an issue solely with the trapezoidal nut, but rather the fitting of the trapezoidal nut inside the x-end-idler plastic part. You can see the issue below for more details on what the nut should spin like. Note though, that even if the trapezoidal nuts spin smoothly, they must spin smoothly when placed inside the x-end-idler. Very difficult problem to solve, but I haven't run into this issue since I fixed this fitting.

https://shop.prusa3d.com/forum/assembly-and-first-prints-troubleshooting-f62/issues-with-trapezoidal-nut-t22964.html

My bet is this fixes your issues: @FormerLurker and @lachesis

[FormerLurker]

@2blane, I took apart both trapezodial nuts, and there doesn't seem to be any problems. After re-tightening them I manually turned the z axis with my fingers, and it seemed as smooth as ever (thought, admittedly it is not super easy to tell how easy they turn given the stepper motor resistance).

I've been printing with this thing for a long time (years), and so far this has been my biggest frustration. Who wants to repeatedly have to level Z an unknown number of times before printing? Also, I see no difference at all in my print quality, which I would expect when having such a persistent error. I guess I don't understand the point of this error if it seems to make no difference except now I've got a nice new Sisyphean task.

Can someone from Prusa chime in here? Is this a bug? Is there an undiscovered printer problem I should look into? It's been nearly a month and with all the time I've spent on this I could have been supplying you with whatever info you need to debug this problem.

[JQE]

I am struggling with the same thing. I have calibrated and worked to get it as tight as i can.
Everything is parrellel, the nuts turn smoothly with no issue. The z level is almost exactly the example they use in the instructions.

It passes z calibration everytime, but get the Some problem encountered, Z-leveling enforced. Sometimes its once, sometimes its 4-5 times in a row.

It always happens at point 8 or 9.
I did redo z calibration 2 times to see if it would help.
If i try enough times it eventually goes through, so i do not believe it is a bed issue.
I might try firmware 3.5.1 tonight and see if it helps.

[lachesis]

I have not seen the issue since I downgraded to 3.5.0. I took a quick look at the diff between 3.5.0 and 3.5.1, but I could not figure out why this might happen. It would make sense for this bug to have appeared between 3.4.0 and 3.5.0, as all of this re-leveling logic was added or rewritten between those releases, but there are no real changes in this area of the code between 3.5.0 and 3.5.1. For now, the downgrade to 3.5.0 has solved this for me, but I would love to be able to get back to mainline.

Here is the code that produces the error:
https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp#L4566

Here is the code that triggers that:
https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp#L4512

If any of those break statements are hit, we will eventually end up in the error. Unfortunately, that kill_message which would let us distinguish between the various problems never seems to be used again.

If I get a chance this weekend, I might try hacking in a serial console debug line and upgrading back to 3.5.1 to see if I can figure out which check is failing.

[JQE]

I tried 3.6.0 and it did not resolve the issue. Had it 2 times in a row, third time i was going to watch terminal output to see, and of course it worked.

I will do some more research tonight, i wonder if those codes are stored in the Fail stats.

[kquinsland]

I'll open a new issue if it's deemed necessary, but i just started running into this issue today after a failed print / head crash. I cleaned the bed and tried the same gcode again... no such luck.

i re-sliced the stl and i can't even print the new gcode. the z level 3 of 9 _always_ fails. When this happens, the error encountered, z level enforced... message shows up. I click the wheel to begin the procedure. the gantry moves up, stalls, and begins moving back down. And then it looks like the firmware "forgets" that it already did the first two points. The screen says Calibrating z 1 of 9... and does the 4 hop measurement and then starts moving the gantry to the right... where it promptly crashes. the error encountered, z level enforced... message is displayed, again....

I have tried to power off the printer and manually move the print head all the way to the left, but the "calibrating z level" always fails at the third point.

i have a mk3s running 3.6.0-2069.
I have a few videos if it's helpful. I will try reverting to prior stable firmware.

EDIT: I flashed the 3.7 RC1 firmware from the releases page (i wanted to try out the 7x7x5 bed level.... it's FAST!) and loosened up/re-tightened the print bed and have had a few successful prints since. While i was re-securing the print bed, i noticed a nozzle size/shaped _dent_ in the steel sheet. This would make sense; during one of the z level enforced... procedures, the head did _not stop_ as it approached the bed. it crashed in and depressed the right front corner of the bed. I powered off quickly, and was able to release the print head / bed and verified that it was still on the rails properly. I was certain that i had done correctly as i later ran the the first run auto calibration wizard which confirmed that things were perpendicular.

Possible that me re-seating the bed corrected some slight imbalance that the first run calibration check (the one that takes ~ 12 min and has the head repeatedly homing over the 4 corners...) missed?

[benjamin-goldman]

FYI - i have been on with support about this VERY issue with a Prusa built machine a couple of times and nobody knows what it is.

[kquinsland]

@benjamin-goldman I've been thinking that there's some memory corruption at run time. When printing, the 4th line (bottom) like of the screen should be a marquee style scroll of the current file name, no? I almost never have the file name present. It's there, usually, at the beginning of the print, but soon disappears. Sometimes it's blank, sometimes a few characters. Usually, when it's just a few characters present, the characters are similar to or copies of characters already on the screen (like a 1, because the Z: level is 1.05 or sometimes it's the thermometer icon or the clock (next to the ETA timer) icon.

Theory is that whatever is copying from the ROM into the display buffer is off by a little bit and copying nearby, but not correct, characters.

[mak3r]

I also have been having this issue on firmware 3.6.0. It's was extremely frustrating. Z Calibration always failed after the x-carriage would rise all the way up and then come back down to approx 70mm and stop with the "some problem encountered Z leveling enforced". The printer at that point thought the carriage was at Z=0. Occasionally, I could recover by forcing Z to a high value, lowering the carriage by moving the z axis all the way to the bed and then setting Z=0 within a mm of the correct location. This did not always work and the time to get a print started went from nearly instant after uploading gcode to sometimes impossible to print. I would shut it off for 24 hours until I had time to come back to it. I've been searching for answers and wasn't satisfies that 3.7.0-RC1 would solve the issue. Fortunately 3.7.0 is now tagged "latest".

Today I upgraded to firmware 3.7.0 (I have the MK3 so binary accordingly) . So far I have now had success with running the "calibrate Z" process and the first print started without issue.

UPDATE:
The second print after upgrading to 3.7.0 firmware failed in the same way as before with the exception that now the failure occurs at only 25mm from the top instead of at 70mm down.

[mak3r]

@lachesis

I have not seen the issue since I downgraded to 3.5.0. I took a quick look at the diff between 3.5.0 and 3.5.1, but I could not figure out why this might happen. It would make sense for this bug to have appeared between 3.4.0 and 3.5.0, as all of this re-leveling logic was added or rewritten between those releases, but there are no real changes in this area of the code between 3.5.0 and 3.5.1. For now, the downgrade to 3.5.0 has solved this for me, but I would love to be able to get back to mainline.

I downgraded to 3.5.0 today in the hopes this would solve the problem. It did not! Perhaps there is a real issue in the hardware that's causing this but it's very odd that it only started happening after upgrading the firmware. Now I can't print without black magic and I'm back to not being able to start a print unless I'm sitting next to the printer because it requires user input to get past the notification that I should upgrade to firmware

New firmware version available: 
3.5.1 
Please Upgrade

Has anyone made any progress. Do you have any other suggestions?

[talz13]

@mak3r

I know I'm going to jinx myself, but I've not had any recurrence of the z leveling enforced issue on my mk3s since upgrading to the final 3.7.0 release (it was still present for me in the 3.7.0 RC earlier).

[lachesis]

@mak3r Yeah I think a lot of people who are seeing this problem have legitimate hardware issues. If the bug appeared after upgrading from 3.4.X or lower, then you likely do have a hardware issue. If it wasn't present in 3.5.0 but then mysteriously appeared after an upgrade to 3.5.1, I am stumped too.

You can get around the upgrade firmware notification by just changing the latest available firmware version in Slic3r's machine settings extra g-code.

[FormerLurker]

@lachesis, that could be true, but in my case if an issue exists I have not seen it anywhere else except for the bed leveling procedure. My first layer always looks good, no problems with curling or adhesion, good print quality (except for some MMU issues that I plan to work out soon).

I believe the problem here is that it fails with no useful feedback. If the problem is big enough to cancel the print, I'd expect it to have some noticeable effect on something, print quality or otherwise.

Also, I've not had a failure with XYZ calibration in quite some time. I also broke down my printer and ran lots of tests (as you can see above). XYZ worked fine after several attempts, but leveling still fails randomly.

Edit: It doesn't actually cancel the print, I don't know why I said that. It just loops through the leveling procedure over and over, and I cancel the print and try again after powering down, which seems to (usually) fix the problem. For example, just this week I tried to run the leveling procedure after it failed 5 times, and it never succeeded. After rebooting it worked on the first try. It doesn't always work on the first try after a reboot, but it rarely succeeds on retry if the first attempt fails. Something fishy is going on because why would the retry fail way more often than the initial attempt?

[mak3r]

Wow. Thanks everyone for the fast responses! I also found this thread https://shop.prusa3d.com/forum/hardware-firmware-and-software-help-f64/some-problem-encountered-z-leveling-enforced-error-t26525.html and downgraded to firmware v3.4.1. The problem is gone - at least on this first print.

[mak3r]

@mak3r Yeah I think a lot of people who are seeing this problem have legitimate hardware issues. If the bug appeared after upgrading from 3.4.X or lower, then you likely do have a hardware issue. If it wasn't present in 3.5.0 but then mysteriously appeared after an upgrade to 3.5.1, I am stumped too.

You can get around the upgrade firmware notification by just changing the latest available firmware version in Slic3r's machine settings extra g-code.

@lachesis Maybe I was at 3.4.x when I upgraded last time. I'm not really sure. I guess I upgraded slic3r and then started getting the firmware upgraded messages on the printer. If it is a true hardware issue how do I figure out what it is? I wonder do I need a new pinda or is it something else. I guess that's for another week when I have more time. Thanks

[JoN1oP]

I'm experiencing the same issue on my MK2.5. I upgraded from 3.5.1 to 3.7. Upgraded to the latest slic3r, latest everything basically :)

When I tried to print something, on the 7~8th calibration point it did seem to struggle finding the point and triggered the error. It then asks me to raise the Z axis to the top which I did a few times but everytime I answer "Yes", the Z-axis starts going down and once it reaches the bed, doesn't do anything and basically asks me to raise the axis again (kind of a UI loop).

I went through the whole Setup wizard, no issue whatsoever in finding the calibration points, did get a perfect first layer calibration.

Trying to print again this morning, I first get a "MINTEMP BED" error during the warmup (even though the ambient temperature is around 18°C). I immediately retry the print and it starts the whole calibration process. It calibrated fast on a few points but struggled on a couple along the way. It finally failed when it reached the 8th point.

Not sure what to do aside from downgrading the firmware but according to the previous comments it doesn't seem to be a guaranteed success.

[theamazingdrew]

I'm on a MK3 with 3.5.1, and just started seeing this issue for the first time tonight. I flipped the sheet over to make sure it wasn't a dent. No difference. Just stuck in a loop now... Nothing will print.

[JustinFarris]

FWIW, I'm getting this problem on 3.7.0. It happens during about 75% of my prints at one of the Z checkpoints, but not always the same one. It's usually in the back row, but I caught it once in the front.

My best guess is that it does have something to do with a PINDA problem, but when the calibration makes it all the way through the prints are fine, so I'd like to either figure out what's causing it or somehow allow the firmware to ignore whatever problem it's detecting for now.

[mak3r]

All, I replaced my PINDA probe and I am now running on v3.7.0. So, did the update cause a bunch of PINDA probes to fail? Why so many problems with so many users after recent updates? Did we all just reach PINDA end-of-life at the same time?

These questions will likely never get answered and rather than distress over it, I recommend getting the new probe and moving on so you can print again. Too many hours spent trying to get software to solve a hardware problem.

Well, I for one am much happier when the printer is operating.

[FormerLurker]

Ok, I updated the firmware to 3.7, and finally my problem seems to have ended. I just started about 5 prints in a row without a failure. Point 3 always tries twice (one with the fast motion, once with the slow motion). I'm not sure what is different about point 3 (it's at the front right position, previously it had been getting stuck on the left side in the middle), but I'm fine with it so long as it continues printing.

I'll continue testing, and if the issue really is gone, I'll close this ticket. Whatever my problem was it seems different than everyone else's problem.

[FormerLurker]

OK, my problem has been solved. I notice the new... 9?? point leveling will recheck what seems to be a random point (second, slower check) on perhaps every other print, but it's not failed yet after about 10 prints. It must be some resonance issue with my machine, right? At some point I'll try to test this, but it doesn't seem to affect my prints much, if at all, so this will be a low priority for me.

I CAN'T TELL YOU how happy I am. My printer is not next to my PC, and now I only have to walk to the printer once to select the filament (for single filament mode) per print instead of sometimes 2 or more times! On some days I'll do 10-20 very small test prints while working on my plugin, and this saves me gobs of time and frustration.

Also, love the new leveling! It's so fast :)

CLOSED!

[FormerLurker]

I had a few more 'Some problem encountered, Z-leveling enforced' errors, and found my problem and a solution. Of course, it was really my fault all along (of course). However, your fix that slows down the second Pinda probe motion if there was a problem with the first REALLY mitigated the problem. I figured I best own up to my mistake and let you know so you can add it to your list of things to check if you hear about this issue again.

So, I noticed that my X axis belt was a little loose. While I was squeezing it together to test the tension, I felt a sort of ticking, and suddenly the belt had even less tension than before. After some experimentation and tinkering, I finally figured out that the screws on the right side of the X axis that make contact with the two X axis rods had gotten quite loose (or maybe I just never tightened them properly, I can't be sure), and weren't making contact with the X rods anymore! I tightened them up and my belt went back to normal. No z-axis wobble, and the printer sounds different during z hops. I didn't even notice that the hops sounded strange before.

I figure when the Z axis lowers to the bottom for the Z calibration there is less give in the Z rods, so the belt was stiffer there, and there was less flex in the Z rod itself. As it moved up and down for calibration the rods were able to flex more, slightly changing the height of the PINDA probe, or perhaps resonating with the movement. It's a miracle it ever worked, honestly. Also, the fact that such a large issue could exist with little to no effect on print quality is pretty amazing, and is a testament to the quality of your machines.

Edit: I don't feel there is any need to reopen the issue, but I wanted this solution here in case anyone searches your repo for this issue.

[lachesis]

Glad to hear you figured it out FormerLurker. Thanks for posting back to share what you learned! :+1:

As far as I can tell, my issue disappeared with the upgrade to 3.7.1, so I think there was something software-related happening for me. As a bonus, the mesh bed levelling is much faster for me on the 3.7 firmware than it was on 3.4.

[FormerLurker]

OH man I love it. It's faster than I'd ever though possible (I never thought the old one was slow) and actually fun to watch.

[PrintedSolutions]

custom g-code and firmware are not on the same page.

M115 U3.7.1 ; tell printer latest fw version