Mesh bed leveling on 1.18 (and 1.20+1)

GrodanB

Seem like the severe faults was due to the old sensor… just needed to spend more money on my printer...

Have not checked all but decided to just mesh level and print after changing and it worked... does not look like the mirroring feature is still there.

I'm investigating further... SO weirdness is less... and now I "only" have to understand the coordinates...

Thanks for the help so far. Seems like the SMD version is a real big step in getting more reliable results.

GrodanB

I FOUND THE FAULT…

Finally I have now gotten to the point where I now understand why the Duet seem totally weird.

Here is my script that seems to work:

[[GCode]]
M561                    	; clear any bed transform, otherwise homing may be at the wrong height
G31 X0 Y0                	; don't want any probe offset for this
T0                          	; select first hot end
G91                         	; Relative coordinates
G1 Z4 F6000                 	; Lower bed to avoid hot end dragging in bed.
G1 X-350 Y-240 F3000 S1     	; move up to 240mm in the -X and -Y directions until the homing switches are triggered
G1 X6 Y6 F600               	; move slowly 6mm in +X and +Y directions
G1 X-10 Y-10 S1             	; move up to 10mm in the -X and -Y directions until the homing switches are triggered
G90                         	; Absolute coordinates
G1 X150 Y100 F3000          	; Go to bed center and home the Z axis
G30                         	; Home Z-axis			    
M557 X25:300 Y12:188 S25     	; Bed level from X25Y12 to X300Y188 in ?mm increments
G29 S0                      	; Auto Bed Level and create report	
; Z probe parameters
G31 T1 P500 X-25.2 Y0.0 Z1.78
G1 X70 Y200 F3000           	; Dock after bed level. Move first in front of docking notch
G1 X70 Y235 F3000           	; Dock after bed level

The reason for my problem was simply that the G31 that was run in config-override palaces the probe outside T0 print range… Now I begin with removing that... (G31 X0 Y0) and suddenly it works...
But still does not probe X300 column wonder why? Last is X285 which nicely adds with 25 to X300...

Anybody who can explain that?

GrodanB

Found that to… Wow sometimes 18 years in software development helps...

This line

[[GCode]]
M557 X25:300 Y12:188 S25     	; Bed level from X25Y12 to X300Y188 in ?mm increments

```Need to be:

[[GCode]]
M557 X25:301 Y12:188 S25 ; Bed level from X25Y12 to X300Y188 in ?mm increments

One more that allowed then the mesh leveling works as I want…

Maybe some future improvement in the firmware? or is this wrong?

Also run the repeat-ability test of the probe:
M98 P0:/macros/ProbeRepeatability
G32 bed probe heights: 0.054 0.055 0.054 0.054 0.053 0.053 0.054 0.054 0.054 0.054 0.050 0.053 0.053 0.054 0.052 0.051 0.053 0.053 0.052 0.052 0.053 0.052 0.052 0.054 0.051 0.051 0.052 0.052 0.053 0.053 0.053 0.054, mean 0.053, deviation from mean 0.001

The IR probe that is sold on the Duet site is clearly repeatable... Really nice to have this run. Now I most likely never need to run it again...

Only problem with this is that the map is 25mm offsetted... That is that when the T0 is on X25 the probe is at X0... realy wish that I could get this result using the probe coordinates instead... or I manually shift the height map... that is

[[ height map.]]
RepRapFirmware height map file v2 generated at 2018-00-07 21:10, mean error -0.083, deviation 0.100
xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
25.00,301.00,12.00,188.00,-1.00,25.00,25.00,12,8
-0.259, -0.271, -0.277, -0.247, -0.212, -0.109, -0.104, -0.103, -0.149, -0.199, -0.314, -0.343
...

to

[[ height map.]]
RepRapFirmware height map file v2 generated at 2018-00-07 21:10, mean error -0.083, deviation 0.100
xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
0.00,276.00,12.00,188.00,-1.00,25.00,25.00,12,8
-0.259, -0.271, -0.277, -0.247, -0.212, -0.109, -0.104, -0.103, -0.149, -0.199, -0.314, -0.343
...

dc42

The question is, what do you most need to correct for: the bed being uneven, or the height of the print head not being constant e.g. because the rods that it travels on sag under the weight?

If the rods don't sag at all but the bed is uneven, then the height map is correct as it is, because it is the probe that gets positioned at the probe points, not the nozzle.

If the bed is perfectly flat but the rods sag or are bent, then you are right, the height map is offset. But you can fix it by setting the XY offset of the probe to zero in G31 and adjusting the M557 grid definition to avoid probing off the edge of the bed.

If part of the problem is the bed and part is the rods, then the only solution I know of is to use the nozzle itself as the Z probe.

GrodanB

Everything looks like rod sag.

If you look at the code above I do remove any probe offset to get the probe to probe the two last columns.

Of this only the X=300 cannot be reached….

Also I needed to go beyond max to get it to use max... (301 instead of 300 for X)

So by removing the probe position with G31 I got one more probe column.

This gives me the questions

1. Why 301?
2. What does the duet do when printing in the columns that is not probed?
3. Is it ok to just change the start and end for X in the height map file to shift the file 25mm towards origo?

dc42

1. Because your X offset is 25.2 and 275+25.2 = 300.2 which is greater than 300.

2. It extrapolates the average tilt of the bed.

3. Yes.

GrodanB

Ok… Then I understand.

Why not truncate? Seems like wasteful of data just for 0.2 mm...

Need to check but I'm quite sure it did not use 300 even if G31 x0 y0... Is this not removing the 25.2 offset?

As stated in https://www.duet3d.com/forum/thread.php?pid=34951#p34951 the last column is not used… Then in then next I got it probe at X=300 buy using 301...

Will check again.

Extrapolation, is that using the neighboring measure points or the complete bed?

Makes more and more sense now... One day I understand this to...

Thanks

GrodanB

Got the dual z motor working.
Sag problem of course is still there but wow… What a test print I got, seems like the printer just got to a new level.

Get the best coverage of measure points if I clear the probe offset and navigate using the nozzle. And then move the table accordingly manually.

That's a minor issues that I now can handle..

But suddenly using the LCD to move the z axis 50 mm the bed moved very fast (really scary since I never seen it before) but worked super fine...

Wonder why I never seen this before. But thanks for a nice function.

So to wrap this up,

if you do not have the IR with surface mounted transmitter/receiver I strongly recommend that.
if you have more than one z axis motor and a driver to use I strongly recommend that to.
- An update to the wiki how to set up the z axis where it is clear that most of the z axis setup is copied automatically and that you do not need Z10:10 to set the speed
As recommended at E3D's forum I run the calibration multiple times and four seem like the magic number. Duet report 0.000 deviation and regardless how exact that is I don't expect better than that.

dc42

The speed at which the jog controls move the bed will be limited to the value you specify in the Z parameter of your M203 command in config.g. So if you are uncomfortable with it moving that fast, you can reduce it.

If it is moving faster than before, check that you haven't inadvertently increased the Z steps/mm.

GrodanB

Was just scary since I have not experienced it. Honestly it's super.

Yes, it might be a zero that was not there before… But I keep it since it seems like the bed compensation like a fast bed and with the duex it seems like it has no repeatability problems at that speed.