Higher density mesh bed leveling

[stahlfabrik]

This seems like a low-hanging-fruit feature request

The MK3 mesh bed leveling is quite coarse, it only probes a 3x3 pattern. I had my heatbed exchanged because my old bed has a slight bow right where the PINDA does not probe - so the printer is blind to that. Also, in order for a super consistent first layer I generally wished I could configure the amount of leveling probe points.

The Klipper firmware makes the probe pattern configurable. I wished I could do that on my MK3, which runs the Prusa firmware.

Internally, the 3x3 grid is interpolated to a 7x7 grid. So an obvious way would be to add a "fine" MBL option in the printer settings, so that the printer scans a 7x7 grid and then does not interpolate anymore. It would be even better, if the number of probing points in X and Y direction would be configurable seperately. I would think in the range of 2 to 7.

I would love that - and I am sure the number of Heatbed replacements would go down if that would solve some first layer issues.

I think I remember a video on YouTube where Josef teased a menu config option for exactly that. It was when MK3 was still in internal beta.

Best regards

[stahlfabrik]

IMO quite an improvement which is not surprising - giving that theory that minout has MBL deactivated in the planner:-)

[RacingHell]

Has anyone checked, if the pinda temperature and it‘s calibration-curve isn‘t mixing up results between 3x3 and 7x7? Underneath 30°C probe temp the MBL is a tiny bit different for me (as already discussed, because the calibration doesn‘t recognize those lower but necessary temps) but muuuuch more solid, since manual calibration with the continuity measurement method. There could be the effect of having more warming up time for the pinda on 7x7 which could give more stable MBL as well?

[stahlfabrik]

A good calibration is needed for optimal results. I guess pinda will heat maybe 5C or so doing the 49 points when printings abs:-)

You always should start the MBL with pinda temperature of at least 35C. Under that and the firmware cannot compensate the temperature shift. Another low hanging fruit for Prusa to change:-)

[F0x06]

Thanks for your confirmation. So my firmware should have a visible effect:-)

Im re-printing right now a pattern with your firmware, the only thing i can confirm is that Z-motors are moving slightly during print, this confirm that MBL is working, it can be interresting to check the same with @mionut firmware.

[edspeds]

As far as PINDA is concerned, I have a script in my starting GCODE to bring the PINDA to 35C prior to mesh bed leveling to help with consistent first layers. In any case there's a definite improvement with the higher density MBL. As an aside I also used springs in place of the standoffs for my bed leveling. I typically have it within 0.05mm for my PEI sheet but just tossed the 3rd party sheet on to test as I my Prusa PEI sheet is pretty good and the 3rd party is scheist.

[F0x06]

As far as PINDA is concerned, I have a script in my starting GCODE to bring the PINDA to 35C prior to mesh bed leveling to help with consistent first layers. In any case there's a definite improvement with the higher density MBL. As an aside I also used springs in place of the standoffs for my bed leveling. I typically have it within 0.05mm for my PEI sheet but just tossed the 3rd party sheet on to test as I my Prusa PEI sheet is pretty good and the 3rd party is scheist.

I also use a >35c PINDA GCODE script :).

[stahlfabrik]

@codiac2600 i just thought: the sheet metal SHOULD shield the magnetic forces, shouldn’t it? So I took the pliers and moved them ontop of the sheet. I could not feel the force of the magnets. Without the sheet the pliers get attracted.

One very scientific proof that Jos fears are not warranted. ;-)

[codiac2600]

@stahlfabrik

I would say this all depends on how affected a pinda us by weak magnetic fields. It should be affected some but the question is how much. We could try seeing if the map is better or worse by placing something thin enough to block any additional magnetic field but still allow the pinda to resister the surface. Or even remove magets besides the ones on the corners.

[RacingHell]

@stahlfabrik I was wondering and quickly loaded a magnetometer app onto my smartphone, it uses the compass sensor. Magnetic fields are there, and it seems to get higher with sheet on it. :)) But this could also be just the sheet it spots.

