Mesh Leveling Bug?

[CCS86]

Hi guys,

I'm having trouble with mesh leveling on my MK3 running 3.4.0.

Essentially, I can see that in areas which are being "over-squished" the mesh leveling is lowering the nozzle, and areas less squished it is raising the nozzle. So, it is either overcompensating, or introducing error.

I am a mechanical engineer, so precision alignment is a very familiar task. I have used a digital indicator to mechanically level my bed. It is flat within +/- 0.0015".

I have actually shown that I get a more consistent first layer with mesh leveling disabled, but this seems to create a new issue:

If I comment out the G80 mesh leveling code, the printer seems to ignore the stored live Z adjust value. The nozzle is very high. The printer does respond to changing that value after the print has started.

If my stored live Z value is "x", I end up with about 2x to get it printing correctly. If I stop that print and start another (power remains on), the nozzle is high again and the live Z value needs to be increased to 3x.

Short story:

• There may or may not be a bug in the mesh leveling. It is possible that the Pinda probe is just not accurate enough to fine tune a fairly flat bed. It seems precise in that the over/under squished areas seem to repeat.

• I need a clean way to disable mesh leveling and get a consistent Z0 height

Thank you!

[Pathogenius]

I'm not sure if this is related, but while fighting with bed mesh correction, I happened to notice that my sheet was not flat, and then verified that with it on the hot plate using a laser, BUT, then removed the sheet and lasered the bed, which was way way more flat. In other words, the sheet itself is screwing up my bed level.

[CCS86]

That isn't related. I have checked both my platform and my print surface and find they track together very well. My stated flatness above is on the actual print surface.

[Pathogenius]

Some people have suggested that the Pinda doesn't work very well when the printer is cold. It seems to be true for me. It usually takes me 5-10 test prints of my Live-Z test object to get bed mesh correction setup properly, and by that time the whole print including frame and motors, have reached stable temperatures.

[CCS86]

I'm not experiencing that either.

If I start cold, and print multiple objects back to back, my first layer thickness isn't varying.

The individual points for each mesh calibration are wrong.

[Pathogenius]

Did you happen to try adjusting the Z offset using Slic3r rather than the Live-Z option in the printer itself?

[ Printer Settings / Size and coordinates / Z offset ]

[CCS86]

I have not. I don't use Slic3r. I prefer Cura.

[CCS86]

?

[AndrzejCichocki]

I too have an issue with mesh bed levelling and would like to turn it off.
I have been trying for a couple of weeks now to get a consistently flat 1st layer to print on the Prusa i3 Mk3 but cannot, no matter what I try, the printer squishes the front middle the most to the point of being unusable and prints with variable quality over the rest of the bed.
I have fitted springs and used a DTI gauge to get the bed level to within 0.01mm (Lifting the steel sheet and replacing causes variance so anything finer cant really be trusted, but this is good enough for a flat bed), and have checked with the gauge fitted to the left of the extruder motor, to the front and to the right as close as I could get to the PINDA probe and always I get the same results after running a G80 G81, the printer insists the front middle is lower than the rest of the bed, yet it is not!.
If I adjust the bed so the G81 values are indicating a flat bed or adjust to make the bed lower at the front , the front middle still remains squished the same amount, so the bed correction is working, just consistently wrong!.
All I want to do is switch of the automatic mesh bed levelling and print at a fixed live-z value.
Below are two G81 outputs from two different firmwares which show the same issue, but the latest firmware is even worse, both outputs done one after another without removing the steel sheet and allowing the PINDA time to warm up beforehand.

3.1.3:
0.21667 0.19787 0.18315 0.17250 0.16593 0.16343 0.16500
0.13167 0.14619 0.15746 0.16546 0.17021 0.17169 0.16991
0.07639 0.11129 0.13848 0.15796 0.16974 0.17382 0.17019
0.05083 0.09315 0.12620 0.15000 0.16454 0.16981 0.16583
0.05500 0.09178 0.12064 0.14157 0.15459 0.15968 0.15685
0.08889 0.10718 0.12178 0.13269 0.13990 0.14342 0.14324
0.15250 0.13935 0.12963 0.12333 0.12046 0.12102 0.12500

