Maybe Bug: Redoing height maps add sometimes random offsets

[dgrat]

I think this is a firmware bug, I noticed already since a while. It is still present in 3.4.
When I redo height maps the height maps shift sometimes by a constant amount.
Here I played with a z-offset of 1.9 mm and 1.95 mm. The offset became quiet drastic (+/- up to 0.5 mm).
I noticed that behavior on all my printers. This behavior is rather random. Sometimes the height maps are fine.

The trigger height seems always correct and does not change, because the reported z-value upon triggering is always the same value.
Seems like the firmware is adding a random number to the height estimate.
After powering off the printer entirely (no reset via firmware), I often get a correct height map again.

Any ideas?

Steps to reproduce:
Duet Wifi 2
call: G31 P500 X-25.5 Y37 Z1.95

Example shows a G29 after a print I ended.

And here just after redoing after soft-reset which disappeared only after head-reset

[dgrat]

This post is deleted!

[fcwilt]

@dgrat

Are you setting the Z=0 Datum using a single G30 are the center of the bed or perhaps at one of the grid points?

You have to do that when creating the height map and when loading the height map.

Frederick

[dgrat]

@fcwilt
I thought that is only necessary before starting a print?
Where is written that G29 requires that and why the offset changes?

[bricor]

@dgrat
https://docs.duet3d.com/User_manual/Connecting_hardware/Z_probe_mesh_bed

Partway down under the heading:
Running bed mesh compensation

Establish a Z=0 datum

[dgrat]

@bricor

I wonder if G29 depends on another command e.g. g30 to create a datum.
Shouldn't be heightmap creation defined in a gcode macro which the user defines?

[Stephen6309]

@dgrat I use this for my mesh.g file, it makes sure the printer is homed, and load the heightmap.csv, if it doesn't exist, creates it:

M561 ; clear any bed transform
while iterations < #move.axes & move.axes[iterations].visible
	if !move.axes[iterations].homed
		G28
		break
M290 R0 S0    ;  clear baby stepping
G29 S1
if result > 1 ; if no heightmap.csv, make one
	G29 S0

[fcwilt]

@dgrat said in Maybe Bug: Redoing height maps add sometimes random offsets:

@bricor

I wonder if G29 depends on another command e.g. g30 to create a datum.
Shouldn't be heightmap creation defined in a gcode macro which the user defines?

G29 executes mesh.g if it exists, as it should.

The assumption is that mesh.g contains all the commands needed to create the desired height map.

And since you need to set the Z=0 Datum before creating/loading a height map mesh.g likely is going to include a G30 to set the Z=0 Datum.

Now some folks who home with a Z probe rely on that to set the Z=0 Datum. I simply include the G30 in the mesh.g file so I don't have to concern myself with what came before. Also mesh.g is going to work at the current bed temperature which might be different from the bed temperature when homing.

Frederick

[dgrat]

Thanks all for gcode and explanation

[fcwilt]

@dgrat said in Maybe Bug: Redoing height maps add sometimes random offsets:

Thanks all for gcode and explanation

Always glad to help if I can. If I cannot help I try very hard to not make things worse.

Frederick