Mesh compensation which accounts for G10 X&Y tool offsets

SanderLPFRG

@dwuk3d @fcwilt
Great to hear you're working on this as well!

We also have an index with dual HAQ-XY kinematics. Initially, we aimed to compensate using the micro-Z, but due to the mounting system and the materials of our bed, we observed that the bed deforms symmetrically over the center. As a result, we can handle the compensation using the gantry, at least in mirror mode. For duplication, this is still the approach we want to pursue.

Regarding the applied mesh location, if you check the X and Y coordinates in DWC, it prints from approximately X-25 to X25. This means the height map is being applied within those coordinates. I see two possible solutions:

Parsing the CSV file to shift all points by X+150mm, which would require some post-processing.
Trick RRF into probing the heightmap at X-150mm instead. I believe this could be automated using meta commands, perhaps something like:

var dualprintingoffset = 150

; Start mesh offsetting
G91 ; relative movements
G1 X-{var.dualprintingoffset} ; move X to offset
G92 X{move.axes[0].machineposition + var.dualprintingoffset}; set position back to original
G90

; Actual position is now 150mm offset compared to assumed position

; Define adaptive mesh area around X=0
M557 X{var.printxmin, var.printxmax} Y{var.printymin, var.printymax} P{var.pointsx, var.pointsy}
G29 ; Measure bed. 

; Machine assumes this is around X=0 position, while it is actually measuring offset area

; Reset mesh offsetting
G92 X{move.axes[0].machineposition - var.dualprintingoffset}; set position back to original
G90

fcwilt

@SanderLPFRG

But you didn't say why you think the firmware doesn't take into account the tool offsets when applying mesh compensation.

Frederick

SanderLPFRG

@fcwilt said in Mesh compensation which accounts for G10 X&Y tool offsets:

But you didn't say why y

Ah, my bad!

I have two reasons to believe it doesn't compensate correctly:

In the X-200 to X-100 range, the Z-offset slopes slightly downward, whereas from X-100 to X100, there's a very slight bulge. When I touch the Z-axis during printing, I can feel it compensating for the bulge, even though it's printing in the slanted area.
If I only probe the middle area but print outside this probed mesh, it still actively compensates. I believe RRF doesn’t extrapolate beyond the probed area, so I assume it’s applying compensation based on the middle section.

fcwilt

@SanderLPFRG

Thanks.

Anything is possible but I find it hard to believe that no one has noticed a compensation problem like this.

Has @dc42 made any remarks to you regards this issue?

In any case tomorrow I will run a test to see if mesh compensation works the way I think it does or not.

Frederick

fcwilt

@SanderLPFRG

Hi,

Well I've done some preliminary testing.

I created, by hand, a heightmap (X range from -90 to +90, Y range from -90 to +90) that had extreme Z offsets,

Z offset by X range

X=-90 to -54 : Z offset 0
X=-18 to +18 : Z offset 5
X=+54 to +90 : Z offset 0

I then created some macros.

Two to turn mesh compensation on and off
Two to set the tool X offset to either +90 or 0
Three to do G53 moves to -90, 0, +90

My testing revealed what I thought to be true.

Mesh compensation takes tool offsets into account.
If the tool is outside the height map nothing seems to be done.

Frederick

SanderLPFRG

@fcwilt So If I understand correctly;

If I have a mesh present at X-200 to X-100 and print at X-50 to X50 with a G10 offset of -150, will it still print with the correct compensation?

fcwilt

@SanderLPFRG said in Mesh compensation which accounts for G10 X&Y tool offsets:

@fcwilt So If I understand correctly;

If I have a mesh present at X-200 to X-100 and print at X-50 to X50 with a G10 offset of -150, will it still print with the correct compensation?

Yes, that is what my testing confirmed.

Keep in mind that when mesh compensation is active, movements done from the "jog" buttons on the DWC are still affected.

With the heightmap I tested having a Z range of 0mm to 5mm it was easy to see the mesh compensation adjustment being made as I moved the tool around from the DWC.

Frederick

SanderLPFRG

