Strange behavior with Bed Compensation

peirof

Hi,

I'm trying to print a piece of approximately 250x150x10 mm, and a strange thing happens to me …

It does not make the first layer well, in areas the Nozzle is very close to the bed, and in areas, in the exmos there are about 2 mm.

I do the following.

[[language]]
Calibrate
I adjust the point Z = 0
I do Bed Compensation.

To test if it is correct, I move the Nozzle until it rubs the Bed, and I move it in small increments 10 mm, in X and Y, positive and negative. Throughout this journey, the Nozzle grazes the Bed.

Up to here, everything normal

But when I print the piece, the separation of the Nozzle to the Bed changes a lot, from being stuck, to about 2 mm apart.

I use this Script at the start of the Slicer

[[language]]
G29 S1; Load and use the heighmap
G90; Absolute movements
G1 X0 Y0; Move to the center of the bed in X and Y
G1 Z50; Move to 50 mm in height

To force the Heigtmap to use the printer.

What can happen? Any ideas?

dc42

When you say "I do bed compensation", do you mean that you run G29, or something else?

peirof

Yes, for Duet Web Interface.

25 mm between points, and when finish, show a 3d Draw of points… Aprox 2mm of maximum desviation

dc42

2mm maximum deviation is much too high. Can you link to the displayed height map so we can see what shape it is?

peirof

Height map

This heigh Map is far from virtual bed… this time other times in near virtual bed.
Maybe that explains why there are areas that are stuck together and areas that are 2 mm
For example.... another height map

Why is this height map so far from the virtual bed? I have followed the same steps as other times …

1- Calibrate
2- Adjust the point Z = 0
3- Run Mesh Grid Compensation

contents of Height Map.csv

[[language]]
RepRapFirmware height map file v2 generated at 2018-01-14 09:27, mean error -9.173, deviation 0.799
xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
-120.00,120.10,-120.00,120.10,140.00,30.00,30.00,9,9
-10.389,-10.389, -7.833, -7.854, -8.066, -8.154, -8.246, -8.246, -8.246
 -7.933, -7.933, -8.151, -8.162, -8.203, -8.262, -8.301, -8.345, -8.246
 -8.217, -8.316, -8.474, -8.412, -8.509, -8.449, -8.524, -8.528, -8.492
 -8.599, -8.634, -8.646, -8.798, -8.713, -8.761, -8.721, -8.784, -8.761
 -8.941, -8.961, -9.023, -9.039, -9.079, -9.076, -9.036, -9.111, -9.129
 -9.289, -9.300, -9.315, -9.441, -9.366, -9.416, -9.427, -9.462, -9.414
 -9.667, -9.699, -9.662, -9.687, -9.738, -9.824, -9.737, -9.812, -9.867
-10.100,-10.100,-10.099,-10.139,-10.152,-10.189,-10.212,-10.200, -9.867
-10.100,-10.100,-10.339,-10.440,-10.466,-10.453,-10.402,-10.402,-10.402

dc42

What exactly do you do at this step:

2- Adjust the point Z = 0

You should not need to adjust Z=0 because auto calibration does that already.

peirof

With manual control… Move down in Z, until nozzle touch bed (paper) and say duet z=0

dc42

At "say Duet Z=0"do you mean you send G92 Z0, or something else?

You shouldn't need to do that, because auto calibration will already ensure that Z=0 is as accurate as possible, averaged (in a least squares manner) over all the probe points.

peirof

Some idea why can do that?

The movements with no printing object, are Ok. Nozzle sticks to bed…. But when print an object.... In periférical points nozzle is far from bed...

One question possibility... I have setup my probing radius in config.g in 120 mm, diameter 240mm.

In this case, the diagonal of the object is bigger that 240mm. It's posible how printed zones of the object are outside of probing area, nozzle don't have info of this zone, and autocalibration not in use outside the probing diameter?

dc42

During auto calibration you should probe the entire printable bed area. It's the probe points a long way from the centre that provide the most information about the printer geometry. Unfortunately it's also those probe points which are most likely to be affected by any tilting of the effector.

peirof

And… Why can the reason with finish the bed conpensation, the 3d graph is far from bed?

I suppose, that 3d graph, depends of contents of heightmap.csv... And in my case are around - 8mm. This explains why the graph it's far.... But

Why the content of heightmap.csv are around - 8mn? Another times I have used autoconpensation... Probé points are positive and near bed.
Why depends the valor of these points? How obtain Duet?

peirof

…. i love this game....

i think i have it.... Can you check, David, if this have sense....

Before:

Homedelta.g

[[language]]
G91                        	; relative positioning
G1 S1 X530 Y530 Z530 F1200 	; move all towers to the high end stopping at the endstops (first pass)
G1 X-5 Y-5 Z-5 F1200 S2    	; go down a few mm
G1 S1 X10 Y10 Z10 F360     	; move all towers up once more (second pass)
G1 Z-5 F4800               	; move down a few mm so that the nozzle can be centred
G90                        	; absolute positioning
G1 X0 Y0 F4800             	; move X+Y to the centre
G29 S1				; Usar el heighmap generado por la compensacion automatica

and slicer start script…

[[language]]
G29 S1; Usar el heighmap generado por la compensacion automatica
G90 ;Movimientos absolutos
G1 X0 Y0 ; Moverse al centro de la cama en X e Y
G1 Z50 ; G29 S1Moverse a 50 mm de altura
M929 P"log_eventos.txt" S1 ; Comenzar logging

How can you see… i haved [c]G29 S1[/c]…. Duet applies this compensation 2 times??? No?
i have erased [c]G29 S1[/c] from start code of slicer, and for the moment works well…. for the moment

This posible explanation have sense?

dc42

Running G29 S1 twice shouldn't matter; but if you run G29 S1, then set Z=0 manually, then run G29 S1 again, that might cause a problem.

peirof

One question….
If printer it's not in level.... How many degrees can compensate calibration? 1,2...20,45 degrees of slope?

Ask for this, why the table where is the printer, has and slope of 0,86 degrees

dc42

It doesn't matter if the table has a slope. What does matter is if the bed is not at right angles to the towers. RepRapFirmware can compensate for a few degrees of this type of bed tilt.