Auto_Bed_Leveling: Enhanced G29 command

[Roxy]

Roxy,
I have some questions :

Why do I have some "+-" before some values of the topography ?

  --0.22982 +0.00091 +-0.17644
  -0.22815 --0.00807 +-0.13478
  -0.17552 +0.19074 --0.04623

I have "+", "-", "--", "+-" !!! I see in your code, you add some extra for the font used in pronterface. But what I understand, is that you double the sign, so why do I have many "+-" ?

Which set of code do you have printing the bed topology? Which #define ORIGIN_???_??? is enabled?

I looked, and my guess is you have ORIGIN_FRONT_RIGHT defined ???? If so, I think you found a bug. Let's change that code to be:

#ifdef ORIGIN_FRONT_RIGHT
    for(yy=0; yy<n_points; yy++ {
        for(xx=0; xx<n_points; xx++) { 
            SERIAL_PROTOCOLPGM(" ");
            if ( eqnBVector[ (n_points*n_points)-yy-(xx*n_points)-1 ]-mean >= 0.0)
                SERIAL_PROTOCOLPGM("+");
            else
                SERIAL_PROTOCOLPGM("-");    // we need this extra - because Proterface uses a preportional
                                // font and it causes the columns to not line up nice without it.
            SERIAL_PROTOCOL_F( eqnBVector[ (n_points*n_points)-yy-(xx*n_points)-1 ]-mean, 5);
        }
        SERIAL_PROTOCOLPGM(" \n");
    }
#endif  // ORIGIN_FRONT_RIGHT

In addition, I do not understand the values of this matrix ; here are the values :

Bed x: 78.00 y: 71.00 z: 3.21
Bed x: 101.00 y: 71.00 z: 3.67
Bed x: 124.00 y: 71.00 z: 3.62
Bed x: 78.00 y: 97.00 z: 3.44
Bed x: 101.00 y: 97.00 z: 3.43
Bed x: 124.00 y: 97.00 z: 3.63
Bed x: 78.00 y: 123.00 z: 3.27
Bed x: 101.00 y: 123.00 z: 3.31
Bed x: 124.00 y: 123.00 z: 3.40
Eqn coefficients: a: 0.01 b: -0.00 d: 3.24
Mean of sampled points: 3.442588

With Libre Office Calc, my matrix is

-0,232588	-0,002588	-0,172588
0,227412	-0,012588	-0,132588
0,177412	0,187412	-0,042588

Some values mismatch too much with the topography given by the code ... I do not know why ?

Thanks a lot

I haven't actually run the ORIGIN_FRONT_RIGHT code. (And that is why it is easy for a bug to sneak in.) I've made those changes but we need to check them out. How about you re-run it with the suggested change. And we will wrestle it to the ground with the new numbers?

[AbuMaia]

I've just discovered through updating to the latest ErikZalm Marlin (pulling all the goodies from beckdac's Marlin in the process) that if one forgets to put the #define ORIGIN_* code in configuration.h, the topo routine will still run, it just won't output any numbers. It took me two attempts to figure out what the problem was. At least it didn't crash & burn when it couldn't find any defined origins.

[Roxy]

I've just discovered through updating to the latest ErikZalm Marlin (pulling all the goodies from beckdac's Marlin in the process) that if one forgets to put the #define ORIGIN_* code in configuration.h, the topo routine will still run, it just won't output any numbers. It took me two attempts to figure out what the problem was. At least it didn't crash & burn when it couldn't find any defined origins.

Yes, that was delibertly coded to make sure it would not cause any side effects if no display perspective was specified. And in fact, if you have reasons to view it from multiple perspectives it is safe to specify more than one origin. In that case, you need to figure out out which one is which one because there won't be any titles over the maps.

[DarkAlchemist]

Here is an old problem that I had forgotten about but because I am redoing my printer I stumbled upon again and I am wondering how to fix it (makes it a tad hell when trying to dial stuff in)?

Probe is 1.9mm away so I go do a G28 and all looks fine but when I do a M114 I see Z is at 6.9 BUT it really isn't because when I do a move of 6.9 it is still in the air instead of touching the glass which is where I needed it to be.

