Hyperfine bed leveling?  

Re: Hyperfine bed leveling?

G80 values can be much higher than the EEPROM stored one.

Have you had any more thoughts on storing the values as steps? We did discuss this a long time ago and it would make a lot more sense. I am pretty sure there's an EEPROM bit that could be used as a "converted-to-steps" flag.

Peter

Re: Hyperfine bed leveling?

Do you Guys think you could help me find a firmware for mk3 with hyperfine bed leveling. Thanks in Advance

Re: Hyperfine bed leveling?

Do you Guys think you could help me find a firmware for mk3 with hyperfine bed leveling. Thanks in Advance

Hi Thai.b,

latest MK3 release is https://github.com/3d-gussner/Prusa-Firmware/releases/tag/MK3-v3.1.3-HP

I know i wrote that already once or twice, but i hope getting Hyperfine bed leveling implemented in MK3 v3.4.2

Re: Hyperfine bed leveling?

G80 values can be much higher than the EEPROM stored one.

Have you had any more thoughts on storing the values as steps? We did discuss this a long time ago and it would make a lot more sense. I am pretty sure there's an EEPROM bit that could be used as a "converted-to-steps" flag.

Peter

Hi Peter,

yeah i was looking into that and try to get the same steps like in Live-Z where the 1st knob turn adds/subs 1 and the 2nd or 3rd 2 for the HBL LCD menu.

As the EEPROM table changes every time Prusa adds new features/functions i was thinking to use 'EEPROM_FARM_MODE' and 'EEPROM_FARM_NUMBER' space for the additional needed HBL values. I guess nobody except Prusa uses the FARM MODE.

Disabling the FARM_MODE is lot of work and testing.

Hopefully merges to newer firmware versions will get easier that way on the other side a pull request might get difficult as this FARM_MODE disabling is a quite big change.

I am not sure which way i should go?

Re: Hyperfine bed leveling?

I am not sure which way i should go?

Sorry, I really can't help you make that decision; I have forgotten most of what I learned with this 🙁

I do have a feeling that whatever you do, ultimately will be wrong; there seem to be way too many changes needed to the firmware at the moment.

It would be so much easier for everyone if PR picked this up and ran with it.

Peter

Re: Hyperfine bed leveling?

So far if I want to hyperfine my bed level I have to use the amended 3.13 firmware until one is made for 3.42. Thanks 😛

Re: Hyperfine bed leveling?

also forgot to add cna you use a g80 code with abcdefgh on a normal gcode and pr firmware 😆

Re: Hyperfine bed leveling?

Do you Guys think you could help me find a firmware for mk3 with hyperfine bed leveling. Thanks in Advance

Hi Thai.b,

latest MK3 release is https://github.com/3d-gussner/Prusa-Firmware/releases/tag/MK3-v3.1.3-HP

I know i wrote that already once or twice, but i hope getting Hyperfine bed leveling implemented in MK3 v3.4.2

Would be nice but I do not see anything mentioned in the 3.4.2 (be9f921) about hyperfine bed leveling, so maybe it will take a bit longer.

Did anyone try to create a MK3 3.4.2 firmware with the hyperfine bed leveling code merged. Maybe I'd try myself but it is quite a couple of years that I've worked with GitHub so I'd have to get familiar again. 😉

Re: Hyperfine bed leveling?

Why completly remove the FARM_MODE feature? Just ensure that it would be always disabled with a preprocessor macro.
So maybe everywhere there is an #ifdef FARM_MOD replace it with an #if 0
Or simply hide the FARM_MODE macro ^^

So you wouldn't have to worry about updating your fork with the upstream.

Re: Hyperfine bed leveling?

Interesting observation. I have been operating a MK2 with hyperfine bed levelling for some time. The XYZ calibration results gave the axes as perpendicular but I needed a range of non-zero hyperfine values at all the calibration points to achieve a level print surface. I recently upgraded the MK2 to a MK2S with the Prusa upgrade kit. After reassembly the XYZ calibration again gave a perpendicular axes result. I put zero values for all the hyperfine calibration points, intending to recalibrate from scratch. I was surprised to find that I could print almost perfect calibration squares across the whole print surface without having to adjust any hyperfine values. Would this suggest that it is possible to correct level imperfections in the MK42 heated base by purely mechanical adjustment? In rebuilding the printer I appear to have corrected all my levelling issues although as noted in both cases before and after the upgrade the results of XYZ calibration were perfect. I would be interested to know if anyone else has experienced this. I have another MK2S which also XYZ-calibrates perfectly but still requires non-zero hyperfine values at all calibration points to produce a flat print surface.

