(suggestion) Heated bed leveling (custom settings)

[Shushkata]

This is something that i think is needed when bed leveling. The in-user interface leveling is made with pre-applied settings that does not work for every material. The Gcode command that can make the leveling is somewhat hard to dial, as it need to be part of a print. is it possible to have a custom bed leveling setting in the user interface ? This is something i shared with Elegoo's support and they were willing to pass forward down the line but when, what and how is a mystery with that brand.
Can this be supported with the current version of the initial code you use ? Maybe it can be added ?

[kevinhouseuk]

I too would like a feature to store meshes for other plates and temperatures.
But I also have a theory about how it could be done without any actual changes to the CC, which I'm hoping somebody else might run with::

I'm quite new to this (although a programmer long ago) and not familiar with Gcode, but by prodding Copilot a few times I came up with this approach:

It uses two bits of Gcode:

1. Write a Gcode script to call the bed levelling function (only). It would include parameters for plate type/side and plate temp. Possibly also the filament type if you want to distinguish (though I think deriving temp from the filament's own parameters make more sense). The gcode should:- Populate the variables from the slicer's variables..

• Set the temperature, run the leveling, and then save the result. with a profile name based on those parameters.
  I'm not sure how easy it is to load and run g-code, but I guess this could even be put into the before print code (temporarily - bear with me).

2. Edit the standard before G-code to select the profile using the parameters as per the above. It will simply pull in the profile that has been saved previously.

In use:

1. Run the leveling gcode for each combination you intend to use, swapping plates accordingly of course. This can be done any time before you want to use it. Probably makes sense to do them all up-front though.
2. Use the second bit of gcode in ALL prints from then on. It can just live in the before section.
3. You can ignore the CC's UI leveling - it won't be used in practice if you follow this method (and it works ;-))

Caveats:

1. The storage of multiple meshes of any name appears to be supported within klipper. So, this should work without modification, but I haven't tested that.
2. I am uncertain on how the selection of profile within the job's gcode interacts with the selection in the CC's UI (web or touchscreen). I am guessing that the CC selects the profile and then processes the gcode of the job, in which case this should be fine. But if it somehow intervenes with the gcode then it may not.
3. As I said, I'm new to 3d printing so haven't attempted to actually code anything myself, yet. Copilot actually gave me all the code I asked for to do this and it looked reasonable, but my CC is currently broken (failed sensor) and when it's fixed I'll have other priorities before I'll get to thinking about this.
   I'm really interested to know what people think of this

[kevinhouseuk]

On further thought - the two could be combined so that if the mesh has previously been stored for the plate and temp combination then it uses it, and if it hasn't then it creates and stores it and then uses it. (I suppose you could also have a 'forced refresh' option if you wanted.)
I believe that requires putting a macro for that logic into the printer.cfg though, so not quite so accessible for people and risky if you have don't have SSH access and have to use gcode to upload an edited version. I've seen it said that the CC won't boot if that file is corrupted - that seems strange since it wouldn't seem necessary for the UI etc to function, but I can't state that it is untrue.
It also occurs to me that this complements what KAMP does - two different approaches with different pros and cons and suitable in different scenarios. Probably a combination is the ideal.

[suchmememanyskill]

Gcode macros are not supported by elegoo's implementation of Klipper. Also, Elegoo's klipper implementation is a single binary. So if it crashes due to an invalid config, you get nothing.

[kevinhouseuk]

Gcode macros are not supported by elegoo's implementation of Klipper. Also, Elegoo's klipper implementation is a single binary. So, if it crashes due to an invalid config, you get nothing.

That's a pity about macros. As I said, I'm new to these systems - are there any helpful overviews on the structure, and for example on what is and isn't included in the CC klipper?

But back to my first post, is there any reason the basic idea isn't appropriate anyway, even if it does require a manual trigger to create each mesh in the first place?
Also, when klipper crashes, does that just end the job or crash the whole device? (!). It seems the former should be the case.
So, you could still SSH in and fix whatever you need to. and presumably other UI features should work, you would just crash every job.
I can see how that might prevent any idea of swapping back a clean .cfg file on the original OS, since it presumably requires klipper to run a gcode to swap the file from the USB, and if it parses the current ('corrupt') file first then you'd be stuck.
If I've made further errors in my understanding of how this works, I'd appreciate pointers to any good breifing docs. So far I've just had to google and use chatGPT to research and it's quite inefficient and clearly risks misunderstandings around the CC specifically.
Thanks

[suchmememanyskill]

So, the big issue is that elegoo's bed mesh algorithm via the touch ui hardcodes the gcode command for leveling. You can use a hex editor to replace these gcode commands (and thus their temperatures), but that's not very easy. Creating configuration for this will be quite difficult (i don't really want to write a whole lot of arm assembly for this)

You're right about just the app crashing (in most cases*), but the app also handles network connectivity, and only when the app fully boots. In OpenCentauri we remedy this by re-implementing the connection logic before booting the app.

But tl;dr, we looked into this, there's no sane way to do this. Real Klipper would be your best bet

[kevinhouseuk]

So, the big issue is that elegoo's bed mesh algorithm via the touch ui hardcodes the gcode command for leveling. You can use a hex editor to replace these gcode commands (and thus their temperatures), but that's not very easy. Creating configuration for this will be quite difficult (i don't really want to write a whole lot of arm assembly for this)

You're right about just the app crashing (in most cases*), but the app also handles network connectivity, and only when the app fully boots. In OpenCentauri we remedy this by re-implementing the connection logic before booting the app.

But tl;dr, we looked into this, there's no sane way to do this. Real Klipper would be your best bet

Thanks.
But I wasn't proposing to edit the UI but instead to avoid the UI altogether for leveling.
I would just run gcode from the slicer or USB to create the various meshes once and then gcode in the jobs to use them. The built-in meshes would then be redundant because no job would ever use them in practice. My assumption being that even if you selected pre-leveling when printing a job, it would go ahead and do that but the subsequent gcode in the job would actually swap to the specific profile anyway.
It's obviously not ideal to relegate the UI, but once the meshes are created, it becomes zero-effort to use them. Aside from maybe recreating them if it seems they have drifted.