I’ve been following this conversation with interest and I just wanted to add a couple of comments.
Going back to the start of the original thread by @garethky , I’ve never seen any indication that many people swap out their nozzles for different sizes on a regular basis and that it really is an annoyance and a place where errors get inserted into the process. When it gets right down to it; if the printer can’t (electronically) read the nozzle parameters then there’s going to be human input which means there will be opportunities for error. Maybe this is a source of frustration for people with many hours/thousands of dollars of wasted printer time, but I haven’t seen any indication that this is the case.
@Florian turned the discussion to having a filament parameters database that the printer could access to have the (user defined) best operating configuration for the filament. It’s a good idea, but I don’t think it’s appropriate to have the printer access it - this seems to be more appropriately accessed by the slicer.
In my mind, the ideal would be a community maintained database for different filaments. When I say “community”, it would be users that determined the best printing parameters for specific filaments and would allow a user to share their parameters to the database and let others vote on whether or not these values should be included in the parameters provided to the slicer. Again, we’re talking “ideal” which means that the uploaded user values would be averaged into the existing values to get the best possible printing parameters.
The problem with this idea is that there aren’t any “standard printers” out there that could take these ideal values. There are huge variations in the operating conditions of the printers due to poor set up, sensor variation, ambient operating environment (including whether or not there is an enclosure and whether or not its heated) and so on. So the question becomes are there multiple database entries for specific printers and operating environments - not an insurmountable problem but adds to the complexity and work required to make sure the uploaded parameters are applied in the appropriate situation.
The big question that jumps out at my here is, how important would this database be for the average user? I’m not sure the vast majority of users work with any kind of variety of filaments - in my experience, just as @Sineos indicated, I have seen a lot of variation between brands of filaments (ie PLA from one company doesn’t print the same way as PLA from another) with little to no variation between lots within the same manufacturer’s product.
From what I can see, the vast majority of users use the same brand of filament and spend some time getting it dialed in to get good quality prints and stick with that because its work and they don’t have a good process for optimizing print parameters for a filament. This database would be of great use to them starting out, but once when they have something that works, its value becomes marginal.
Personally, I’m somewhat adventurous when it comes to filaments as I will get different manufacturer’s products that I read about to try out. Currently, I’m trying out Igus I151/I180 filaments because of their self lubricating properties and I would have loved some more precise printing parameters that somebody else had done the work on instead of the days I’ve spent dialing it in.
As a generic comment: DON’T ADD ANY MACROS TO THE SYSTEM. Too many people see a macro that they think need and add them blindly, only to discover they cause problems with the printer’s operation. Macros are one of the greatest features of Klipper and one of its greatest problems (especially for new users).
The support discussion is something of a red herring; if the functionality is well thought out and it is used by people, it will be maintained going forwards. The pull request process seems to work very well when it comes to Klipper and if it’s used then somebody will be making sure it works.
It seems to me that the ideas put forward in this thread are individuals wish list items. If there’s a conclusion that I can make here on what’s needed it is some kind of process for gauging users pain and coming up with a prioritized list of issues.