# Scheduled commands and optimized bed mesh leveling **URL:** \ **Category:** Features\ **Created:** [July 2, 2023, 4:43am UTC](https://klipper.discourse.group/t/scheduled-commands-and-optimized-bed-mesh-leveling/9247 "2023-07-02T04:43:18Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Florian](https://avatars.discourse-cdn.com/v4/letter/f/898d66/32.png) [@Florian](https://klipper.discourse.group/u/Florian)\ **Post date:** [July 2, 2023, 4:43am UTC](https://klipper.discourse.group/t/scheduled-commands-and-optimized-bed-mesh-leveling/9247/1 "2023-07-02T04:43:18Z")
Hello again 🙂 Using JSchuh’s macros for a while, I was wondering if this functionality would be worth including natively in Klipper. I am particularly referring to: - **[Schedule commands at heights and layer changes](https://github.com/jschuh/klipper-macros#layer-triggers)** - **[Optimized mesh bed leveling](https://github.com/jschuh/klipper-macros#bed-mesh-improvements)** To achieve this, Klipper would need to know when layer changes occur (this information can come from the slicer or be found through pre-processing gcode and identifying layer changes in Klipper natively). Once Klipper “knows” when layer changes happen, it can execute scheduled commands. It would also “know” what coordinates correspond to the first layer, which makes it possible to determine the print-specific area to probe for optimized bed leveling. To ensure that the pre-processing of layers at run-time does not slow Klipper down, the gcode reading and pre-processing would need to run in parallel to the execution of gcode commands during printing. I have been working on such a code (using Python’s multi-processing ability, passing gcode commands of entire layers for execution through a queue and error messages through a pipe) and I am currently stress testing it with real-world printing. Hence, implementing above mentioned features natively should be doable without too many issues and without running the risk of slowing Klipper down. This would make the functionality of JSchuh’s macros available to a wider user base, which may not be tech-savy enough to currently use it. Just wondering what your opinion is. Cheers Florian ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [July 2, 2023, 6:31am UTC](https://klipper.discourse.group/t/scheduled-commands-and-optimized-bed-mesh-leveling/9247/2 "2023-07-02T06:31:00Z")
- Optimized mesh leveling is already being worked on for including into Klipper. - The other one (IMO) is a slicer function and there is no need to replicate it in the printer’s firmware ---
**Author:** ![Florian](https://avatars.discourse-cdn.com/v4/letter/f/898d66/32.png) [@Florian](https://klipper.discourse.group/u/Florian)\ **Post date:** [July 2, 2023, 6:53am UTC](https://klipper.discourse.group/t/scheduled-commands-and-optimized-bed-mesh-leveling/9247/3 "2023-07-02T06:53:17Z")
Hi Sineos Great to read that optimized mesh leveling is already being worked on. Wasn’t aware of it. What is the approach being taken? Maybe you could point me towards the corresponding discussion. Regarding scheduled gcode commands at layer change, I was referring to commands that can be added at runtime. Otherwise, it would indeed be a replication of a slicer function. Any thoughts? Cheers Florian ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [July 2, 2023, 7:00am UTC](https://klipper.discourse.group/t/scheduled-commands-and-optimized-bed-mesh-leveling/9247/4 "2023-07-02T07:00:49Z")
> [@Florian](#): > > Maybe you could point me towards the corresponding discussion. > > > The current implementation of the \`relative\_reference\_index\` feature was initial…ly added when the mesh configuration was static and could not be changed during runtime. When runtime parameters were introduced it was also possible to change the \`relative\_reference\_index\` to accommodate a new mesh, however this puts restrictive requirements on where the new mesh is located as the new index must reference a coordinate near the original index. > > With the forthcoming addition of "adaptive" mesh leveling it is necessary to rework how the reference coordinate is handled. This pull request makes the following changes: > > \- The original points are no longer cached. Points are generated each time \`BED\_MESH\_CALIRBATE\` is run to guarantee that > all attributes that depend on point generation are set. > > \- A new \`zero\_reference\_position\` option has been added. This behaves like the relative reference index, however it takes an 2D coordinate rather than an index. If the coordinate is located within the mesh then the mesh will be offset to make this location apply zero adjustment. If the coordinate is outside of the mesh then its location will be probed after calibration with the resulting Z value will be used as the z\_offset. > > \- To avoid breaking existing configurations the \`relative\_reference\_index\` option has not been removed. If the RRI is specified then its location will be determined at startup, with the result set as the \`zero\_reference\_position\`. Its behavior will mirror that outlined above. The \`RELATIVE\_REFERENCE\_INDEX\` parameter for \`BED\_MESH\_CALIBRATE\` has been removed as this value cannot be changed after initialization. > > These changes shouldn't affect existing configurations with the possible exception that some users may update the RRI via gcode command. When it is determined that this is ready to merge I will note this change in Config\_Changes.md. > [@Florian](#): > > I was referring to commands that can be added at runtime. I’m missing the point here. If I need such, then it depends on the model that I’m printing and as such, I’ll set it in the slicer. All modern slicers have such functions, so why should I add the complexity in the firmware? ---
**Author:** ![Florian](https://avatars.discourse-cdn.com/v4/letter/f/898d66/32.png) [@Florian](https://klipper.discourse.group/u/Florian)\ **Post date:** [July 2, 2023, 8:50am UTC](https://klipper.discourse.group/t/scheduled-commands-and-optimized-bed-mesh-leveling/9247/5 "2023-07-02T08:50:06Z")
Hi Sineos Thanks for the pointer! Re scheduled commands at layer change, JSchuh made a good argument: “This is similar to what your slicer can already do, but I find it simpler, and you can schedule these commands while a print is active. As an example of usage, I added an [LCD menu item](https://github.com/jschuh/klipper-macros#lcd-menus) to pause the print at the next layer change. This way the pause won’t mark the print by e.g. pausing inside an external perimeter.” Another one would be that the user simply forgot to add e.g. a filament change pause when slicing and wants to correct the error while the print is already running. The use cases are certainly specialized as to when you would need such functionality. Nevertheless, having the option wouldn’t hurt. Of course, macros can do this too. However, as you wrote yourself, beginner users copy those macros and then run into issues because the integration of the macros is sometimes not straight forward… Cheers Florian ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [July 2, 2023, 9:00am UTC](https://klipper.discourse.group/t/scheduled-commands-and-optimized-bed-mesh-leveling/9247/6 "2023-07-02T09:00:33Z")
> [@Florian](#): > > Nevertheless, having the option wouldn’t hurt. From experience, I can tell you that the Klipper project lead is very leery of adding “edge case” features that do not contribute a broad and measurable benefit for the average user base. Main arguments are: - Added maintenance burden - Added documentation burden - Added configuration complexity Without being the project lead, my feeling is that such a feature has below zero chance to get accepted. Much higher impact features have been rejected for the above reasons and in this case I tend to happily agree, since it is an edge case where adequate alternatives exists. ---
**Author:** ![Florian](https://avatars.discourse-cdn.com/v4/letter/f/898d66/32.png) [@Florian](https://klipper.discourse.group/u/Florian)\ **Post date:** [July 2, 2023, 10:35am UTC](https://klipper.discourse.group/t/scheduled-commands-and-optimized-bed-mesh-leveling/9247/7 "2023-07-02T10:35:41Z")
Hi Sineos. Yes, in this particular case, the “cost-benefit” analysis is a tricky one to evaluate. I guess, if the corresponding code would be tidy and simple, it might be worth thinking about it. If not, I agree to not mind the hassle. Anyways, I am happy to see that optimized bed mesh will be native soon 🙂 Cheers, Florian