Skip to content

Conversation

@dmbutyugin
Copy link
Collaborator

This PR substantially reworks how the automatic shaper selection processes multiple resonance data files. Some printers can have different resonances at different points of the build volume (e.g. bed slingers at different Y positions, some CoreXY printers when gantry or Y rods have insufficient stiffness, delta printers across build volume in general, etc.), so in order to do a proper input shaper selection, one may need to run resonance testing at different points, and somehow combine the results. The current Klipper script just combines the resonances data from different files and averages the measurements for the same frequencies. This has a downside that individual resonance peaks at specific points may be smoothened out by data at other points, sometimes leading to poor input shaper selection. The new reworked algorithm instead estimates remaining vibrations (as a percentage) for each shaper for each resonance measurement individually, and then selects the input shapers that minimizes the vibrations across all measurements. In addition, this PR brings a couple of other minor changes to the shaper selection algorithm:

  • No longer recommend ZV shaper by default if possible - this input shaper shows relatively poor performance in practice due to high sensitivity to the shaper frequency and damping ratio selection, which makes it a poor choice for an automatic recommendation (the data is still presented for ZV shaper and a user can make an informed choice to enable it if they choose so).
  • An additional pass over the shaper frequency selection to try to improve over the previous best shaper; this is useful on occasions like when MZV was selected with good smoothing results but relatively large remaining vibrations, and the best 2HUMP_EI happens to give too much smoothing and thus is not selected, but it could be possible to select a different 2HUMP_EI shaper frequency that gives both smaller remaining vibrations and smaller smoothing than MZV, making it a better recommendation.
  • When the minimal estimated shaper vibrations are exactly 0, permit a very small non-zero vibrations value for the 'best' shaper recommendation.

Here's a comparison for a few cases of the current and the new algorithm for multi-point automatic input shaper selection:

Current algorithm New algorithm
old_x_resonances new_x_resonances
old_y_calibration new_y_calibration
old_z_calibration new_z_calibration
old_y_calibration new_y_calibration

And while you can see that the input shaper recommendations are not always different, sometimes it is more accidental, and the new algorithm still better accounts for individually measured resonances.

* Do not recommend ZV shaper by default if possible
* Try to find more optimal shaper out of more aggressive ones

Signed-off-by: Dmitry Butyugin <[email protected]>
@KevinOConnor
Copy link
Collaborator

Thanks. In general it seems interesting and useful to me.

One question I have - would it be reasonable to convert from the current /tmp/xxx files to the webhooks api for this data? That is, instead of changing the existing file format could we instead export the data over the webhooks unix domain socket, and change the graph_accelerometer.py and calibrate_shaper.py scripts to read from the socket? There are a few benefits to doing that: I'm sure the gui frontends would love to also have access to this data; it would avoid having to warn about changing file formats in the future; it could avoid the need to ssh/scp the graphs to another machine for display purposes. For examples of code that does this today, one can look at how klippy/extras/bed_mesh.py implements the "bed_mesh/dump_mesh" endpoint and how scripts/graph_mesh.py can read that data from the socket (or from moonraker or from a file produced from a previous invocation of the script).

Otherwise, I did not review the math in this PR, but I'll defer to your expertise. It sounds like a useful addition.

Cheers,
-Kevin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants