Saving G29 Bed Level Correction Matrix to EEPROM

[Fri]

Attachment 3511

Here it is.
As a side note, I switched a US rambo with a Chinese today uplaoded the firmware and printed away. No problems, this was not with the eeprom save, just with the G28 plan bed level deletion commented out. Works like a charm. Z doesn't trigger x and y.
This makes me believe that it is either some sort of a chip/memory issue or something with the hardware....but I don't know. Will take a scope to it one of the next days.

[Roxy]

Attachment 3511

Here it is.
As a side note, I switched a US rambo with a Chinese today uplaoded the firmware and printed away. No problems, this was not with the eeprom save, just with the G28 plan bed level deletion commented out. Works like a charm. Z doesn't trigger x and y.
This makes me believe that it is either some sort of a chip/memory issue or something with the hardware....but I don't know. Will take a scope to it one of the next days.

Your bed level correction matrix is unity. Probably you did not make the change to Vector_3.cpp to get the precision required to see the matrix:

void matrix_3x3::debug(char* title)
{
    SERIAL_PROTOCOL(title);
    SERIAL_PROTOCOL("\n");
    int count = 0;
    for(int i=0; i<3; i++)
    {
        for(int j=0; j<3; j++)
        {
            SERIAL_PROTOCOL_F(matrix[count],6);        // Added by Roxy to give better precision
            SERIAL_PROTOCOLPGM(" ");
                count++;
        }
SERIAL_PROTOCOLPGM("\n");
    }
}

The reason I want to see the matrix is to see if it is 'consistent' and looks reasonable. If you are out of memory for the calculations, we probably won't get a consistent matrix. And... If it is out of memory, taking an oscilloscope to it won't help. All of the electronics will be working correctly, but the firmware can't compute the things it needs to do the job.

[Geoff]

..........10253.jpg

[Fri]

Roxy, is that what you are looking for?

Martix 2.JPG Martix 1.JPG

[Roxy]

Yes. Those correction matrix's look good. Which would imply you are not running out of memory to do the calculations.

[Fri]

Roxy,
I tried this and I am not getting it to work. As you know I have had some issues when commenting the matix erase in g28.
So, if I do the eeprom, it all save is to eeprom alright, but it doesn't make a proper g28. It homes x & y but not z and
then starts printing way high above the bed. The offset is fine, it works good with regular abl.

Question, where is the matrix saved normally.

Without the eeprom save, when I uncomment the matrix erase in g28, all is good, when commenting, at the
end of the g29 cycle, the triggered z stop is preventing x & y to go home, when lifting up a few mm it goes home.
I also noticed that it actually bed levels when homing, meaning it moves z while crossing the bed.

I don't understand why it doesn't do the same thing as if the matrix erase is on, since it only does that with g28, BEFORE
the g29 probing....

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