3.5.0:
0.21167 0.19509 0.18204 0.17250 0.16648 0.16398 0.16500
0.13093 0.14735 0.16003 0.16898 0.17420 0.17568 0.17343
0.07787 0.11302 0.14052 0.16037 0.17256 0.17710 0.17398
0.05250 0.09213 0.12352 0.14667 0.16157 0.16824 0.16667
0.05481 0.08466 0.10901 0.12787 0.14123 0.14910 0.15148
0.08481 0.09062 0.09701 0.10398 0.11154 0.11969 0.12843
0.14250 0.11000 0.08750 0.07500 0.07250 0.08000 0.09750

Look at how the bottom row drops compared to the first set of results.
They are both false, since my bed has been checked with a DTI gauge and is less than 0.01 variance, yet this is saying I have over 0.1 variance, no wonder I can't get a consistent 1st layer over the whole bed.

I tried commenting out the G80 line in Slic3r setting live-z to 0 (Normally -0.5mm) and using the printer offset dialed into -1mm but this did not appear to allow the head to go near enough to the bed to be able to print, I started at 0 offset, then -0.5 finally -1 but there appeared to be no difference to the head position so I stopped for now.
If anyone has any other suggestions to try, I will gladly try them to get an even print. Is it possible to directly access the EEPROM values where the offsets are stored using an AVR ISP Mk2 and modify them as I am sure this is where the problem lies, but I don't have enough technical information yet to do this.
KR

Andy

[jonnieZG]

Some people have suggested that the Pinda doesn't work very well when the printer is cold.

That's what for the PINDA Temperature Calibration is. A healthy PINDA on a MK3 should be working fine on both a hot and a cold printer, if properly calibrated.

The PINDA on my old MK2S was so temperature dependent, that mesh leveling was not working properly. By the time it would got to the 9th calibration point, the sensor would pick up enough heat to read wrong distances. Fortunately, the MK3 solves this problem, so you might want to check if your PINDA is OK.

[CCS86]

I don't understand why after nearly 2 months, we have yet to receive a single reply from Prusa devs.

[dway100]

I'm having the same issues. G81 shows that I am within .015 across the print surface, but I still have to dial in -40 on the left and 25 on the right in the mesh leveling calibration correction to get an even first layer. I even tried adjusting the bed to be higher on the left and lower on the right and it made no difference. Still needed -40 and 25. I contacted Prusa support through the chat and they sent me a new PINDA which I installed yesterday....same results. It's really frustrating. This is my first printer and I've only had it since the middle of October and I've spent way more time trying to figure this out than I have actually printing things.

[UebertreibeR]

Happy to find this. I do have the exact same problem so I'm in with you guys. @CCS86 I tried the same thing running prints without G80. It seems to be more consistent but I have to live-Adjust Z in the beginning of the print just as you described.
I'm currently thinking about modding the Firmware in order to disable any mesh bed correction but keeping the Live-Z funcionality.

@dway100 I think we already discussed it on my Post in the prusa FB group. Patrick here :)

[AndrzejCichocki]

I have looked at the firmware and understand some of it, but my C coding knowledge is not ideal, so I am struggling with it.

[zbross]

I will chime in here as well and say that I've been having the same issue. I have tried manually leveling, and no matter what I do the front and right sides still indicate that they are lower than the rest of the board. If I adjust them to get consistent values with G80 and G81, the first layer gets squished in those areas. I'm going to be trying with a downgraded firmware this afternoon and see what happens.

[CCS86]

Come on devs, a response would be great.

[F0x06]

Come on devs, a response would be great.

I think this is interesting :) #1239 (comment)

Edit: I know your are also following the other issue, its for others

[CCS86]

This is a pretty sad showing by Prusa support. To completely duck looking into this issue and replying is hard to justify.

Chat support bounced me to email support. Email support bounced me to github, and now I'm just getting ghosted.

[hackinistrator]

hi CCS86 , i managed to do what you're looking for with 2 different methods.
i'm using e3d new hotbed that heats up more then 200c , no pei sheet can withstand those temps . so i lost my mesh bed leveling (+using thick glass plate over the heatbed) .
so , method 1 is to move the pinda out of the extruder , connect it to the left side of the x carriage . (design and print custom left side carriage) .
add some metal plate (or adjustment screw) under it to set z home position .
if you use adjustment screw , you wont need mesh bed leveling at all , remove g80 from the starting script of your gcode . adjust z height with the screw.

