Auto_Bed_Leveling: Enhanced G29 command

[AbuMaia]

Roxy, what syl20 means is, no matter what value you use for n (2,3,4,etc) the Bed Level Correction Matrix displayed after G29 finishes is always in a 3x3 arrangement. Is there some averaging going on? If I do a G29 n5, the BLCM is still 3x3. I've done searches, but I haven't found any post anywhere that explains how the BLCM works, how it's used.

[Roxy]

Roxy, what syl20 means is, no matter what value you use for n (2,3,4,etc) the Bed Level Correction Matrix displayed after G29 finishes is always in a 3x3 arrangement. Is there some averaging going on? If I do a G29 n5, the BLCM is still 3x3. I've done searches, but I haven't found any post anywhere that explains how the BLCM works, how it's used.

Oh! I didn't understand that was what he meant. This is an easy question!!! It just might be a little bit difficult to answer in simple terms. The problem is you need to have Matrix Math. Its just algebra, but there is a special way matrix's operate on each other.

The generated Bed Level Correction matrix is always 3x3. And unless you are doing the original 3 point probe to determine the bed's plane, you are doing a n x n grid of probe points. All of those n x n grid probe points are averaged using a Least Squares fit to find the best approximation for the bed's plane.

But here is the deal... The way the 3D-Printers work is the nozzle is told to go to some [X,Y,Z] coordinate (and extrude material while it does that). Once the G29 is run and the bed level correction matrix is generated, those coordinates are multiplied by the correction matrix to generate a new (corrected) [X,Y,Z] coordinate. The bed level correction matrix is always 3 x 3. More input points to the least squares routine that generates it will just result in a better average of the numbers. The matrix will always be 3 x 3.

This is necessary because of how matrix math (multiplication) works. The actual function that maps the uncorrected coordinates to the new plane-normal angle is in Vector_3.cpp. It looks like this:


void vector_3::apply_rotation(matrix_3x3 matrix)
{
float resultX = x * matrix.matrix[3*0+0] + y * matrix.matrix[3*1+0] + z * matrix.matrix[3*2+0];
float resultY = x * matrix.matrix[3*0+1] + y * matrix.matrix[3*1+1] + z * matrix.matrix[3*2+1];
float resultZ = x * matrix.matrix[3*0+2] + y * matrix.matrix[3*1+2] + z * matrix.matrix[3*2+2];

x = resultX;
y = resultY;
z = resultZ;
}

If you have your [1 x 3] input matrix of [X,Y,Z] and you multiply it by the [3 x 3] bed level correction matrix, you get back out a [1 x 3] matrix with the new (corrected) [X,Y,Z] coordinates. Also note... Your bed level correction matrix that is generated by the G29 is almost unity. It has a diagonal of all numbers being almost '1.0' And when you do a G28, your bed level correction matrix is set to unity. The diagonal is 1's but everything else is 0.

Without running a G29, the new X is equal to the original X*1.0 + Y*0 + Z*0 And the new Y is equal to the original X*0+Y*1.0+Z*0 and the new Z is equal to the original X*0+Y*0+Z*1.0 In other words... The corrected coordinate are the same as the original coordinate. The input [X,Y,Z] coordinate matrix has each of its values multiplied by 1.0

But it doesn't work that way when the bed level correction matrix is no longer unity after the G29 command. When you pass in your uncorrected coordinates... say just the X part, it gets multiplied by a number that is almost 1.0 (matrix.matrix[3*0+0]) and then a small number gets added on for the Y and Z part. You add on Y*matrix.matrix[3*1+0] and Z*matrix.matrix[3*2+0]. This extra will stuff will 'rotate' the X coordinate to a slightly different position. And this same thing happens for the Y and Z parts.

[syl20]

Thanks a lot for the explanations, as my algebra lessons are (too much) far away !
I understand there is an average of the values of probes with a Least Squares method ; the BLCM is still 3x3. So, can we consider that an unflat bed (like the one with carbon fiber) is considered as a flat/rigid bed, no matter what value you use for n ?

In addition, I've seen an another great evolution for your already (very) great G29 enhancement ; instead of probing the full bed size, it is possible to probe just the printing area. It is very usefull, because you reduce the probing zone, reduce time of probing, improve the accuracy, ... ; a guy has already made this on github (https://github.com/ErikZalm/Marlin/pull/1022) ; 3 files have been changed. Is there a way to merge the code ?
Thanks

[ctcwhexdx]

Good Morning,,

I am running into an issue when I try to follow the first post for setting this up, I downloaded the most recent firmware from the link on the first post, as mine is older, made all the changes according to the first post and when I go to compile this I get the following errors:

Marlin_main.cpp:1943:2: error: #endif without #if
Marlin_main.cpp: In function 'void process_commands()':
Marlin_main.cpp:1937: error: 'dock_sled' was not declared in this scope

Now if I just compile the firmware without any modifications it compiles without any problems.

I am not sure but I think there's been some changes made to the code since this thread was started, has anyone else run into this?

I would appreciate any ideas

Thank You

[Roxy]

In addition, I've seen an another great evolution for your already (very) great G29 enhancement ; instead of probing the full bed size, it is possible to probe just the printing area. It is very usefull, because you reduce the probing zone, reduce time of probing, improve the accuracy, ... ; a guy has already made this on github (https://github.com/ErikZalm/Marlin/pull/1022) ; 3 files have been changed. Is there a way to merge the code ?
Thanks

Yes, it should be possible to merge the code together. The biggest question I would have is how does the G29 get told how big of an area to probe? Some how, that should be automated.

[Roxy]

Good Morning,,

I am running into an issue when I try to follow the first post for setting this up, I downloaded the most recent firmware from the link on the first post, as mine is older, made all the changes according to the first post and when I go to compile this I get the following errors:

Marlin_main.cpp:1943:2: error: #endif without #if
Marlin_main.cpp: In function 'void process_commands()':
Marlin_main.cpp:1937: error: 'dock_sled' was not declared in this scope

Now if I just compile the firmware without any modifications it compiles without any problems.

I am not sure but I think there's been some changes made to the code since this thread was started, has anyone else run into this?

I would appreciate any ideas

Thank You

There is a bug in the current Marlin_main.cpp at GetHub. It is missing some #ifdef's for the Z-Probe Sled. If you do a visual diff of my code against the code at GetHub you will see the missing #ifdef's :

[syl20]

Yes, it should be possible to merge the code together. The biggest question I would have is how does the G29 get told how big of an area to probe? Some how, that should be automated.

It's the slicing program like cura or slic3r that tell the G29 gcode the position and the size of the area to probe.
It would be an optionnal parameter to the G29. Without this parameter the whole bed is probing.
With a new G29 start code in slic3r (easy to do), the printing size parameter override the bed size, that's all.

[Roxy]

It's the slicing program like cura or slic3r that tell the G29 gcode the position and the size of the area to probe.
It would be an optionnal parameter to the G29. Without this parameter the whole bed is probing.
With a new G29 start code in slic3r (easy to do), the printing size parameter override the bed size, that's all.

Can Slicer tell us how big the print plate is going to be for a given print?

[syl20]

Can Slicer tell us how big the print plate is going to be for a given print?

yes, with a post processing script

[Roxy]

yes, with a post processing script

Can you show me that script? I'll modify the G29 to make use of it and probe the region that the print will be.