Saving G29 Bed Level Correction Matrix to EEPROM

[Roxy]

Give me some time to think about how to proceed. But the answer to your questions is easy. The Auto Bed Level Correction is always happening (if it is enabled). It happens on every move to a specified coordinate. The difference is when you do a G28, the Correction Matrix is set to Unity which means no correction happens. The math is all done to correct the coordinates. But the same coordinate comes out of the calculation as what you fed into it.

The G29 does the work to calculate a new correction matrix. At the end of the G29, the new matrix is put in place. And the instructions to move to a new coordinate (to home X & Y) get 'corrected'.

How difficult is it to manually adjust the level of your bed? We should do a G29 n4 T to see how the bed is orientated. If it is not very difficult to alter your beds level, we could orientate things such that the home operation produces more physical clearance just to prove that is what is going on. At that point, you would have Auto Bed Leveling doing its thing and working while we figure out a more elegant fix.

Also, I thought you were going to .ZIP up and post your complete file set so I could compare them to mine (and the distribution code). I can't find where that happened.

[Fri]

I have some corrections to my previous post.

I didn't realize that hitting Xhome on Repetier send a G28 XHome, so it erases the matrix.

Roxy, my bed is easy to level, but the sensor will always be triggered no matter how high you move it. G29 ends with the last probing at the lowest point.

What's so hard to grasp is that this was all working fine, I had G28 erase turned off, did one G29 and printed all day. I usually left the machine where it was after probing and just hit print.
It did a g28 and off it went. Now it does the g28 alright, but from the last position it was at (if z is triggered).

That is why I am wondering where the matrix is saved where is it stored? Could this portion of code or flash memory be screwed up?

[Fri]

Marlin_ML2_Viki_Grid_m499.rar

Roxy, here is the fw. This is the one I used successfully for month, before it went south.

[Roxy]

Marlin_ML2_Viki_Grid_m499.rar

Roxy, here is the fw. This is the one I used successfully for month, before it went south.

OK... I started looking at things... In Configuration.h you have:

#define X_PROBE_OFFSET_FROM_EXTRUDER -43 //-43
#define Y_PROBE_OFFSET_FROM_EXTRUDER -5 //-5
...
#define Z_SAFE_HOMING_X_POINT (10)//(X_MAX_LENGTH/2) // X point for Z homing when homing all axis (G28)
#define Z_SAFE_HOMING_Y_POINT (10)//(Y_MAX_LENGTH/2) // Y point for Z homing when homing all axis (G28)

I think this is going to put the probe way off the bed. If anything is obstructing its movement, this has to change. If it can just go off the bed and not hit stuff, it can probably be left alone.

-----------------------------------------------

Given you have clearance problems... These numbers seem awful tight. I think you should triple them until we get things going. Once things are going, you can shrink them to where ever makes sense. But right now, lets not try to get super tight clearance:

#define Z_RAISE_BEFORE_HOMING 4 // (in mm) Raise Z before homing (G28) for Probe Clearance.

#define Z_RAISE_BEFORE_PROBING 2 //How much the extruder will be raised before traveling to the first probing point.
#define Z_RAISE_BETWEEN_PROBINGS 2 //How much the extruder will be raised when traveling from between next probing points

-----------------------------------------------
I thought you were doing Auto Bed Leveling??? This says you are not:

//#define NUM_SERVOS 3 // Servo index starts with 0 for M280 command
...
//#define SERVO_ENDSTOPS {-1, -1, 0} // Servo index for X, Y, Z. Disable with -1
//#define SERVO_ENDSTOP_ANGLES {0,0, 0,0, 70,0} // X,Y,Z Axis Extend and Retract angles

------------------------------------------------
In Marlin_main.cpp you have:

void setup()
{
...
analogWrite(6,250);
analogWrite(2,250);

What is going on here???? Why are you doing this? What is on pins 2 & 6 ? I looked at your Pins.h and you are messing with the thermistors. I guess you did that for a reason. And it does not appear to be related to these other issues you are having. But...
-----------------------------------------------

In your G28 code (which is *OLD*) you have:

if(code_seen(axis_codes[Z_AXIS])) {
if(code_value_long() != 0) {
current_position[Z_AXIS]=code_value()+add_homeing[2];
}
}
#ifdef ENABLE_AUTO_BED_LEVELING
if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {
current_position[Z_AXIS] += zprobe_zoffset+Z_RAISE_BETWEEN_PROBINGS ; //Add Z_Probe offset distance and extra from HOMEAXIS(Z);
}
#endif
plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
#endif // else DELTA

You are missing the term in RED. I suspect this is causing problems when Auto Bed Leveling is turned on. You need to be running the current code base!
------------------------------------------------------------------------------
In the homeaxis() function, you are missing the stuff in RED because you have an older code base. Because you have the (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY) evaluating to false, that code can't lift the nozzle for you:

if (endstop_adj[axis] * axis_home_dir < 0) {
plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
destination[axis] = endstop_adj[axis];
plan_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feedrate/60, active_extruder);
st_synchronize();
}
#endif
axis_is_at_home(axis);
destination[axis] = current_position[axis];
feedrate = 0.0;
endstops_hit_on_purpose();
axis_known_position[axis] = true;

// Retract Servo endstop if enabled