method 2 - firmware editing . sometimes i'm using different "live z" values for different materials so this method works better .
same thing here , the pinda probe is on the left x carriage (for initial z homing) .
but you can leave your pinda in its original location {it will home normally}in your case). g80 command is not doing mesh leveling , just adds the live z offset values.
you need to edit the G80 command in marlin_main.cpp file .
i'm also not good with coding , but if you need help with that let me know .
i'm using mk2s btw , but this area in the firmware is almost the same .
you'll completely loose mesh bed leveling , all calibration points will have the same values (+offset)
added pic of my pinda probe on left x carriage

[Pun-e]

Hi, thanks to the lockdown I'm taking part in the #speedboatchallenge and have noticed that mesh bed levelling slows down my entire print by 20-40%
Benchy with leveling : 24 min, same gCode without MBL : 18 minutes
At first I was fine manually tramming the bed every time, but after 4 prints my live z offset is approaching 5mm and if I ever forget to reset it manually before doing a normal print, something's going to break
I cannot understand what is so difficult about checking the first probe point, with the exact same code that's there already, but instead of calculating a complex, interpolated mesh from the array of probe points, to just write the value from the first probe point to the entire mesh.
Hell, you could even probe all 9 points so that you can use 99% of the exact same code, just add a flag to G80 to allow the user to specify when they want to run dumb

[github-actions]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[CCS86]

I'm going to bump this so it doesn't get automatically closed.

The Prusa devs should be ashamed of this complete lack of support for a serious functionality issue affecting multiple users.

When I bought a new printer and my company bought multiple printers, and friends ask which printer to buy, guess which printer is not mentioned. Great job losing multiple sales out of laziness or neglect.

[github-actions]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[Prusa-Support]

I'm sorry to read that the problem is not resolved, however, it is very hardly reproducible.

There are several conditions that I could think of off the top of my mind to reproduce the problem but pretty much all of them are hardware-related. I'll try to quickly explain a few.

• The PINDA may be faulty or out of specifics.
  This article should help.
  It may be useful to repeat the last "G80/G81 test" at different temperatures too.

Even if perfectly flat, the heatbed may warp up during the heating if somewhat loose, modified, or in case of cold zones.

• Make sure all the 9 spacer nuts under the heatbed are straight and equally long. Preheat the heatbed to 100°C and loosen the 9 screws on the heatbed. Let the Y-axis absorb heat at the target temperature for 10 minutes, then fully tighten back the 9 screws, without force, but following the sequence explained in the assembly Step 17 Mounting the heatbed (part 4).

• [only PINDA v2] From time to time, the PINDA may benefit from a Temperature Calibration for higher precision at various temperatures - feature not available and not necessary for the Super PINDA.

• We can't exclude the PINDA's thermistor reading is altered over the movements due to partial damage.
  Let the PINDA absorb heat from the bed for several minutes, close to it. Then check if its temperature in "Support > Temperatures" bounces while sliding the X-axis, and wiggling the cable above the PINDA and behind the extruder.

• Cold zones on the bed may cause substantial deformations of the bed heating. A temperature gradient towards the edge is probably just fine but we are looking for substantially cooler macro zones.
  Heat up the heated at 50°C, dampen a tissue with a generous amount of alcohol, and wipe it on heated (without sheet) to make the entire surface wet. Hence observe if the alcohol evaporates uniformly - here is an example.

Last but not least, signal noises have been observed on specific combinations of hardware revisions - #3563 - but honestly, it doesn't seem related, especially because the latter issue is observed on relatively recent hardware revisions.

Michele Moramarco
Prusa Research

[CCS86]

This would have been helpful 5 years ago. I moved on to different brands in part because of poor support.

[Prusa-Support]

I'm sorry to hear that. Not sure what went wrong and how the support was interrupted as our support sessions would theoretically be carried on until a satisfactory solution is found.

Because GitHub is where we track firmware-related problems/suggestions, but this issue is not confirmed to be a firmware problem thus far, the issue will be closed now.

Michele Moramarco
Prusa Research