@fcwilt said in Mesh compensation which accounts for G10 X&Y tool offsets:

ed having a Z range of 0mm to 5mm it was easy to see the mesh compensation a

Smart testing Idea,

Can you share the simple CSV you made?? Maybe our issue lies with having both X and U mapped to the X movements? I wonder if it then follows with the X or the U axis?

fcwilt

@SanderLPFRG said in Mesh compensation which accounts for G10 X&Y tool offsets:

@fcwilt said in Mesh compensation which accounts for G10 X&Y tool offsets:

ed having a Z range of 0mm to 5mm it was easy to see the mesh compensation a

Smart testing Idea,

Can you share the simple CSV you made?? Maybe our issue lies with having both X and U mapped to the X movements? I wonder if it then follows with the X or the U axis?

I will have to create a new one.

I simply used G29 to create a heightmap of the desired number of points, then edited the heightmap Z values to all 0.00, then selectively edited certain ones to 5.00, for the X axis only.

I will post one later today.

Frederick

SanderLPFRG

@fcwilt I managed to make one as well

Testing I just did;
Height map of +5 , 0, +5, so a V shape loaded

When selecting and jogging with Left toolhead, it follows the path correctly, and changes the Z-compensation direction perfectly at the middle of the whole bed
When selecting and jogging with Right toolhead, it follows the path correctly, and changes the Z-compensation direction perfectly at the middle of the whole bed
When selecting the mirror tool (see config below), it still applies a V-shaped bed correctly, but it offsets the mesh as well, so then it is mirroring at the quarter of the whole bed

config;

; Tool Left
M563 P0 S"Left" D0 H2 X0 F0     ; define tool 0
G10 P0 X0 Y0 Z0                 ; set tool 0 axis offsets
G10 P0 R0 S0                    ; set initial tool 0 active and standby temperatures to 0C

; Tool Right
M563 P1 S"Right" D1 H3 X3 F1    ; define tool 1
G10 P1 U0 Y0 Z0.15       ; set tool 1 axis offsets
G10 P1 R0 S0                    ; set initial tool 1 active and standby temperatures to 0C

; Tool Mirror
M563 P2 S"Mirror" D0:1 H2:3 X0:3 F0:1     ; tool 2 uses both extruders, hot end heaters and fans, and maps X to both X and U
G10 P2 X150 Y0 U-150 S0 R0                      ; set tool offsets and temperatures
M567 P2 E1:1                                    ; set mix ratio 100% on both extruders