[stahlfabrik]

Haha:-)

Great ideas:-)

Anyway 7x7 MBL imho works great (for me).

[F0x06]

Haha:-)

Great ideas:-)

Anyway 7x7 MBL imho works great (for me).

A big question left: Why prusa MBL can't manage to do his job properly without the use of "Bed level correction" ?

I got the best but not perfect results with: Left: -47 Right: -20 Front: -4 Rear: 9

[OopAck]

Where an how to print to test the 7x7 level?

[stahlfabrik]

You install the modified firmware and change the G80 to G80 N7 in your start gcode

[F0x06]

Little update here, i reinstalled the nylock nuts manual leveling mod, this is what i get from Octoprint PrusaMeshMap when done (Bed 65c)

And right after the same with G80 N7

PS: Happy new year everyone !!!

[Tinker999]

Thank you, thank you, thank you for the best first layer I every had on my Mk3. Just flashed the new 7x7 firmware and very happy with it.

Also great top layer, I guess great bottom layer helps yields a better top layer.

[CCS86]

It would be awesome if someone developed a modification to mesh leveling, to blend the effect out over some number of layers.

[PurelyAbrasive]

Does anyone know if the new firmware has the nyloc bed leveling code in it? Where the center is the zero point and all other measurements are from there?

[F0x06]

Does anyone know if the new firmware has the nyloc bed leveling code in it? Where the center is the zero point and all other measurements are from there?

Nope, this is the same version but with g81-center patch :) enjoy: firmware.zip

[alandeane]

Is it possible to build a Mk2.5 version of this firmware? I believe it has the same bed as the MK3, so the hardware should be capable.

[stahlfabrik]

LOL to the question before and the quick turnaround. Not about the 2.5 question

You might want to use the bed visulatizer plugin in octopi. There you can activate a checkbox that shows the bed centered without any firmware patch.

Another idea that i have: why not move the left edge of the mesh bed leveling more to the left? As there is a steel sheet there is no reason like hitting a special spot on the bed pcb to not measure edge to edge. On right side the bed is measured on its very edge. On the left we could basically probe at homing position on x.

Attention when implementing that tho: there are spots in mk3 firmware where the first leveling spot is used and where the machine might have no steel sheet on!? Not sure. Thinking of temperature calibration. Maybe xyz calibration too

[codiac2600]

Is it possible to build a Mk2.5 version of this firmware? I believe it has the same bed as the MK3, so the hardware should be capable.

We have a copy here on our Facebook group. Check the files section. https://www.facebook.com/groups/prusacommunity/?ref=share

[alandeane]

Is it possible to build a Mk2.5 version of this firmware? I believe it has the same bed as the MK3, so the hardware should be capable.

We have a copy here on our Facebook group. Check the files section. https://www.facebook.com/groups/prusacommunity/?ref=share

Thanks, I have asked to join the group, awaiting approval.

[duartemv]

I have a question/request.

A few months ago someone tweaked the official firmware 3.4.0 so the nozzle fan gets quieter at lower speeds. This improved sound reduction greatly, specially for night prints.

Does this release also has that feature? Or can someone/that same person add that feature to this release?

[Joelgastro]

Thank´s a lot guys! I now have a printer that isn´t only printing reliably in specific areas of the bed.

[stahlfabrik]

@duartemv I would suggest to get familiar with how to compile the firmware. It is rather easy and empowers you to mod the firmware to your liking. That fan change is one line of changed “code”. If I got that correctly Best regards

[F0x06]

Thank´s a lot guys! I now have a printer that isn´t only printing reliably in specific areas of the bed.

Which Sheet did you have ? Powder coated or Smooth PEI ? I have the Powder Coated Sheet from prusa, apparently that's normal to have some places more squished acording to Prusa support due to the variations of the coating

[duartemv]

@stahlfabrik I can do that.