#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS) {
do_blocking_move_relative(0, 0, Z_RAISE_BETWEEN_PROBINGS);
retract_z_probe();
}
#endif

-------------------------------------

You have some issues with ConfigurationStore.cpp and .h I've attached better ones. But the ones you have do not store the Bed Level Correction matrix in the EEPROM.

You have a MakerFarm printer, right? Can you move your Configuration.h file to DABC's fork and get that going with the Auto Bed Leveling? And then we can get the Bed Level Correction matrix stored in EEPROM in that code base?

This thread is for support of saving the Bed Level Correction Matrix in EEPROM. If you want help getting code base going, we can start a separate thread. My recommendation is to abandon it and grab DACB's fork and we proceed from there.

[Roxy]

One more thought... While I don't really plan on using the EEPROM saved values for my Auto Bed Level Correction matrix, I'm not opposed to putting that code into my firmware. I would just do a G29 every print and over ride the last saved value. Perhaps it makes sense for me to put that code into my firmware, and for you to cross your Configuration.h (and maybe Pins.h????) over to my code base.

If we did that.... I should be able to duplicate any problem you are seeing....

[Fri]

Roxy, sorry for the delay. I am using a FreeFab3d ML2 printer, it's a hybrid between a Mendelmax and Bukobot.

Can you start an new thread? Let me take a look at your fw tomorrow and see how easy I can implement it.

Here are some answers, I was under the impression that I am using the latest version of Zahn's Marlin.

1. The offset of the sensor from the extruder is minus -43 for x, but the position where it probes is reflecting the position of the sensor...not the extruder. So x 10mm is the sensors position.
2. Clearance is fine with 4 2 2 , it is plenty of movement and clearance for the sensor to go out and back on. I am using abl, but with a proximity sensor, no moving parts.
3. Marlin Main. Void setup, these are controlling fans, at certain temps.

The G28 issues are new to me and they may well be the problem....I will check this out asap.

Thanks so much!

[Roxy]

Roxy, sorry for the delay. I am using a FreeFab3d ML2 printer, it's a hybrid between a Mendelmax and Bukobot.

Can you start an new thread? Let me take a look at your fw tomorrow and see how easy I can implement it.

How about we proceed with me actually putting the Auto Bed Leveling Matrix saving to EEPROM into my firmware, and you crossing your Configuration.h settings over to it. Upon further thought, I don't think you will need to worry about the Pins.h file. I think we just replace the Pins.h file in my code base with what ever you have since you have a totally different printer and won't be using anything I've messed with.

And then... Everything we are doing in this thread is related to Auto Bed Leveling Matrix saving to EEPROM. It will belong in this thread!

Here are some answers, I was under the impression that I am using the latest version of Zahn's Marlin.

1. The offset of the sensor from the extruder is minus -43 for x, but the position where it probes is reflecting the position of the sensor...not the extruder. So x 10mm is the sensors position.

Yes, but here is my concern: If the probe is -43mm on the X Axis... When you home the extruder, the nozzle is going to go to 0. But the probe is going to go to -43mm on the X Axis. Do you have the clearance so it doesn't hit something? I'm guessing it is just fine or you would have already run into problems. Right?

1. Clearance is fine with 4 2 2 , it is plenty of movement and clearance for the sensor to go out and back on. I am using abl, but with a proximity sensor, no moving parts.
2. Marlin Main. Void setup, these are controlling fans, at certain temps.

The G28 issues are new to me and they may well be the problem....I will check this out asap.

Thanks so much!

OK... Hang tight! As soon as I can, I'll get the Auto Bed Level Matrix code to save it to EEPROM in my code base and post it. And then, you just cross your Configuration.h settings over to it and with luck it just runs. With that said, DACB and PrintBus are seeing some flakyness in the code base they are running and right now there is a question of what is causing it. It is entirely possible what ever is causing their firmware to misbehave is the same thing that is giving you problems.

But here is the deal... If I get the Auto Bed Level Matrix code saving to EEPROM in my code base, we will have almost identical code and it will be much easier for me to figure out what is wrong if you continue to have problems. Hopefully, what ever you see, I'll be able to duplicate.

[Roxy]

Fri, I have the Bed Level Correction Matrix saving in the EEPROM right now. I'm testing it right now on a few small prints.

Do you have to use an LCD Panel to run your printer? Can we just turn that off for now and you use PronterFace to run the printer? The reason I'm asking is I would like to take this one step at a time. If we can get my code to work correctly on your printer, then we can start changing one thing at a time until we get everything the way you want it.

[Fri]

Sure can where can I get your firmware

[Roxy]

Sure can where can I get your firmware

Everything seems to work for me. Attached is a .RAR file with my code base. We should proceed in a methodical fashion. First, see if you can get it to compile clean without any changes. Once that can be done, let's just change the printer type from:

#define MOTHERBOARD 81

to

#define MOTHERBOARD 301

and verify you can still compile clean. Let's not enable or change stuff until we can get it printing. One caution, before we can turn on your LCD Panel we have to delete a couple of routines that the Filament Change command (M600) uses in my firmware. I've added a few routines that are normally provided by the LCD Panels.

Let's concentrate on getting the X,Y,Z offsets, the bed size, the direction of travel on the axis and the servo stuff for the Auto Bed Leveling defined correctly. Once you can get it to print, we can focus on ripping out my extra stuff and getting your LCD Panel turned on.

OK?