Thanks for the feedback.
One of the core goals when I started Klipper was to facilitate experimentation with 3d printers. It was a core reason why I chose Python for the host code, why I implemented the module abstractions in the host and mcu code, the choice of text names for mcu/host commands, etc. . Arguably, the genesis of the project was my desire to experiment with modeling of pressure in the extruder.
So, I love it when people perform experiments and share their results! It was not my intent to discourage you from experimenting. Indeed, thermal modeling is an area that Iāve also been thinking about and I wanted to share some of my thoughts on the subject. If you go on to experiment in this area Iām definitely interested in your results.
I built Klipper with an explicit goal of making it easier to experiment, but it has never been a goal of mine to maintain a central repository containing those many experiments. I know this distinction may seem silly or counter-intuitive, but it is an important distinction. Namely, I donāt believe a repository holding many past experiments is a particularly good starting point for a new experiment. (Two problems repeatedly come up when experimenting in experimental repos: an experiment may need to change core interfaces and it becomes very difficult for a developer to make those changes without breaking other experimental features, with the developer often struggling to know what breaking code is experimental or widely used; and, if problems occur with a new experimental feature it becomes very difficult to know if thatās due to fragility in the new experiment or fragility in some other experimental code.) I also am just not personally interested in spending time maintaining a repo of experimental features.
So, the obvious question is - what new features will get merged into Klipper and would this new proposed feature be one of them?
When looking at new features to be merged into Klipper, I generally look to see if there are many users from different backgrounds and different printers excited about the feature, see users test the feature, see users do comparative testing involving prints, and see pictures highlighting before and after pictures showing a measurable improvement that the feature offers. This often occurs over months.
For this particular feature, I have no idea if it would be merged. I donāt know how one could even start to consider that.
You mentioned āaxis twist compensation, and z_thermal_adjustā in your message. You may be surprised to learn that those features were discussed for months and had many users reporting results (including pictures).
Itās also worth pointing out that I also run many experiments that I donāt feel are suitable for the main branch. You can find some of them at GitHub - KevinOConnor/klipper-dev: Kevin's development repository for Klipper experiments. (Iāve had many more never published).
The āsee lots of users test and provide pictures of measurementsā is not an absolute metric of course. Itās not necessary in some cases - for example if someone submits support for a new micro-controller architecture I would not ask for āpicturesā as it is obvious that a printer with that micro-controller either āworksā or ādoesnāt workā with the support. In some cases, like setting up a new API or refining an existing API, there is no reason to suspect a print quality difference - in those cases I still like to see feedback from other contributors, discussions on long-term maintenance, and itās not unusual for discussions to last months. If I canāt get a good feel for a āmeasurable improvementā then Iām likely not going to merge - the goal isnāt to āmergeā, the goal is to have well tested code that provides excellent quality results in real-world usage.
So, Iām happy to see you experiment, and Iād be curious to see your results. If the goal is to improve 3d printing, to experiment, and to gain new insights, then I donāt see āmergingā as a requirement.
Cheers,
-Kevin