After receiving the latest feedback in the Impossible Bed Mesh Leveling thread I decided to take another look into
bed_mesh.py. I am unable to produce a situation where
bed_mesh applies an incorrect adjustment based on the mesh, however I have identified a couple of areas where I believe
bed_mesh can be improved. If you aren’t interested in the details and just want to test the new changes, skip down to the to the
I first decided to take a look at the bicubic interpolation algorithm. While the algorithm is generating mathematically correct results, I believe that the recommended tension value should change to
.5. In my tests it seems to deliver more consistent results, particularly as the surface variance increases. Below are two visualizations generated on my MK3 for comparison. The interpolated mesh is intentionally dense to help show the difference.
As you can see, the .2 tension is too low, resulting in ridges. My MK3 printed okay with this mesh, however this behavior could very well result in a mesh that is “unprintable” on some machines.
Additionally I made a change that affects the edges of the interpolated mesh. Bicubic interpolation requires four control points; when interpolating at the beginning or the end of an axis it is necessary to “fake” a control point. Previously I set it to the same value as the point at the edge of the mesh. This PR uses linear interpolation to calculate the value of the “fake” control point. The result is that the edges shouldn’t “flatten” out. In the following illustration the top curve represents the current implementation (no interpolated control point), and the bottom curve represents the updated implementation (interpolated control point).
The current move splitter checks the z-value along a move segment and splits it when the difference exceeds the configured
split_delta_z. When I first PRed
bed_mesh Kevin suggested that
bed_mesh split moves when they intersect the edge of a triangle in the mesh. At the time it was agreed that this was worth looking into, but not necessary to merge. The experimental branch implements this. This will result in more move segments, the split frequency scales with mesh density. Naturally this increases Klippy’s CPU usage, however in real world tests I haven’t noticed a difference. In synthetic tests using a mesh with a density of 1 sample every 11mm (on both X and Y) it takes Klippy about 3.5% longer to process a gcode file with the new splitter.
The experimental branch also includes a few other changes:
- TMC driver queries are disabled when
debugoutputhas been set. This allows a user to run Klippy in batch mode without removing the TMC sections from a config.
debug_outputare reported in
system_stats. I used this to have my
PRINT_STARTmacro load a mesh, rather than probe one, when running batch mode. There may be a better place to report this,
system_statsseemed like the best fit after a cursory glance of modules that report status.
- I added an
bed_mesh. This allows you to select the profile to load at startup, or skip loading a profile if the specified profile name does not exist
- The last commit includes the ability to dump mesh adjustments over the unix socket. I am currently working on a script that will use
scipyto validate that the adjustment for each move is correct. I’ll add that script to this branch when its done. This is going to be a lot of data to serialize and send so I’m not sure yet how its going to impact Klippy when a client is subscribed.
The branch can be found at: GitHub - Arksine/klipper at dev-bed_mesh-experiment-20220703
I recommend checking out detached as its possible that I will force push to this branch. For those unfamiliar with git, ssh into your machine and perform the following commands:
cd ~/klipper git remote add arksine https://github.com/Arksine/klipper.git git fetch arksine git checkout arksine/dev-bed_mesh-experiment-20220703 sudo service klipper restart
Should I update this branch, you would repeat the fetch, checkout, and restart commands, do not use
git pull. When you are done testing and want to go back to the official branch:
git checkout master
It would be helpful to get feedback both from users that are struggling with their first layer and users that have a consistent first layer.
Specific things to look for:
- Is your first layer improved? Worse? No visible change?
- Any noticeable increase in cpu usage? Any stalls during a print that otherwise would not occur?
- Any additional artifacts on a print? Any reduction?
- Any obvious regressions? (Klippy crashed, invalid tool movement)