Hyperfine bed leveling?  

Page 21 / 22
  RSS
PJR
 pjr
(@pjr)
Antient Member Moderator


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

Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…...
Posted : 23/10/2018 12:04 pm
thai.b
(@thai-b)
Eminent Member

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

Posted : 23/10/2018 3:14 pm
3d-gussner
(@3d-gussner)
Reputable Member


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

Posted : 23/10/2018 6:29 pm
3d-gussner
(@3d-gussner)
Reputable Member



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?

Posted : 23/10/2018 6:43 pm
PJR
 pjr
(@pjr)
Antient Member Moderator


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

Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…...
Posted : 24/10/2018 12:23 am
thai.b
(@thai-b)
Eminent Member

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 😛

Posted : 24/10/2018 12:49 am
thai.b
(@thai-b)
Eminent Member

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

Posted : 24/10/2018 1:55 pm
Pete
 pete
(@pete)
Trusted Member



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. 😉

Posted : 04/11/2018 12:24 pm
Saij
 saij
(@saij)
Eminent Member

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.

...
Posted : 18/11/2018 9:55 pm
michael.e4
(@michael-e4)
Active Member

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.

...
Posted : 20/12/2018 11:36 am
3d-gussner
(@3d-gussner)
Reputable Member


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

Posted : 20/12/2018 12:25 pm
michael.e4
(@michael-e4)
Active Member

Many thanks for the info Waldemar.

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

Regards,

Mike

...
Posted : 22/12/2018 1:27 pm
andrew e..m
(@andrew-e-m)
New Member

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;
}
}

Posted : 02/01/2019 4:52 pm
tom.m9
(@tom-m9)
Active Member

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

Posted : 16/02/2019 1:06 pm
3d-gussner
(@3d-gussner)
Reputable Member


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

Posted : 16/02/2019 2:37 pm
tom.m9
(@tom-m9)
Active Member

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

Posted : 17/02/2019 9:09 pm
arlo.i
(@arlo-i)
Eminent Member

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

...
Posted : 08/08/2019 12:36 am
Tim
(@tim-m30)
Famed Member

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 ...

 

 

This post was modified 2 months ago by Tim
It is always wise to get more than one opinion......
Posted : 08/08/2019 1:05 am
BillCampbell
(@billcampbell)
Reputable Member
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

Bill
Tagaytay City, Philippines
Founder member of Philippines Prusa Printer Owners FB Group
Sponsor Pillars of God Academy in Bacoor...
Posted : 11/09/2019 6:51 am
Tim
(@tim-m30)
Famed Member

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. 

It is always wise to get more than one opinion......
Posted : 11/09/2019 9:49 am
Page 21 / 22
Share:

Please Login or Register