Re: Hyperfine bed leveling?

Interesting observation. I have been operating a MK2 with hyperfine bed levelling for some time. The XYZ calibration results gave the axes as perpendicular but I needed a range of non-zero hyperfine values at all the calibration points to achieve a level print surface. I recently upgraded the MK2 to a MK2S with the Prusa upgrade kit. After reassembly the XYZ calibration again gave a perpendicular axes result. I put zero values for all the hyperfine calibration points, intending to recalibrate from scratch. I was surprised to find that I could print almost perfect calibration squares across the whole print surface without having to adjust any hyperfine values. Would this suggest that it is possible to correct level imperfections in the MK42 heated base by purely mechanical adjustment? In rebuilding the printer I appear to have corrected all my levelling issues although as noted in both cases before and after the upgrade the results of XYZ calibration were perfect. I would be interested to know if anyone else has experienced this. I have another MK2S which also XYZ-calibrates perfectly but still requires non-zero hyperfine values at all calibration points to produce a flat print surface.

Hi Micheal,

great to hear that you got your bed leveled hardware wise during your upgrade!!!
I think the best is to try to get the bed hardware wise as leveled as possible and THEN use manual bed leveling / hyperfine bed leveling for the last um.

You can find lot of information about this topic and great results people got:
I started a Wiki about it https://github.com/3d-gussner/Prusa-Firmware/wiki as others like
https://github.com/PrusaOwners/prusaowners/wiki/Bed_Leveling_with_Wave_Springs
https://github.com/PrusaOwners/prusaowners/wiki/Bed_Leveling_without_Wave_Springs
or even by sanding the spacers people got really good results to a point where no manual bed leveling was needed.

To verify my bed I measure it with calipers (Wiki) and then with an Octoprint plug-in (Wiki).

But at the end printing the squares gives the best results as manual measuring and even the PINDA probe may not be that accurate as an human eye or feeling the 1st layer with your fingers.

Merry Christmas and a Happy New Year

Re: Hyperfine bed leveling?

Many thanks for the info Waldemar.

A Merry Christmas and a Happy New Year to you too.

Regards,

Mike

Re: Hyperfine bed leveling?

Unless the compiler is really smart, it will reserve RAM for the codes. Best to make it 'const' so it ends-up in a code section ... or don't even use it! Also, unless the initializer is shorter than the desired length of the array, it is best to let the compiler handle sizing it (use []).

Notice how the switch statement got longer and uglier the more work it had to do? Always think, "There must be a better way to code this!" Also, since it really doesn't need to do anything fancy anymore, it isn't really needed.

I also like to be able to adjust the center (I have a 9-point nylock + fiber washer mounted bed, though it is flat to less within +/- 0.010, it still needs some adjustment because of inconsistent PINDA response).

I haven't tried to compile this yet, so I submit it for consideration and future copy-pasta:

for (uint8_t i = 0; i < 9; ++i) {
long correction = 0;
if (code_seen('A' + i))
correction = code_value_long();
else
continue;
float offset = float(correction) * 0.001f;
if (fabs(offset) > 0.501f) {
SERIAL_ERROR_START;
SERIAL_ECHOPGM("Excessive bed leveling correction: ");
SERIAL_ECHO(offset);
SERIAL_ECHOLNPGM(" microns");
}
else {
mbl.z_values[i / 3][i % 3] += offset;
}
}


Re: Hyperfine bed leveling?

Hi Guys,

this all looks very very good. I would like to adjust my firmware with this feature - but going to the whole 42 Post-pages is hard...
If there is the possibility to resume the code changes in the different files?

I have a MK2.5 and a MK3 with MMU2, both builded in Haribo-Mod-Style (z=220mm MK2.5 and z=320mm MK3) - so I'll try to do implement this Hyper bed leveling AND to combine it with the great working 7x7 Pinda Bed Mesh leveling.

Hope for your help!
Thank you!

Tom

Re: Hyperfine bed leveling?

Hi Guys,

this all looks very very good. I would like to adjust my firmware with this feature - but going to the whole 42 Post-pages is hard...
If there is the possibility to resume the code changes in the different files?

I have a MK2.5 and a MK3 with MMU2, both builded in Haribo-Mod-Style (z=220mm MK2.5 and z=320mm MK3) - so I'll try to do implement this Hyper bed leveling AND to combine it with the great working 7x7 Pinda Bed Mesh leveling.