Any ideas?

[AbuMaia]

you need to figure out out which one is which one because there won't be any titles over the maps.

Seems easy enough to fix, just added a SERIAL_PROTOCOLPGM("Origin: Back Right \n"); etc to the top of each #ifdef ORIGIN_BACK_RIGHT etc.

edit: it works

Bed Height Topography:
Origin: Front Left
--0.07360 +0.01565 +0.02315 +0.06515 +0.04815
--0.05935 +0.01365 +0.02940 +0.04940 +0.02940
--0.04510 +0.01390 +0.02990 +0.04165 --0.00110
--0.03410 +0.00765 +0.00340 +0.02115 --0.02910
--0.04235 --0.00860 --0.01885 --0.01810 --0.06135

Probe is 1.9mm away so I go do a G28 and all looks fine but when I do a M114 I see Z is at 6.9 BUT it really isn't because when I do a move of 6.9 it is still in the air instead of touching the glass which is where I needed it to be.

Any ideas?

Do a G28, then a G1 Z0. Find out at what distance above the bed the nozzle stops. Let's call that number X.

Look for this section in Marlin_main:

      if(code_seen(axis_codes[Z_AXIS])) {
        if(code_value_long() != 0) {
          current_position[Z_AXIS]=code_value()+add_homing[2];
        }
      }
      #ifdef ENABLE_AUTO_BED_LEVELING
        if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {
          current_position[Z_AXIS] += zprobe_zoffset;  //Add Z_Probe offset (the distance is negative)
        }
      #endif

Change the "+= zprobe_zoffset;" to "+= zprobe_zoffset+X;" inputting the number you found earlier for X. On my printer, it was 4.

If you do a G1 Z0 after a G29, does the nozzle touch the bed as it's supposed to?

[Drone]

Here is an old problem that I had forgotten about but because I am redoing my printer I stumbled upon again and I am wondering how to fix it (makes it a tad hell when trying to dial stuff in)?

Probe is 1.9mm away so I go do a G28 and all looks fine but when I do a M114 I see Z is at 6.9 BUT it really isn't because when I do a move of 6.9 it is still in the air instead of touching the glass which is where I needed it to be.

Any ideas?

I have no idea if this will be any help to you, but I just found the issue with my Z offset problem and it turned to be the offset was in the working EEPROM memory. Nothing I did would move the Z axis to the bed close enough to print. The answer was to send a M502 to load hardware defaults in the EEPROM and then an M500 to store the defaults into EEPROM working memory and the problem was resolved. Be sure to have the EEPROM enabled in the configuration.h. I have no idea how I put the wrong value in memory in the first place, but that was the cure for me.

[AbuMaia]

It didn't work for me. I think there's a bad calculation somewhere in my firmware that I haven't been able to find.

[Roxy]

It didn't work for me. I think there's a bad calculation somewhere in my firmware that I haven't been able to find.

Is your EEPROM turned on?

[DarkAlchemist]

I have no idea if this will be any help to you, but I just found the issue with my Z offset problem and it turned to be the offset was in the working EEPROM memory. Nothing I did would move the Z axis to the bed close enough to print. The answer was to send a M502 to load hardware defaults in the EEPROM and then an M500 to store the defaults into EEPROM working memory and the problem was resolved. Be sure to have the EEPROM enabled in the configuration.h. I have no idea how I put the wrong value in memory in the first place, but that was the cure for me.

Once I installed this I turned off all EEPROM nonsense and I have to recompile for any changes to take place. I did that because I did get caught with that issue but that isn't the problem here. I am stumped but I sense there is an issue in the code when dealing with this but where in the code the issue lies I do not know.

What I have to do is G92 Z(some large number) then I can move it down so the number it thinks it is at it really isn't but I print just fine.

[syl20]

Which set of code do you have printing the bed topology? Which #define ORIGIN_???_??? is enabled?

Oh sorry, I mistake ! My origin was set to FRONT_RIGHT althought it would be BACK_RIGHT. With this new setting, everything is OK (signal and values). Thanks a lot !

Have you tested my perl script ?