Auto_Bed_Leveling: Enhanced G29 command

[DarkAlchemist]

Scanning? I don't know what you mean. But the EEPROM capability is nice for people that are constantly tweaking settings. The problem is it can bite you in the a$$ if you never use them and suddenly your printer is taking its numbers from the EEPROM. That has happened a whole bunch on the Auto Bed Leveling.

Scanning but you might call it probing. I have seen people storing the bed leveling code and recalling it instead of scanning/probing the bed each time before print.

[Roxy]

Scanning but you might call it probing. I have seen people storing the bed leveling code and recalling it instead of scanning/probing the bed each time before print.

The currently released Marlin Firmware does not have any provisions for storing the Bed Level Correction matrix. But that would be straight forward to do. If that was added to the firmware, the most natural behavior would be it pulls it out of EEPROM and uses it unless you force the printer to do a G29 and store the updated matrix. I can see how that would be valuable to some people.

[DarkAlchemist]

For me the bed is just too flexible on an I3 and I think errors would abound.

In my situation is 3 enough or do I do 4 or 5?

[RobH2]

Mine does 9 by default. I just left it and I get spectacular results. It's takes a bit longer but when something takes 3 hours to print, what's an extra 45-seconds going to matter in the beginning? We all accept that 3D printers are finicky on a good day so all you can do to mitigate variance is a good thing.

[Roxy]

For me the bed is just too flexible on an I3 and I think errors would abound.

In my situation is 3 enough or do I do 4 or 5?

Pretty much... a 3x3 grid will work if you have your numbers dialed in. But it really depends on the repeatability of your Z-Probe. Almost for sure a 4x4 grid will work well. The question is how far can you prune it back and still get good numbers going into the Least Squares fit algorithm. And that answer depends on how accurate (and repeatable) your Z-Probe is. I have the cheapest switch available from eBay. And 3x3 works fine but I typically go 4x4.

A simple way to answer this question for yourself is do a 3x3, a 4x4 and a 5x5 grid. Take a look at the Correction Matrix that gets produced for each grid size. How much different are the numbers? I would trust the 5x5 numbers the most because those get averaged over more measurement points.

[DarkAlchemist]

More points the better the sampling the more accurate it will be but why is this ABL so slow when compared to this one? https://www.youtube.com/watch?v=1eNz1l56H5E

[Roxy]

More points the better the sampling the more accurate it will be but why is this ABL so slow when compared to this one? https://www.youtube.com/watch?v=1eNz1l56H5E

Well, that is a Delta Printer... I want one in the worst way! Of course it can move fast!!! But if you want to speed up your Auto Bed Leveling... Go into Marlin_Main.cpp and change this:

static void do_blocking_move_to(float x, float y, float z) {
float oldFeedRate = feedrate;

feedrate = XY_TRAVEL_SPEED;

current_position[X_AXIS] = X;
current_position[Y_AXIS] = Y;
current_position[Z_AXIS] = Z;

plan_buffer_line( current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder); // change to maybe feedrate/20 or feedrate/30
st_synchronize();

feedrate = oldfeedrate;
}

I'm not sure what unintended side effects it is going to have... But your Auto Bed Leveling should go faster if you make that change. You might be able to go all the way down to feedrate/1 but it will all depend on how good your printer's mechanics are.

[DarkAlchemist]

The feedrate was already fast enough it is the up and down that is tortuously slow.

[DarkAlchemist]

In the configuration.h file, find these lines:


#define EEPROM_SETTINGS
#define EEPROM_CHITCHAT

and comment each one out with // in front.

With my ABL I had to also go into Marlin_Main.cpp around line 3210 and do this

#if defined(EEPROM_SETTINGS)
case 499: // M500 Store settings in EEPROM
{
Invalidate_EEPROM_Settings(); // Roxy added function to guarintee we are using
// the default values defined in the firmware!
}
break;
#endif

else it would not compile. My chit-chat has always been commented out though.

[Roxy]

The feedrate was already fast enough it is the up and down that is tortuously slow.

Oh! Go search for: static void run_z_probe() {

That will be the function that does the actual Z Probe. There are 3 places in that function where it moves the Nozzle up and down. You will see 3 lines that have feedrate/60 in them. First it moves down to find the bed and then back up. Probably these can be made faster without a problem. But the last one (which is where it is doing the measurement) is definately more accurate at slow speed!