The never-ending battle: Bed Mesh Compensation

[Diamondback]

Hey everyone,

I'd like to collect some feedback and/or spark some discussion around something weird that I may have noticed recently. But the backstory first:

I have a custom Toolchanger with a bed that has 3 individual Z motors that drive the bed via a simple kinematic mount. So before every print (in this order) I do the following:

• Home X/Y/Z
• Trim the bed via multiple G30 probes until the deviation is small enough
• Home Z again
• Create a new mesh via G29
• Run the print

Now this has always given me seemingly random issues, the trimming always works and the mesh creation also always seems to work fine, the resulting mesh looks believable etc.
However, sometimes the print just seems off, you can see the Z motors move fine, but the resulting compensation doesn't work out. Sometimes during the first layer of a single print the Z distance fits, sometimes it's too much, sometimes too little.
Prints with a large surface area to me are always hit and miss and I tend to avoid them for this reason.

However: Recently I seemed to have noticed that things work perfectly fine when the initial print goes wrong and I abort it, just to immediately restart the same print.
So basically, when I do my full calibration routine when a mesh is already active it actually seems to work...

This left me wondering and I am currently printing test samples of three different conditions:

• Unhomed, no mesh active
• Homed, no mesh active
• Homed, mesh already active

Now, did you ever encounter something else like this? Maybe purely creating the mesh doesn't always actually make use of it?
I've posted my actual config and pre-print routines many times before related to this issue and people didn't find any obvious issues in them, the main point of this thread is trying to collect some info around that new clue I might have found.

[dc42]

@Diamondback you can use M122 to see whether mesh bed compensation is active. In the Move section of the report it should say "Compensation in use: mesh" or "Compensation in use: none".

If your Z axis has backlash and your slicer start GCode does not home the Z axis, then it could make a difference whether the nozzle is below or above the first layer height when you start the print.

[Diamondback]

@dc42 I have no doubts about the mesh being active, I can see the motors move. However, they seem to be doing the "wrong" thing. To me it feels like it's maybe using an old mesh or something, even after creating a fresh one.
Part of my slicer start code is always the full sequence mentioned in the first post, so it does home Z in any case.

I'll show some images of my test prints when the last one is done.

[Diamondback]

Interestingly enough, here's a very recent post that seems to have issues with the mesh seemingly being active with M122, but it not actually working until another G29 S1 was issued.
https://forum.duet3d.com/post/298335

[RogerPodacter]

@Diamondback i have had multiple instances where i made a change to something, lets say in config.g, and it doesnt take effect until 2 times later. meaning the board reboots after a change, but it doesnt implement the change. and i troubleshoot and think i'm crazy, then a 2nd reboot and the change sticks.

Perhaps the same effect happens with mesh level.

I dont have an example i have in mind, and i could be at fault here and its user error by me. of course this doesnt seem to happen anymore as i get more familiar with Duet...soo i dunno!

[Diamondback]

@dc42 Ok, that took way longer than expetected (not printer related) but here are the results.
I printed a 280x280 "sheet" out of PETG, a single layer (0.2mm) high for three different scenarios:

• Printer freshly turned on, bed heated to target temp, waited 30minutes, then printed from slicer
• Printer freshly turned on, bed heated to target temp, waited 30 minutes, manually homed the printer, then printed from slicer (I included this scenario since I wasn't 100% sure if the prior homing or the prior G32 was the "fix")
• Printer freshly turned on, bed heated to target temp, waited 30 minutes, manually homed, manually run G32 via DWC button, then printed from slicer

The slicer gcode contains homing (only if not already homed) and G32 (always) calls.

So the only difference between the three is if the printer was homed before printing and if G32 was run manually via DWC or not before the slicer gcode runs G32.

Here's pictures of the resulting prints:

Unhomed, no manual G32, only G32 from slicer gcode:

Homed, no manual G32, only G32 from slicer gcode:

Homed, manual G32 via DWC button, another G32 from slider gcode:

As you can see, there is quite a stark difference here between running G32 manually before the print file runs G32 or not.
Important: ALL THREE PRINTS had G32 run AT LEAST as part of the pre-print slicer gcode, only the last one had it run an additional time manually before running the print.

Ever since I discovered this I always ran a manual G32 before my prints in addition to the slicer one and did not have single issue with broken/weird mesh bed correction... Something is off here somewhere...

Any ideas...?

[droftarts]

@Diamondback sounds more like probe inconsistency to me. How is it configured? What firmware version and hardware? Please post an image of the bed mesh, too, and the response to G32 from a cold start.

Ian

[RogerPodacter]

could you run the same test, but not repeating the mesh command. essentially use the same saved mesh each time:

print 1 without mesh active
print 2 with mesh active
print 3 fresh boot
etc