Expected behavior would be to compensate and move in 1 direction only, when mirrored mode is selected (when moving from outside to the middle of the bed

SanderLPFRG

@fcwilt Here are some videos;

Height map was set at 50 , 0 , 50 to make it really clear for the video
Movement Left printhead; https://photos.app.goo.gl/FJuenGCBoZD6ia7j6
Movement Right printhead; https://photos.app.goo.gl/8H9C4EzgjiuiZuvc7
Movement Mirrored; https://photos.app.goo.gl/6M6dbW1AvHj1x8A36

(uploaded like this because of limited upload size)

fcwilt

@SanderLPFRG

Mesh compensation cannot work for two printheads at the same time - it could adjust the bed for one or the other, but not both.

The video suggests it is applying the entire heightmap twice, once to the left half and again to right half of the bed.

Which, in a way, makes sense since mirroring essentially splits the bed into two equal parts.

However it does no good at all as the heightmap doesn't match either half of the bed.

Seems to me you must turn off mesh compensation when mirroring.

Frederick

dc42

@fcwilt said in Mesh compensation which accounts for G10 X&Y tool offsets:

If the tool is outside the height map nothing seems to be done.

What should happen is that the compensation is applied based on extrapolating a plane that represents the average of the height map.

fcwilt

@dc42 said in Mesh compensation which accounts for G10 X&Y tool offsets:

What should happen is that the compensation is applied based on extrapolating a plane that represents the average of the height map.

I will go back and re-test to see if I can verify that.

I didn't see anything obvious during the first test.

Thanks.

Frederick

SanderLPFRG

@fcwilt @dc42

Mesh compensation cannot work for two printheads at the same time - it could adjust the bed for one or the other, but not both.
The video suggests it is applying the entire heightmap twice, once to the left half and again to right half of the bed.
Which, in a way, makes sense since mirroring essentially splits the bed into two equal parts.
However it does no good at all as the heightmap doesn't match either half of the bed.

Theoretically it should not, but yet it does actively apply a mesh. It indeed looks like it is applying the same heatmap twice, but in any case it would be better to keep the mesh origin in the middle, and only use the left side. The physical bed does not move.

In our case it is definitely not ideal, nor perfectly mirrored along X=0, but it definitely is significantly better to compensate more than nothing.

I currently got it working with this code;

G1 X0 Y0 F6000 Z10 ; move to controlled position while G90
G91; set to relative
G1 X{-var.dualprintingoffset} ; move X to offset position
G92 X0; Force new position to X=0
; Actual position is now 150mm offset compared to assumed position
M557 X{var.printxmin, var.printxmax} Y{var.printymin, var.printymax} P{var.pointsx, var.pointsy} ; Define adaptive mesh area around duplication position
G29 ; Measure bed. 
; Machine assumes this is around X=0 position, while it is actually measuring offset area
G1 X0 Y0 F6000 Z10 ; move back to controlled position
G92 X{-var.dualprintingoffset}; set position back to original X=0

fcwilt

@SanderLPFRG

Yes, it does apply compensation but it is using the heightmap for the entire bed and applying it to each half.

What you need to do is take the heightmap for the entire bed, make a copy, and edit it so the numbers for just the left half constitute a heightmap for the entire bed.

Then when mirror is active at least the left side will get accurate mesh compensation whereas the right will get the same which may or may be of any help.

Frederick

SanderLPFRG

@fcwilt Correct,

See the code snippet I sent above; it automatically measures a mesh that is offset by the X value of duplication.

It gives the same result as manually offsetting the CSV file.

This indeed gives a good compensation for left half, and the right half follows, which is not ideal but works better than no compensation.

Ideally, you could also do the compensation with user-defined axis ( we have a microZ which moves the X and U printhead up and down) which could be used for mesh compensation like @dwuk3d also mentioned. I guess that requires a huge overhaul of how printing with 2 printheads works in Duet tho.. We could also integrate it into a slicer (post-processing) to send a G1 X, U, Y, Z, V, and W position. But then the slicer also needs to know the mesh heightmap

fcwilt

@SanderLPFRG

What do you mean by offset?

Are you just probing the left half of the bed?

Frederick

SanderLPFRG

@fcwilt
Yes, in short.

The G-code is printing between X-50 and X50. When I measure the adaptive mesh over this area (the middle of the bed) and then print in mirror mode, the firmware applies the mesh data from X-50 to X50, even though the print is shifted to an offset region (e.g., X-150 to X-50 with a 100mm offset).

To fix this, I trick RRF into measuring the offset area (X-150 to X-50) while it believes it's probing around X0. This way, when printing, it applies the heightmap it thinks is from X0, but it's actually from the offset area where the print will take place.

dwuk3d

@SanderLPFRG I like your idea of inflating the mesh compensation and then doing some automatic measuring to see what happens - will be a really good way to test how effective any slicer, or post processor created 'microZ' based mesh compensation is working.

Thinking about doing the mesh compensation in a post processor, which relies on a reasonably up to date mesh file being available offline, I can think of a couple of strategies to how this could work in practice.

a). Do some sort of auto check like you are doing for a few of the worst sample points before every print - and if they are not within an acceptable range - then stop the print and request that it is re-sliced with an up to date mesh file.

b) Another alternative might be to just do a mesh in every print - and then create in the post processor some code that checks a few points in the mesh file to make sure that they are more or less the same as the offline mesh file used to create the print.

Obviously though the ideal would be for RRF to handle Micro Z lifters - but as mentioned I suspect that would get quite complicated - especially when you start going to 4 tools and beyond.