[FmrAnimalTech]

Just flashed the new 7x7 firmware, changed the G80 to G80 N7 in my start gcode. I installed on 1 of my 4 MK3s to test it... the test print came out PERFECT! This is AWESOME.... I am very happy with it... I am now flashing the other 3 !!!!

[alandeane]

I have installed the mk2.5 version, and can report it's working well, with the MMU2 unit installed. I've only run single prints so far, but I don't see why a MMU print should have any issues.

[mionut]

Hello, I am glad that my code works for more people. I commented mbl.get_z(x, y) in plan_set_position because i suspected that the distance is applied 2 times. plan_set_position is used in functions:

• calibrate_z_auto
• home_xy
• homeaxis
• retract (firmware)
• recover_machine_state_after_power_panic
• update_current_position_xyz (bed calibration)

That is in homing and calibration mostly. The other place mbl.get_z(x, y) is in function plan_buffer_line that is the main function for moving in normal printing and here is not removed. Is it better with mbl.get_z(x, y) removed from plan_set_position or left there ?

[stahlfabrik]

As far as I understood one feedback above it works better in my fork where I did not touch the planner. Personally I did not compare printing results myself. I just could not make sense of your change:-) so I left it as Prusa implementation has it. But thank you for explaining the reasons. I think we all - especially the Prusa developers - now can think about it.

Your workaround is making quite a lot of people happy now:-)

[F0x06]

Just to inform you guys, prusa team is currently working on a fix, there is some leveling issues confirmed apparently sinze 3.5.0, IMHO it's older than that, and apparently downgrading firmware does not resolve the issue, I assume it's related to values stored on eeprom. I have these informations because I spoke with chat support yesterday.

[insanity67]

Just to inform you guys, prusa team is currently working on a fix, there is some leveling issues confirmed apparently sinze 3.5.0, IMHO it's older than that, and apparently downgrading firmware does not resolve the issue, I assume it's related to values stored on eeprom. I have these informations because I spoke with chat support yesterday.

Could you please give a bit more details about this? Have massive problems with leveling atm on 3.5.1.

[F0x06]

@insanity67

I don't have more information than that sorry, this is all I got :/

[AnatomicFlack]

I had a very strange issue the other day that might be related to that EPROMM issue.

I used the bed leveling adjustments in firmware to tweak the bed up on one side and down on the other before my planned switch to the 7x7 firmware. I had entered a value of -4 on the left and +4 on the right, everything else was zero. I then zero'd out those two settings (to go back to mechanical leveling) and spent a good hour leveling the bed (still before 7x7) with the non wave spring/nyloc nut way and I had it nailed down to an under .02 delta. I then reset the printer and on the next level check the bed was perfectly tilted to one side as if those -4/+4 values were finally reset and removed from epromm. I ran the check 5 times and the results never changed outside of slight measuring variance. I reset, checked Z, used the reset option under the firmware bed level adjustments and checked for stuff under the bed. Nothing changed, this was in fact that actual bed numbers.

So even though I set the left and right adjustments back to 0, it didn't seem to take effect until I restarted the printer. I had run about 15 G80s with it like this before restarting. This could potentially cause some serious issues if you are leveling and adjusting values, but it's not being properly updated without a reset.

If anyone else wants to try to repeat the issue:
G80, adjust the bed level through firmware, G80, then set bed level back to zero, G80 before a reset, G80 after a reset. There should result in a jump between the last two G80s without any physical adjustment to the bed.

Images are level before reset and just after reset. No other change.

[F0x06]

@AnatomicFlack Thanks a lot for pointing this issue, so it means we need to restart printer between each correction before testing?

[zbross]

@AnatomicFlack What website, app, plugin, or file are you using there to visualize and interpret your G81? That seems incredibly useful for helping people who use the screw adjustment method to figure out what they need to do.

[AnatomicFlack]

