Bed leveling matrix to eeprom

I am trying to get the bed leveling matrix (result from probing) stored in the eeprom, to not have to level before every print.
Any ideas.

I don't think that should be too hard to do, read and write from the EEPROM happens in ConfigurationStore.cpp, you would just have to store the probing values, read them from the EEPROM, instead of actually probing the bed.

You would still have to home Z, and you will have to make sure that Z is homed at the same XY location every time, but that location could be either stored in the EEPROM or just be defined in Configuration.h. Or just have 2 homing switches.. one mounted on a servo, and one mounted the classic way.

A alternative but dirty solution could be, to just pass the values together with G29, that would do fine for testing, bit would probably be a pain to maintain.

Edited 1 time(s). Last edit at 10/07/2014 02:49PM by Ralf.

could you not just speed up the process of auto homing. so you can go get a cup of coffee and when you come back it has already homed an started to print.

Unless you are probing a lot of points, I'm not sure I see what the advantage is. You still have to wait for the hot end to heat up in most cases. For me, the auto level probes 4 points but the hot end has started heating while the probes are being done. After probing, it starts printing within about 30 seconds. I think the whole probing process takes less than 90 seconds for me.

i'm not sure what the advantage to accuracy of the calibration print to store the data in eprom. the calibration settings will change with the time of day, temperature, humidity, thermal/mechanical fatigue of components. because we use cheaper materials that warp, change size during temp,humidity we came up with a calibrate per run. to reduce print start fails from adhesion to first layer. this is a golden secret that makes reprap work better than a 30,000 Stratasys.

if you want to store calibrations in eprom why even bother getting a more accurate print?


that said, you would want to look at the g29 command functions, find a way to take your values and plug them into the variables. i would have commands on the sd card that when read would calibrate machine at start up. probably a file named probe.gco, or probe.ini so look at how the printer self initializes from sd card as well.

this would reduce to print time if printer was already heated up and if probe was only method to home z axis.


this all being said, you could remove the reset of g29 from the G28 code and only need to calibrate 1 time per reset of the printer. this seems like a better use of resources, but calibration can go out of whack the further the time away from calibration.

Thanks guys!

The advantages are clear, no excessive wear on the z axis, it moves up and down 18 times when doing a grid probing. The g29 would only have to be done when the prints/ first layers are not good or a bed or nozzle change.

Kind of like an inkjet, you don't clean the nozzle before every print.

James Daniel, I am using it now with a once a day g29, removed the reset from g28 and it works great. I agree with you that heat and other
things affect the bed to nozzle distance, but like I said, it works like a charme on two machines. That is why I am trying to get it onto the eeprom.

Ralf, should it look something like that?
EEPROM_WRITE_VAR(i,plaPreheatHotendTemp);
EEPROM_WRITE_VAR(i,plaPreheatHPBTemp);
EEPROM_WRITE_VAR(i,plaPreheatFanSpeed);
EEPROM_WRITE_VAR(i,absPreheatHotendTemp);
EEPROM_WRITE_VAR(i,absPreheatHPBTemp);
EEPROM_WRITE_VAR(i,absPreheatFanSpeed);
EEPROM_WRITE_VAR(i,zprobe_zoffset);

EEPROM_WRITE_VAR(i,plan_bed_level_matrix[3*0 + 0]);
EEPROM_WRITE_VAR(i,plan_bed_level_matrix[3*0 + 1]);
EEPROM_WRITE_VAR(i,plan_bed_level_matrix[3*0 + 2]);

EEPROM_WRITE_VAR(i, plan_bed_level_matrix[3*1 + 0] );
EEPROM_WRITE_VAR(i, plan_bed_level_matrix[3*1 + 1] );
EEPROM_WRITE_VAR(i, plan_bed_level_matrix[3*1 + 2]);

EEPROM_WRITE_VAR(i, plan_bed_level_matrix[3*2 + 0] );
EEPROM_WRITE_VAR(i, plan_bed_level_matrix[3*2 + 1] );
EEPROM_WRITE_VAR(i, plan_bed_level_matrix[3*2 + 2] );

Sorry, haven't had the time to look deeper at it..

After a quick at the code, in Marlin_main.cpp it looks like the probed values is stored in eqnBVector[], I would just store and retrieve the values from this array, and then skip the actual moving around and probing stuff, but still let the code do all the calculation.