Bed mesh compensation not applied to all the tools

sebkritikel

@sylvain said in Bed mesh compensation not applied to all the tools:

Here it is.

Board: Duet 2 Ethernet (2Ethernet)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)

tpost1.g tpost0.g tfree3.g tfree2.g tfree1.g tfree0.g config.g tpre3.g tpre2.g tpre1.g tpre0.g tpost3.g tpost2.g

I made severall tests again.

I can see bed levelling on T2 (the fist tool used).
When switched to T3, no bed levelling.

Thanks !

G29 S1 is commented out (turned off) in your tpost3.g (and your tpost2.g you just uploaded!!!) whereas it is not commented out (turned on) in your tpost1.g.

In addition to that, like @Phaedrux said, some of your tfree files have G29 S2 still active. Going from T0 to some other tool, you are disabling mesh compensation via tfree0.g, but then because it is G29 S1 is commented out in T2 and T3 it wont turn back on.

Phaedrux

Tfree1 tfree0 still has

;mesh levelling off
G29 S2

And you've commented out all the G29 S1 to turn them on. Just remove all references to G29 in your tool files.

duetlover

@Phaedrux said in Bed mesh compensation not applied to all the tools:

M98 P"config.g"?

=> no error

I will test with all G29 commented.

But as I told you I only use T2 and T3.

How could G29 in T0 or T1 could affect my print ?

All the more the print starts with T2 and bed levelling is active for this first tool.

Keep you updated !

sebkritikel

@sylvain said in Bed mesh compensation not applied to all the tools:

@Phaedrux said in Bed mesh compensation not applied to all the tools:

M98 P"config.g"?

=> no error

I will test with all G29 commented.

But as I told you I only use T2 and T3.

How could G29 in T0 or T1 could affect my print ?

All the more the print starts with T2 and bed levelling is active for this first tool.

Keep you updated !

How high (in millimeters) is the object you are printing when the printer changes from T2 to T3?

duetlover

The change to T3 is done at about 3 mm.

I also thought at M376 H15

but the bed levlling is stopped before.

Thanks

Phaedrux

You have T-1 in your config to deselect all tools, so perhaps that's when the tfree files are getting called.

Removing all references should tell us.

duetlover

T-1 and ALL G29 commented => same results...

If it could help, here is the part of gcode file when T3 is selected for the first time :

G1 X199.790 Y94.848 E0.0216
G1 X197.752 Y92.810 E0.1258
G1 X198.247 Y92.810 E0.0216
G1 X199.790 Y94.353 E0.0952
G1 X199.790 Y93.858 E0.0216
G1 X198.742 Y92.810 E0.0647
G1 X199.237 Y92.810 E0.0216
G1 X199.790 Y93.363 E0.0341
G1 X199.790 Y92.868 E0.0216
G1 X199.732 Y92.810 E0.0036
G1 E-4.0000 F4200
; layer 7, Z = 2.167
T3

G91
G1 Z5 F600
G90

G1 X200.600 Y107.666 
; feature outer perimeter
; tool H0.250 W0.010
G1 Z6.667 F120
G1 X99.205 Y91.805 F120
G1 Z1.917 F120
G1 X200.795 Y91.805 E0.1056 F300
G1 X200.795 Y108.195 E0.0170
G1 X99.205 Y108.195 E0.1056
G1 X99.205 Y91.805 E0.0170

When T2 is selected again after T3 bed levelling is running again.

sebkritikel

@sylvain said in Bed mesh compensation not applied to all the tools:

T-1 and ALL G29 commented => same results...

If it could help, here is the part of gcode file when T3 is selected for the first time :

G1 X199.790 Y94.848 E0.0216
G1 X197.752 Y92.810 E0.1258
G1 X198.247 Y92.810 E0.0216
G1 X199.790 Y94.353 E0.0952
G1 X199.790 Y93.858 E0.0216
G1 X198.742 Y92.810 E0.0647
G1 X199.237 Y92.810 E0.0216
G1 X199.790 Y93.363 E0.0341
G1 X199.790 Y92.868 E0.0216
G1 X199.732 Y92.810 E0.0036
G1 E-4.0000 F4200
; layer 7, Z = 2.167
T3

G91
G1 Z5 F600
G90

G1 X200.600 Y107.666 
; feature outer perimeter
; tool H0.250 W0.010
G1 Z6.667 F120
G1 X99.205 Y91.805 F120
G1 Z1.917 F120
G1 X200.795 Y91.805 E0.1056 F300
G1 X200.795 Y108.195 E0.0170
G1 X99.205 Y108.195 E0.1056
G1 X99.205 Y91.805 E0.0170

When T2 is selected again after T3 bed levelling is running again.

I do not know, I'm sorry. It looks OK to me.

Just conjecture, but G10 and the taper command couldn't possibly be causing this right? I see no reason for that to be the case...

