Mesh compensation which accounts for G10 X&Y tool offsets

SanderLPFRG

Hi!

We have a machine with a bed that sags symmetrically around the X=0 line (600mm X-width).

When printing in mirror mode, this means that the compensated Z-height should theoretically be the same for both the left and right printing toolheads.

Because mirror mode is just a regular gcode (centre at 0,0) with G10 offsets applied for X and U (and U inverted), the firmware is actively applying the bed mesh compensation for the original coordinates, while in reality, the left toolhead is printing 150mm to the left and the right toolhead is printing 150mm to the right.

Since RRF (RepRapFirmware) knows that the tool offset for X is -150, is there a way to set it up so that it compensates the mesh at the adapted X coordinate rather than the original, unadjusted coordinate?

SanderLPFRG

note;

I found that you might be able to use G10 L2 or M206. But from what I can see, this only adjusts the position of the toolhead, but still compensates the bed mesh at the original coordinates.

dwuk3d

@SanderLPFRG I wonder if you could just alter the coordinate boundaries between meshing and actual printing - or just do some sort of patching of the height map.csv file to alter the coordinate system to overcome your issue..

Looking at your other post - and your mention of micro-Z adjusters - I guess the ideal would be for the main Z gantry to stay stable and for the micro-Z adjusters to do the mesh compensation.

That is what I am intending to try and do with my IDEX design - ideally with the firmware - but probably initially with the GCODE post processor - that takes in the original GCODE, plus the height map.CSV - and add the appropriate micro Z axis adjustments to the G0/G1s etc.

Would also probably have to segment up long moves - incase they need more than one adjustment.

fcwilt

@SanderLPFRG

Since the mesh merely lays out the relationship between XY position and the required Z adjustment why do you believe, during printing, the firmware doesn't take into account tool offsets?

Frederick

SanderLPFRG

This post is deleted!

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