ENSURE_BED_MESH for Print Start gcode

Macros
1

I’ve created a macro that ensures there’s a bedmesh active that fits the current bed temperature by naming meshes after bed temperature. I there is no proper one it gets measured with a soak time to ensure there is no drift while measuring:

feel free to test, modify and report any bugs :wink:

3 Likes
2

Thank you for he macro. It’s a great idea and I tried it. I have the following problem. I get the bedmesh, but it doesn’t find the macro next time I want to print. Do you have any suggestion?

3

Did you put the macro into your printer.cfg?

4

Yes, this will be the message before printing begins.

Thermal soak: waiting 120s
12:08
No matching bed mesh → preparing calibration for 55C
12:08
Bed Mesh Debug: active=, expected=mesh_bed_55, target=55C, soak=120s
12:08
Retries: 0/10 Probed points range: 0.003233 tolerance: 0.007500

5

You could post a klippy.log containing the two runs. That might help finding the error.

1 Like
6

Thanks. From this output I can only see that no mesh was active at print start:

“active=, expected=mesh_bed_55”

That alone does not necessarily indicate a bug.

The macro was intentionally designed to check only the currently active mesh, not all saved mesh profiles. The reason for this is that I wanted “BED_MESH_CLEAR” to act as a manual “invalidate current mesh” command.

So the intended behavior is:

  • matching mesh still active → reuse it
  • mesh was cleared (or Klipper restarted) → force a fresh calibration on next print

If the macro automatically reloaded saved profiles, then “BED_MESH_CLEAR” would no longer reliably trigger a re-measurement during the next print start.

To better understand what is happening in your case, a “klippy.log” covering two consecutive print starts would help:

  1. first run: mesh gets created
  2. second run: mesh should either still be active or be recalibrated

Especially interesting would be whether anything triggers:

  • “BED_MESH_CLEAR”
  • “SAVE_CONFIG”
  • “FIRMWARE_RESTART”
  • a normal Klipper restart

between both print attempts.

7

THANK YOU FOR YOUR EFFORT AND DETAILED RESPONSE.

I HAVE NOT BEEN ABLE TO FIND OUT WHY THERE IS NO ACTIVE NETWORK, EVEN IF IT IS CREATED.

I AM ATTACHING THE LOG FILES.

KLIPPY-reduced.txt (374.6 KB)

console_log.txt (7.1 KB)

8

Thanks for the logs — this makes the behavior much clearer now.

The issue does not seem to be inside the macro itself. It is mainly caused by the surrounding start/end logic.

In your setup:

  • Z_TILT_ADJUST internally runs BED_MESH_CLEAR

  • PRINT_END also runs BED_MESH_CLEAR

  • and PRINT_START manually loads mesh_bed_55 before calling my macro

So the currently active mesh is repeatedly invalidated by the surrounding macros.

My macro was intentionally designed around the concept of an active mesh, not merely a saved profile. The idea is:

  • if the correct mesh is still active → reuse it

  • if something cleared the mesh → force a fresh calibration

This allows BED_MESH_CLEAR to act as a deliberate “invalidate current mesh” command.

So in your current setup, the recalibration is expected because:

  • Z_TILT_ADJUST clears the mesh

  • PRINT_END clears the mesh again after every successful print

Also, this line in PRINT_START is somewhat contradictory to the intended design:

BED_MESH_PROFILE LOAD="mesh_bed_55"

because the macro is intentionally not based on auto-loading saved profiles.

For cancelled prints, however, your CANCEL_PRINT does not clear the mesh, so in that situation the mesh should normally remain active.

9

Now I finally understand how the PROCESS-MACRO works.

THANK YOU VERY MUCH…

10

No reason for shouting.

Always send a complete klippy.log - If too large, compress it (ZIP).

2 Likes