Frix-x
Bed mesh reset before a print when using a virtual probe
Idk if it's just a me issue or if it aint even an issue.
But the following problem I have encountered. After the bed mesh is done and saved, it isn't loaded. I can manually load it though. Would be awesome to implement a load bed mesh after the meshing macro.
What was definitely responsible for my inconsistent first layer issue.
IIRC Klipper wrote some warnings months ago that the "default" bed mesh will no longer be loaded automatically on start up with a future release. But after a bed mesh the current values should be loaded.
IIRC Klipper wrote some warnings months ago that the "default" bed mesh will no longer be loaded automatically on start up with a future release. But after a bed mesh the current values should be loaded.
Thanks for your reply. In my case it doesn't load the mesh after bed meshing. I have to manually load it to apply it on a fresh print.
Klipper & mainsail & moonraker & klippain are up to date.
If there is something I can provide I am more then happy to.
That's very strange!
Can you confirm that if you do BED_MESH_CLEAR and then BED_MESH_CALIBRATE there is indeed a mesh loaded? This should be the standard behavior of Klipper. If it's not the case, then there is definitely a bug in Klipper... (I don't think it's Klippain related)
do you have maybe some macro "hiccup" where it somehow does a BED_MESH_CLEAR after a bed mesh or something?
To be creative, you could override BED_MESH_CLEAR and print an error, to test it out. but thats not a permanent solution. just locating or eliminating possibilities
I have done a bed mesh calibrate and it worked must be something weired in the Start gcode
So I have found the issue realting to the bed mesh getting cleared. This issue occurs because of the clean module. There is a variable to make the printer home z before brushing/cleaning, setting that variable to false fixes that issue.
A G28 Z clears the bed mesh.
Ohhh you're right! This is definitely something I did not think about and that I will need to fix... Thanks for catching this issue, it was not an easy one (and only happens when using a virtual probe Z endstop)
since I did not use clean nozzle, it never came up on my virtual z endstop
since I did not use clean nozzle, it never came up on my virtual z endstop
The G28 Z is done during the _MODULE_Z_CALIB macro here: https://github.com/Frix-x/klippain/blob/52632ec5cd482282c1319fd6d01a7499305d2a1e/macros/base/start_print.cfg#L364
Or the during the _MODULE_CLEAN when the specific force_homing_before_brush variable is set to true: https://github.com/Frix-x/klippain/blob/52632ec5cd482282c1319fd6d01a7499305d2a1e/macros/base/start_print.cfg#L339-L341
So I have found the issue realting to the bed mesh getting cleared. This issue occurs because of the clean module. There is a variable to make the printer home z before brushing/cleaning, setting that variable to false fixes that issue.
You're right! I've done some checking of the default start_print sequences. In fact, this bug should never happen in Klippain when using one of the stock probe configurations, as all the default start_print sequences are in the correct order to avoid it. But it could indeed happens when setting this variable to true.
If for some reason you want to override the start_print sequence to get your own, then it can also happens when two parameters are met:
- When not using the Z auto-calibration plugin
- And at the same time, if you have a sequence where the "z_offset" module is placed after the "bedmesh" module.
So, I'm going to add some mechanisms after the v4 release to avoid this problem and allow more custom user configurations in the start_print sequence and also solve the problem if using force_homing_before_brush = True.
Glad to have been able to help out figuring out this "bigger" bug. Also thanks for documenting the different scenarios.
@Frix-x could this be just avoided by checking if a bed mesh is loaded? At beginning of the processing of modules do a bed mesh clear and then check at each module when clearing if it is not already set? Just wondering
@Frix-x could this be just avoided by checking if a bed mesh is loaded? At beginning of the processing of modules do a bef mesh clear and then check at each module when clearing if it is not already set? Just wondering
Yeah this is how I wanted to do it. Thing is that the BED_MESH_CLEAR is absolutely needed in the G28 to avoid a known but rare problem where the machine would stop and error on every Z move due to an active bed mesh.
However during the last G28 Z, this should not a be a problem anymore and I was thinking of adding a new parameter like KEEP_MESH=1 and check that in the G28 (the same way we use the force_homing thing or some other parameters but it would be transparent for the user (no new variable)).
@Frix-x do you want to override G28 for that? or where do you like to place "KEEP_MESH=1"?