bed_mesh: profile fixes

[Arksine]

This makes a couple minor changes to the profile behavior for bed_mesh:

1. Require that a profile name be specified for the PROFILE parameter in BED_MESH_CALIBRATE and all parameters in BED_MESH_PROFILE. This resolves #5875.

2. Introduce an initial_profile option. This allows users to specify which profile is loaded at startup, or to bypass loading a profile at startup by specifying a profile name that doesn't exist (my preference is to set this to none).

Signed-off-by: Eric Callahan [email protected]

[KevinOConnor]

Thanks. I can commit the profile name checks now, but I think the iniital_profile stuff should wait until after the v0.11.0 release.

What's the reasoning for adding a new config option for the profile name? Is it that some users don't want a mesh loaded at startup, or is it that there is some reason to load a mesh at startup that isn't named "default"? If the former, I wonder if an alternative would be to change the code to not load a default mesh at startup and require users to manually issue a BED_MESH_PROFILE command during start scripts. (A notable short-term pain, but may be better for long term maintenance.)

-Kevin

[Arksine]

Sounds good. Yes, the initial_profile is really to allow users to select either a specific profile or skip loading a profile (this is my preference). I agree that perhaps its better to disable loading the default profile. If a user really wants to load one at startup they could use a delayed_gcode to do it, that is something I could note in bed_mesh.md.

[KevinOConnor]

Okay, thanks. I cherry-picked commit 5e34b450.

Separately, it seems a bit odd that one would use a delayed_gcode - I would think it would be simpler for a user to update their START_PRINT macro (or corresponding slicer setup).

Cheers, -Kevin

[Arksine]

Thanks. I updated this PR to remove profile initialization.

Separately, it seems a bit odd that one would use a delayed_gcode - I would think it would be simpler for a user to update their START_PRINT macro (or corresponding slicer setup).

Generally I agree, however I documented it in the event that a user wanted to restore the prior behavior. There may be a situation where a user wants the profile active before the print has started, although in general practice I don't think that makes much sense. I can remove that documentation that if you prefer.

[KevinOConnor]

Thanks. Seems fine, but something to change after the next release.

-Kevin

[KevinOConnor]

FYI, I agree with making this change. I suspect it might cause a lot of pain for existing users though. I wonder if there is some way to announce this change so it's better understood before we roll it out.

-Kevin

[zellneralex]

Moonraker has integrated announcement and to my knowledge Klipper and moonraker are automatically subscribed. That would reach at least most Fluidd/Mainsail users.

@Arksine can help to setup an Klipper announcement, he has done that for moonraker in the past.

[Arksine]

Sure, we can do an announcement. Moonlight is already set up to watch Klipper's issue tracker. All Kevin would need to do is create an issue in this repo and tag it with an announcement label. Within an hour the announcement should be distributed to all running instances of Moonraker with an internet connection.

Additionally I started looking into pulling announcements from the discourse using their API. I believe its possible without credentials, so its something I'm willing to look at adding for future announcements related to Klipper.

[KevinOConnor]

That makes sense. We could make an announcement now and schedule the change on something like Feb 1st?

The announcement could be something like:

An upcoming version of Klipper will no longer load a default bed_mesh configuration at startup. If you are using a bed_mesh configuration today then it is recommended to add an explicit BED_MESH_PROFILE LOAD=default command to your START_PRINT macro (or equivalent slicer start commands). This change to Klipper is planned for February 1st 2023.

Thoughts?

-Kevin

[Arksine]

Sounds good to me. The of title of the issue will be emphasized, and the announcement will include a link that takes them directly to the issue. When you close the issue it will be dropped from the feed.

I went ahead and fixed up config_changed.md, forward dating it to Feb 1 2023.

[KevinOConnor]

Okay - I created the issue (#5983).

Separately, for what it is worth, I'd recommend having Config_Changes.md and bed_mesh documents point users to updating START_PRINT (or slicer start). I don't feel strongly about it though, so up to you.

-Kevin

[Arksine]

Looks good!

I went ahead and made those changes to the docs. I agree that loading the profile in the start macro is the best way to deal with it. I did leave a note in the Bed Mesh docs on how to restore the old behavior with a [delayed_gcode], but recommended that they just load the profile before a print.

[djessup]

Just confirming this appeared in Mainsail for me just now - the system works!

[qwewer0]

On Fluidd it is a bit cut down, but its there.

[pedrolamas]

On Fluidd it is a bit cut down, but its there.

Pressing "more information" button should send to the full article... I wonder if I should just allow those notifications to be something like 10 lines or so... 🤔

[Sineos]

I'd even go a step further since I assume that a lot of users readily ignore the little "1": Priority announcement should be shown (full-screen) automatically until actively cleared

[KevinOConnor]

Thanks.

-Kevin