G10 P3 X-0.5	Y36.7	Z-35.26				; T3

I recognize Z-35.26 is necessary.

@sylvain could you try commenting out M376 H15?

Phaedrux

@sebkritikel said in Bed mesh compensation not applied to all the tools:

Just conjecture, but G10 and the taper command couldn't possibly be causing this right? I see no reason for that to be the case...
G10 P3 X-0.5 Y36.7 Z-35.26 ; T3

I recognize Z-35.26 is necessary.
@sylvain could you try commenting out M376 H15?

Worth a shot.

Also, are you sure you've got G29 S1 enabled somewhere else now? Should be in the slicer start gcode or start.g at least.

duetlover

Commenting M376 solved the issue !

Thanks !

sebkritikel

@sylvain said in Bed mesh compensation not applied to all the tools:

Commenting M376 solved the issue !

Thanks !

Very interesting! @Phaedrux if this is truly the cause, I wouldn't say this is expected behavior correct? Expected behavior would be G10 tool offsets having no impacts on mesh taper?

Phaedrux

@sebkritikel I'll check with DC42 as I really have no idea.

sebkritikel

@Phaedrux said in Bed mesh compensation not applied to all the tools:

@sebkritikel I'll check with DC42 as I really have no idea.

For what its worth, I just tested it on my machine and can confirm G10 Z offsets will interact with with taper values set via M376, similar to what slyvain is seeing.

Duet2 Wifi+Duex5
3.2-beta2 (2020-10-05b2)

Set M376 H15
With T0, with no offsets in G10, moved over built plate at Z=6mm. Could see ballscrews moving for compensation

Put an artificial offset on T1 (IDEX) of G10 P1 Y.22 U.00 5 Z-20

Selected T1, bed moved down to account for Z-20 offset. Still read 6mm.

Moved T1 over build plate - no ballscrew/stepper movement for bed compensation.

Homed all axes, reset T1 offsets to G10 P1 Y.22 U.00 5 Z.3

Moved T1 over build plate (at Z=6mm), could see ballscrews/stepper moving for compensation.

duetlover

Happy to have contribute to find a bug

sebkritikel

@sebkritikel said in Bed mesh compensation not applied to all the tools:

@Phaedrux said in Bed mesh compensation not applied to all the tools:

@sebkritikel I'll check with DC42 as I really have no idea.

For what its worth, I just tested it on my machine and can confirm G10 Z offsets will interact with with taper values set via M376, similar to what slyvain is seeing.

Duet2 Wifi+Duex5
3.2-beta2 (2020-10-05b2)

Set M376 H15
With T0, with no offsets in G10, moved over built plate at Z=6mm. Could see ballscrews moving for compensation

Put an artificial offset on T1 (IDEX) of G10 P1 Y.22 U.00 5 Z-20

Selected T1, bed moved down to account for Z-20 offset. Still read 6mm.

Moved T1 over build plate - no ballscrew/stepper movement for bed compensation.

Homed all axes, reset T1 offsets to G10 P1 Y.22 U.00 5 Z.3

Moved T1 over build plate (at Z=6mm), could see ballscrews/stepper moving for compensation.

@dc42 this comment should summarize the thread, while tested on an IDEX machine, should be easy to verify on a toolchanger.

dcw259

I've had the same problem with mesh bed compensation and tapering.
Tool offsets were around 6.5mm for T0 and T1 and 3mm for T2 and T3

With M376 H5 (taper off until 5mm) I barely noticed any z adjustments on T2 and T3 and absolutely none on the first two tools.

To confirm, I tried M376 H15 and can see z moving cleanly on all tools.

As it seems, tools offsets is not a part of the calculation behind M376

Hardware: Duet3 MB6HC + 2x Duet 3 EXP3HC
Firmware: MB RRF3.1.1 + EXP RRF3.1.0

dc42

@sylvain @sebkritikel @dcw259, I confirm that mesh compensation taper does not work properly when the tool has a Z offset.

I can squeeze a fix into RRF 3.2 stable, but the fix needs to be tested first. Are any of you running RRF 3.2RC2 and would be open to running an internal build that includes a proposed fix?

sebkritikel

@dc42 said in Bed mesh compensation not applied to all the tools:

@sylvain @sebkritikel @dcw259, I confirm that mesh compensation taper does not work properly when the tool has a Z offset.

I can squeeze a fix into RRF 3.2 stable, but the fix needs to be tested first. Are any of you running RRF 3.2RC2 and would be open to running an internal build that includes a proposed fix?

I am currently running 3.2-beta3.2, but I can upgrade through RRF 3.2RC2 and/or upgrade to an internal build to test the fix.

dc42

@sebkritikel, if you are running 3.2beta3.2 then I recommend you upgrade to 3.2-RC2 anyway.