As far as needing a reset each time, I don't think so. In the past, I've used it to adjust values and the bed and I felt it worked as expected. It may just be when resetting or going back to zero it may need a reset to clear the values for sure. I'm just guessing here though. I don't know nearly enough about the order of operations when processing the value change they are using here.

The file was created by someone named Walter Lundin and posted to the Prusa Facebook Group. It's an AMAZING tool and helped me dial in the bed quickly each time. I would only suggest making sure you have a right angle Allen key to help approximate the angles needed.

Link to the FB Post: https://www.facebook.com/groups/prusacommunity/permalink/899507453723321/

Link to my DropBox in case people aren't members of the FB Group yet: https://www.dropbox.com/s/lcp51lb4f2rw5p3/Bed%20Leveling.xlsx?dl=0

[mionut]

Please try the new committed pinda temperature smoothing. It uses shift with 2 instead of division. These are some consecutive pinda temperatures from octoprint console (P: value) without smoothing: 24.8, 24.5, 24.8, 25.2, 25.1, 24.4, 25.0, 24.5, 25.1, 24.9, 24.8, 24.6 and these are with smoothing: 24.7, 24.7, 24.8, 25.1, 25.0, 24.8, 25.0, 25.1, 25.0, 25.1, 25.1, 25.1, 25.1, 25.1, 25.1, 25.1 The variation is much smaller.

Also i observed that the bed warps after the target temperature is reached so i put a 60 seconds delay with G4 S60; after waiting for heabed temperature and before mesh bed leveling.

[zbross]

I'll also throw in an interesting issue that you may want to try and duplicate. On stock firmware 3.5.1, with no special changes to any gcode, no bed corrections, here are two different G81 outputs:

They look completely different, right? The thing is, no changes have been made between them. One was found by running G81 after G80, and the other was found by running G81 in the middle of a print that was built with Sl1c3r PE, also with no modifications. Any suggestions as to what may cause this discrepancy?

[stahlfabrik]

The pause might be a very nice addition to my start gcode! Great idea.

If the filter is necessary I don’t know. The offset does not change that much +-0.5 degrees. But maybe it does help to get an even better bed. Possible. Great idea still!

I hope Prusa start fixing other things than MMU soon.

[stahlfabrik]

@zbross. Your PINDA is carefully calibrated?

[zbross]

@zbross. Your PINDA is carefully calibrated?

If you mean temperature calibration, then yes, I went through the process a while back. It wouldn't surprise me if it got lost in the myriad of resets, firmware flashing, and other attempts to fix this, so I'll revisit it, but as far as I can tell there's no issue there.

[stahlfabrik]

Resets delete the calibration.

Anyway: you should compare MBL values at exactly the same PINDA temperature. Then it does not matter if your PINDA is calibrated:-)

[zbross]

Resets delete the calibration.

Anyway: you should compare MBL values at exactly the same PINDA temperature. Then it does not matter if your PINDA is calibrated:-)

Thanks for letting me know! I always test at the same temp using a custom gcode to get the PINDA up, but it looks like that's different from the temp when printing, maybe? Either way, thanks again, and sorry for hijacking this thread.

[insanity67]

Can someone describe in a few words the differences between the two forks, I mean stahlfabrik or mionut version? I´m uncertain what I should use now?!

Thanks!

[stahlfabrik]

Mine has just the 7x7 mesh bed leveling and is otherwise stock.

Mionut has some other parts changed: filtering of PINDA temperature and he has changed the PINDA temperature calibration ranges. Also he has done a change to the planner Logik regarding the use of mesh bed leveling values that I have not yet fully understood.

[F0x06]

I use @stahlfabrik version with @mionut PINDA smoothing, also Im not really confident about the planner.cpp change, I need to understand the code a bit more. Works really great!

[Tinker999]

This is a awesome change. Any feedback from the developers. I for one will not update my firmware without it. I now can can use the whole print bed.

[Tinker999]

🎉🎉🎉🎉