Hope for your help!
Thank you!

Tom

Hi Tom,

glad to hear you want to try implement Hyperfine bed leveling to the 7x7 Pinda Bed Mesh leveling firmware.
Yeah this topic got really long with now 42 pages.
I struggled continuing the development sins Prusa-Firmware v3.2.0 got a new menu structure, i am getting closer but still need more time to figure out things.

On my Github you can compare the MK3-private_build branch to Prusa MK3 branch
https://github.com/prusa3d/Prusa-Firmware/compare/MK3...3d-gussner:MK3-private_build

All Hyperfine bed leveling codes start and end with a comment like:
// Hyperfine Bed Tuning
// End Hyperfine Bed Tuning

One of the issues is that the additional 4 bed correct values has to be stored somewhere in the eeprom.
Everytime Prusa added new feature (with eeprom values stored) I had to triple check the code and adjust it. Also it wasn't that user friendly as bed level correct values stored in the eeprom might cause issue with new stock firmware as they use the same eeprom space.

- The eeprom definition moved meanwhile from Configuration.h to eeprom.h
- In the Marlin_main.cpp is the most of the needed code. I set the max offset via gcode to +-200
- Also you can find my changes to ultralcd.cpp

My thought what should be done better:
- Change bed level correct to z-babysteps, like it is done with Live-z (the eeprom value is factor of the z-babystep that is show in display)

Hope that helps,

Waldemar

Re: Hyperfine bed leveling?

HI Waldemar,

thank you for your explanations!
I'll go through and hope for success 🙂 I'll report within the next weeks (or have to order some new eproms 😉 ).

Tom

RE: Hyperfine bed leveling?

Hi all,

So I'm going through this thread again after a year or so, and it seems to be Mk3 oriented now? 

Is there a MK2.5 hyperfine firmware?  Everything seems to be about fixing the MK3 bed (nylock or wave springs)...

Arlo

RE: Hyperfine bed leveling?

MK3, v3.7.1:

And for those of you interested - I recently tried using bed level correction - it does not work with mesh leveling; and even worse, I discovered that using temp calibration to reign in PINDA variability actually made matters worse for me.  Turns out it too is ultra prone to errors if your bed flexes as the bed warms up between 60c and 90c - temps used when th temp cal runs.  Yes, there is a bug report on the problem.

So I went one further, and tried doing a Live-Z without any mesh leveling (commented out G80).   And this showed the entire leveling system is broken.  Test: 

Print something, adjust Live-Z to get a good first layer. result = X.

Print something again, note that Live-Z is X, but nozzle is way off: adjust Live-Z, is now 2X.

Print number 3, note that Live-Z is 2X, but again nozzle is way off: adjust Live-Z, result = 3X to 4X.

Abort test for fear of burying nozzle into PEI sheet ...

RE: Hyperfine bed leveling?

Posted by: Tim

MK3, v3.7.1:

And for those of you interested - I recently tried using bed level correction - it does not work with mesh leveling; and even worse, I discovered that using temp calibration to reign in PINDA variability actually made matters worse for me.  Turns out it too is ultra prone to errors if your bed flexes as the bed warms up between 60c and 90c - temps used when th temp cal runs.  Yes, there is a bug report on the problem.

So I went one further, and tried doing a Live-Z without any mesh leveling (commented out G80).   And this showed the entire leveling system is broken.  Test: 

Print something, adjust Live-Z to get a good first layer. result = X.

Print something again, note that Live-Z is X, but nozzle is way off: adjust Live-Z, is now 2X.

Print number 3, note that Live-Z is 2X, but again nozzle is way off: adjust Live-Z, result = 3X to 4X.

Abort test for fear of burying nozzle into PEI sheet ...

 

 

Tim, that sounds like a problem people had early in the thread where they had not issued a gcode to tell the printer live z was being adjusted. Do your test prints contain an M87?

https://github.com/prusa3d/Prusa-Firmware/pull/32

RE: Hyperfine bed leveling?

M87?   I doubt it - both Marlin and Prusa say it isn't a valid command.  But I had performed a Live-Z (and saved the result) and the value was proper when I referenced it during each run; but each run I had to double the existing value with Tune to achieve a "correct" 0.2 mm layer.  I gave up when I was at -3.800 mm -- I didn't want to destroy my PEI sheet.

It appeared like the display showed the last setting, but the value in actual use started at 0 each run.  So run 1 set -0.900; run 2 set -1.800; run 3 set -2.700 ... etc.