[FR] Input shapers support in Klipper

[dmbutyugin]

Input shaping is a control technique to create a commanding signal that cancels its own vibrations. It would be great to support it in Klipper.

The code for this feature is ready and demonstrates very promising results. Only some documentation rework is pending.

@KevinOConnor, per you suggestion, I'm creating a dedicated ticket to discuss the testing and integration of input shapers to Klipper instead of #2030.

[KevinOConnor]

Thanks! FYI, I'm fine with merging the code now and then merging the guide when it is ready. (Unlike the previous "bezier scurve with simple trapezoid generator" in #57, I don't think there is a concern of a "new user pitfall" with this support.)

-Kevin

[dmbutyugin]

@KevinOConnor Sounds good. I've sent a pull request #3032. Please take a look and comment.

[KevinOConnor]

I had some random thoughts on a possible test methodology. Just a very rough idea, so take "with a grain of salt".

1. Print the test object (vase mode, max_accel=7000, SET_VELOCITY_LIMIT ACCEL_TO_DECEL=99999, SET_PRESSURE_ADVANCE ADVANCE=0, TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1250 FACTOR=100 BAND=5).
2. Look for and measure ridges on print. 2a. If measure 30hz or lower (aka .030s or greater) - then failure. Only way to improve print is to use lower acceleration. Test finished.
3. Configure [input shaper] with shaper_type=zv, shaper_freq_A=<measured value>.
4. Print test object again (same parameters as in step 1).
5. Look for and measure ridges in print. 5a. If ridges no longer in print - then success. Go on to step 6. 5b. If ridges are present and have same distance as before and print looks no better - then failure. Disable input_shaper and test finished. 5c. If ridges are present and have same distance but print looks much better - then success. Go on to step 6. 5d. If ridges are present and show a different distance, then configure shaper_freq_A=<average of measured values from tests> and set shaper_type to mzv, ei, ei2hump, ... based on some formula (TBD) that uses the range of measured ridges from tests. Repeat steps 4&5 with new settings.
6. If using input_shaper, then print out a "rounding of the corner test print". (I'm thinking of a simple 2mm high object with a few holes in it that can show gaps in surface filling.) Print it with both input_shaper disabled and enabled. 6a. If gaps are introduced by input_shaper and quality is too low to be acceptable - then failure. Disable input_shaper and test finished. 6b. Otherwise, success. Use input_shaper as configured. Be aware of what to look for wrt "rounding of the corner" and "ridges".

Thoughts?

-Kevin

[dmbutyugin]

I was thinking about probably even simpler basic tuning, along the lines:

• bump max_accel and max_accel_to_decel to 7000 in printer.cfg;
• disable pressure advance;
• print the ringing model without input shaping and acceleration TUNING_TOWER, measure frequencies per axis;
• if unsuccessful (i.e. no clear period visible) - more advanced tuning is required;
• otherwise, put measured frequencies into [input_shaper] section and enable MZV shaper;
• print the ringing model again in the same manner (this time with MZV);
• if the ringing is gone - full success, otherwise measure the ringing frequencies on the newly printed test;
• if they are different - more advanced shaper is needed (maybe it can be chosen with the help of a script that plots shapers response);
• if they are the same, but ringing is still there, try to also print the ringing model again, but with EI shaper now;
• if EI shaper is better, stick with it, otherwise revert to MZV;

Now, for the selected shaper there is already an acceleration TUNING_TOWER test print. One can choose max_accel from this test such that both:

• ringing is acceptable;
• corners are not smooth yet (since PA is disabled, the corners should still show 'bumps' from insufficient PA).

Here I'm hoping that max_accel will still be higher than what is normally required to reduce ringing without input shaping (so that there is some gain). One can also make a choice between MZV and EI shapers based on the the smoothing of the corners and which max_accel they can take as a result (i.e. if one has to take too low max_accel for EI shaper due to smoothing - it might be better to use MZV and higher accelerations). Also, if the frequency is way too low (e.g. below ~20 Hz), one may also try printing ZV shaper and see if it is still acceptable vs MZV.

Now what I'm now working on in terms of documentation is the description of the more advanced tuning process, and some useful technical details about available input shapers (e.g. which range of frequencies they reduce resonances in). It should be similar to what I suggested earlier to you, Kevin - just guessing by trying several ringing frequencies with 3-hump EI shaper, and choosing the highest frequency that still shows good or acceptable results. Then one can can try 2-hump Ei shaper and even just EI shaper by adjusting the shaper frequency accordingly from 3-hump EI shaper.

[KevinOConnor]

FYI, I'm seeing pretty bad "rounding of the corners" with 2hump_ei on my m2 printer. So, although I saw excellent suppression of ghosting on extreme accel tests, it's not a clear quality improvement for regular day-to-day prints. At some point I plan to retry the tests with just the "ei" shaper to see if I can strike a balance between "rounding" and "ghosting".

Below are some pics of a simple case lid (if curious, it's based on the stl at https://github.com/KevinOConnor/humidwifi/tree/master/case ). This is with my normal "bulk printing" speeds: max_accel=3000, max_accel_to_decel=500, print velocity=100, external perimeter velocity=50, layer height=0.28. These were all done with your latest code from #3032 .

No input-shaping (there are some blemishes, but they aren't that noticeable):

With shaper_type=2hump_ei, shaper_freq=40 (the blemishes are pretty bad):

Just for kicks, I also ran it with shaper_type=3hump_ei, shaper_freq=35 (blemishes also extend to the side wall):

I was thinking about probably even simpler basic tuning, along the lines

Sounds good to me!

Now what I'm now working on in terms of documentation is the description of the more advanced tuning process

FWIW, given the issue with "rounding", I wonder if the advanced advice might ultimately be: "deploy hardware frame stiffeners", and/or "accept that you have to print at low accel/speed".

Cheers, -Kevin

[KevinOConnor]

FYI, here's an overview pic of three lids mentioned previously (from left to right - no input shaping, 2hump_ei/40hz, 3hump_ei/35hz):

-Kevin

[dmbutyugin]

@KevinOConnor That's strange. FWIW, I've been using 2hump EI shaper for some time on my printer, because of wider spectrum of resonances on a delta. I used it mostly for test prints, but did some functional prints too, and didn't notice much of that effect. But there are differences in my setup:

• 2-hump EI shaper is at 51 Hz, not 40 Hz; the difference may still be noticeable between 40 and 50 Hz.
• I'm also using S-Curve acceleration and adaptive acceleration control (so, essentially scurve-shaping branch); the relevant parameters are max_accel = 5000 (accel_to_decel = 2500), min_accel = 1500, ao=4, square_corner_velocity=5.
• I mostly sliced models with 'lines' top and bottom infill, not zig-zag (Cura) that I frequently used in the past; not sure what you use and if it can affect anything.

A couple of recent prints with 2hump EI shaper as described above:

One mount for accelerometer for a delta smart effector (PLA). There's a bit of underextrusion and some gaps that were simply not filled by the slicer, but no described effect.

A box for Raspberry Pi (top cover, PETG). Also I believe no such defect. Both printed at 100 mm/sec infill and inner, 50 mm/sec outer perimeters.

FWIW, I've seen similar effect in the past on scurve-smoothing branch too, where infill lines fail to connect to the perimeters (usually of inner holes). Given that smoothing was very similar to ZV shaper, it is unlikely that it was related to smoothing. I suspect it was related to some processes in the hotend.

In your case, I'm not sure. But it does look like the problem exists regardless of input shaping, but it is possible that input shaping exacerbates it. Also, admittedly 35 Hz is too much of 3hump EI shaper. But 40 Hz 2hump EI should be somewhere on the boundary. But I did not personally test it at that config. I believe I did test it on ~46 Hz in the past, and I think I saw some rounding at high accelerations, but AFAIR closer to 4000-5000 mm/sec^2 (I might be mistaken).

[Sineos]

I followed this chapter https://github.com/dmbutyugin/klipper/blob/scurve-shaping/docs/S-Curve.md#best-tuning-conditions

with following settings enabled:

[printer]
kinematics = cartesian
max_velocity = 300
max_accel = 7000
max_accel_to_decel = 7000
max_z_velocity = 8
max_z_accel = 100

[input_shaper]
shaper_freq_x = 67
shaper_freq_y = 58
shaper_type_x = ei
shaper_type_y = ei

X-Axis:

Y-Axis:

(The "waviness" comes from vase mode extrusion with ASA filament, which starts warping badly after cooling on single walls)

I cannot see any ringing effect:

• Is this test meant to be run without shaping options enabled?
• Too low acceleration (my default is 3000)?
• Other user error?

Edit: log attached

klippy.log

[dmbutyugin]

@Sineos, the thing is, documentation for scurve-shaping branch is work-in-progress now and was not published yet really. That doc is still a copy-over from scurve-smoothing (as you probably have guessed, since it talks about [smooth_axis]), so much of its stuff is not relevant right now for input shaping part. I hope to finish the doc update this weekend.

Regardless of that, I think we have managed to establish good parameters for input shapers from your tests with accelerometer. Your latest test print confirms that (since you don't see any ringing). Which is really good and I suppose you can just use the config you've posted for [input_shaper] as is without further tuning. Just reduce max_accel to whatever you see reasonable (or keep it that way, FWIW). For max_accel you should actually look at your latest print you posted here and see if at any accel the corners of the test model become 'smooth' (normally the corners 'stand out' a bit due to pressure advance disabled, and it should actually stay that way, because input shaping is not a replacement of pressure advance). You should set max_accel in your config below that acceleration to avoid too aggressive smoothing of the prints.

[Sineos]

Well, I'm very happy with the results and the accelerometer testing was fun, too. Many thanks for digging so deep into this matter. I really admire the knowledge gone into the whole Klipper project generally and such features specifically.

(Thou ever since I have done the measurements, the results are annoying the hell out of me. I need to get rid of them)

[dmbutyugin]

@KevinOConnor FWIW, I ran a simulation of 2-hump EI shaper in your configuration using graph_motion.py script (so, shaper_freq=40Hz, damping_ratio=0.1 (default), accel = 3000):

I took the true resonance frequency = 30 Hz somewhat arbitrarily, but lower frequencies result in smaller positional errors (and below ~25 Hz - higher vibrations). It seems that the positional errors in this case are up to ~0.1 mm max due to input shaping. I'm not sure if the gaps you observed are of that order, or larger - it is hard to tell from the pictures, and I'm not very familiar with the US coins.

Separately, at 50 Hz 2hump EI shaper gives positional errors of ~.075 mm using the aforementioned parameters - indeed smaller, but not that dramatically. But 3hump EI shaper at 35 Hz can have up to 0.3 mm positional error already, especially at direction change - this will be very noticeable.

@Sineos

(Thou ever since I have done the measurements, the results are annoying the hell out of me. I need to get rid of them)

Sorry, I did not understand this part. What is the problem with those results? Or are you talking about the test prints?

[dmbutyugin]

@KevinOConnor FWIW, I've updated the tuning docs in scurve-shaping branch. For now they cover also adaptive S-Curve acceleration, but I will later make an excerpt from it that covers input_shaper specifically, and create a pull request for master Klipper branch.

[KevinOConnor]

@dmbutyugin

I used it mostly for test prints, but did some functional prints too, and didn't notice much of that effect.

Interesting. I did make some additional prints and the results are reproducible. Interestingly though, I can still see the problem with ei at 55hz (though it's less noticeable). Disabling pressure advance helps a little, but doesn't solve it (and of course it leads to some stringing). It's possible temperature is making it worse (this was on PLA with temp=195). I'm using slic3r and I've configured it to use wider "extrusion widths" than the default, which may also be contributing to the problem. Also, I have top infill speed set to 100mm/s so maybe that's also making it worse.

I'm not very familiar with the US coins.

FYI, the two holes in the part have a 5mm diameter.

I'll try to see if I can find print settings that make the problem less noticeable.

-Kevin

[Sineos]

@dmbutyugin sorry What I want to say: Every since I know of these resonance frequencies, I want to get rid of them. So it is entirely your fault, because you offered the possibility to measure it 😁 (thanks for it!)

[dmbutyugin]

@Sineos it is probably not what you'd want to hear, but you cannot :) It is pretty much that the laws of physics are against it. Any system has a finite rigidity, and a finite, non-zero moving mass. The resonance frequency is defined from the ratio of the two. Your only possibility is to increase the rigidity and decrease the mass, so that the resonance frequency increases. This has 2 main benefits: higher-frequency oscillations of the same energy have smaller amplitude (so are less visible), and at very high frequency they may too fine to be visible.

[slavedas]

@dmbutyugin when testing the shapers do you really want accel_order set to 2? Is this an attempt to keep print speed by simply shaping movements and using trapezoidal acceleration? Also, when running on a CoreXY what do we do if we turn it to 45 degrees and get different values? use the ones that are single stepper motor values (45 degrees to the axis?). It says we can run a second test, but then I don't know what to do with that test.

[dmbutyugin]

@slavedas

@dmbutyugin when testing the shapers do you really want accel_order set to 2?

Yes, that's the idea.

Is this an attempt to keep print speed by simply shaping movements and using trapezoidal acceleration?

It is an attempt to minimize the influence of multiple things at once. Also, many people may find using just [input_shaper] sufficient.

Also, when running on a CoreXY what do we do if we turn it to 45 degrees and get different values? use the ones that are single stepper motor values (45 degrees to the axis?). It says we can run a second test, but then I don't know what to do with that test.

Honestly, this was (and still is) a part of experimental tuning process. We didn't see any influence so far (meaning, so far we'e only seen that X and Y axis have their resonances, and XY and YX simply have a mix of X and Y). If you decide to run this test at 45 degrees, please share the results. It may help us figure out what to do with these results. But for now you can use the results of non-rotated model measurements.

[dmbutyugin]

@KevinOConnor, intersting.

Interestingly though, I can still see the problem with ei at 55hz (though it's less noticeable).

I do not think that positional errors with EI @ 55 Hz are noticeable. If anything, I'd think this is a good argument in favor of a theory that the true root cause of this effect is different.

I'm using slic3r and I've configured it to use wider "extrusion widths" than the default, which may also be contributing to the problem.

I'd think this may be a primary suspect (depending on how much the extrusion width is larger than the actual nozzle diameter), and the fact that PA seems to have some effect may also speak in favor of this theory. I know that many people successfully print with extrusion width > nozzle diameter. However, depending on how slicer implements attaching infill to perimeters, it may happen that the center of the toolhead doesn't really reach the perimeters when printing the infill. I.e. slicer may decide to move the toolhead only up to (nozzle_diam - infill_overlap) to the perimeter, assuming that the filament forms (half-) a circle at the end of a line, and it is sufficient that the side of that circle touches the perimeter for the infill line to stick to the perimeter. However, if the actual nozzle diameter is smaller, the filament may flow in different directions at the end of the line, and not really reach the perimeter and not stick to it. Additionally, PA may be reducing pressure at the end of a line even more, so there may be insufficient filament pushed out to reach the perimeter. Then as the toolhead moves in the opposite direction, it pulls the end of the filament line that didn't stick to the perimeter in the opposite direction, increasing the gap. This is only my theory, but I guess worth testing by setting extrusion width == nozzle diameter.

Separately, I'm not sure if the temperature can have an effect on this, but printing at higher speeds may require slightly higher temperatures than usual.

Also, I have top infill speed set to 100mm/s so maybe that's also making it worse.

I guess even if you used lower speeds for the top, it only may have masked the problem - since all internal layers would have this problem.

[ehtnevets]

@dmbutyugin , the manual_stepper move command is now working except when stop_on_endstop is used. When limit switch is triggered command performs as expected except subsequent commands are blocked until the expected time to finish the move has passed even the actual move stops earlier. i.e. MANUAL_STEPPER STEPPER=e1cam SET_POSITION=360 MANUAL_STEPPER STEPPER=e1cam MOVE=-12 SPEED=20 ACCEL=60 STOP_ON_ENDSTOP=1 Total dist is 372, expected time to finish ~20s. The system will not respond until ~20s has passed since the last command.

[dmbutyugin]

@ehtnevets Just for my understanding: does this happen only on scurve-shaping branch? Or is it also happing on Klipper master branch now?

[ehtnevets]

Well, it happens on master branch as well. It looks like a master bug, @KevinOConnor ?

[WindoC]

Hi all,

I try to tune and have some compare test print. Both using the same gcode but input_shaper. It reduces the ghost but seems lost a bit of the detail. Is it normal? Thanks!

[printer] delta_radius = 139.8 kinematics = delta max_velocity = 300 max_accel = 3000 max_accel_to_decel = 2000 max_z_velocity = 200 square_corner_velocity = 30 minimum_z_position = -10.0

[input_shaper] shaper_freq_x = 30 shaper_freq_y = 30 shaper_type = ei

Left is input_shaper turn off result and right is on.

input_shaper turn off. Detail of the "String" at the tail seems more clear:

input_shaper turn on. Compare with above is a bit not clear:

The log: klippy.log

[BlackStump]

@WindoC I would be curious to see the results with square_corner_velocity = 5 because to me at least 30 seems excessive. square_corner_velocity = 30 probably great for reducing print time but not good for much else. also why did you choose input_shaper=ei instead of mzv, my take is and @dmbutyugin please correct me if I am wrong ei has more smoothing then mzv so more chance of loosing the very fine detail.

[dmbutyugin]

@WindoC

You could try a few things to improve, in this order:

1. square_corner_velocity = 30 is way too high, I agree with @BlackStump. The recommendation is not to exceed the default 5 mm/sec. You should try this first (i.e. set square_corner_velocity=5), and it is likely that this will be the only thing you'd need to change. Larger values than 5 mm/sec may work, but are not guaranteed, and 30 mm/sec is really too high for quality prints.
2. I'm not sure if you selected max_accel = 3000 according to the recommendations, if not - please try them. I'm not sure what the outcome will be (will you get smaller or larger max_accel as a result).
3. If neither of the above works, you can try MZV shaper instead of EI. It is true that recommendation is to try EI shaper for delta printers, but if the resonance frequency is too low (and 30 Hz is probably at the borderline), then it may be that EI will not be the best choice. You can follow the suggested guide how to compare EI and MZV shapers.

[WindoC]

For suggestion 1. reduce the square_corner_velocity to 5. I try it and seem no different. So I perform a TUNING_TOWER test for setting SQUARE_CORNER_VELOCITY from 0 to 30. But there is no difference play with the SQUARE_CORNER_VELOCITY for the detail losing issue.

For suggestion 2, I use recommendations setting 7000 and no difference too.

For suggestion 3, Use MZV some of the detail back but the ghost increased.

I perform another TUNING_TOWER test for setting SHAPER_FREQ from 25 to 55 (type MZV). And found seem it smooth too much below frequency 40 Hz.

[dmbutyugin]

@WindoC

For suggestion 1. reduce the square_corner_velocity to 5. I try it and seem no different. So I perform a TUNING_TOWER test for setting SQUARE_CORNER_VELOCITY from 0 to 30.

Did you try printing a benchy with SQUARE_CORNER_VELOCITY = 5 and max_accel = 3000? And for the TUNING_TOWER test, which SQUARE_CORNER_VELOCITY did you have in printer.cfg at the time? Note that Klipper does not allow to set SQUARE_CORNER_VELOCITY from the command larger than the value in printer.cfg (so if you had SQUARE_CORNER_VELOCITY = 5 in printer.cfg, then SET_VELOCITY_LIMIT SQUARE_CORNER_VELOCITY=10 will not really do anything).

For suggestion 2, I use recommendations setting 7000 and no difference too.

Here the suggestion is not to just use 7000 max_accel. You need to set max_accel and max_accel_to_decel to 7000 and run TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1250 FACTOR=100 BAND=5 and print the test print. Then look at the print and select the acceleration that still does not smooth the details. BTW, perhaps the current tuning test is not very good at giving that information, since it does not have small fine details.

I perform another TUNING_TOWER test for setting SHAPER_FREQ from 25 to 55 (type MZV). And found seem it smooth too much below frequency 40 Hz.

FWIW, the frequency should be set from the resonance frequency. But I think your test can be illustrative in how much MZV smooths. BTW, which acceleration did you use here? 7000? And which SQUARE_CORNER_VELOCITY?

[BlackStump]

I made a model with some detail on the back which is actually hard for a slicer to reproduce. model picture of model before slicing picture of model after slicing picture of print There is a lot of light shadowing on the print picture which looks like print ghosting but it is just light shadowing, sorry about my poor lighting and photography.

I used this command TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=SQUARE_CORNER_VELOCITY START=0.5 FACTOR=0.33334 BAND=3 config details

[printer] max_accel: 4877 square_corner_velocity: 12.0

[extruder] pressure_advance: 0.30

[input_shaper] shaper_freq_x: 75 shaper_freq_y: 63 shaper_type: mzv

I stand corrected at least with square_corner_velocity from 1 to 10 not affecting fine detail as I thought it would and it would seem input_shaper is not affecting fine detail either, it is producing pretty much what the slicer is slicing.

[dmbutyugin]

@BlackStump I'm slightly worried that printing the text in vase mode is going to be rather difficult. I've modified a test print to have a small protrusion on each side, maybe that one will be easier to print and reason about?

I stand corrected at least with square_corner_velocity from 1 to 10 not affecting fine detail as I thought it would and it would seem input_shaper is not affecting fine detail either, it is producing pretty much what the slicer is slicing.

Perhaps. I wonder if 30 mm/sec is still too much? Also note that you have much higher frequencies - 75 and 63 Hz, at least 2x more than 30 Hz. This makes a huge difference.

@WindoC Did you manage to get anywhere with the tuning? If anything, I would suggest you try tuning from the start (or did you do that already?), especially now that the model has some small details that may help figure out the right parameters. Separately, my thinking is that if 30 Hz is true for your printer, for EI shaper you'd need to use ~5 mm/sec square_corner_velocity and decrease the acceleration to ~2000 mm/sec^2 as 3000 mm/sec^2 may be too much for that low resonance frequency.

[WindoC]

@dmbutyugin Thanks. I will try it later.

30 Hz seems is the best setting for me. I think it is a trade-off to turn on "Input shapers" for my case. Still, the enhancement is not bad.

[alocin73]

Hi,

i've tried measuring the ringing with ADXL345 on an ender3 (direct drive with stock stepper and glass bed).

this are the result: vib-th-x.txt

vib-th-y.txt

This is the actual configuration, not perfect, but better then everything i've tried until now.

` [printer] kinematics: cartesian max_velocity: 300 max_accel: 3000

max_accel_to_decel: 10000

max_z_velocity: 10 max_z_accel: 100 square_corner_velocity: 5

[input_shaper] shaper_freq_x: 46 shaper_freq_y: 42.5 damping_ratio_x: 0.05 damping_ratio_y: 0.05 shaper_type: ei

[scurve] acceleration_order: 4 min_accel: 800 ` X master

X EI

X EI s-curve

Y master

Y EI s-curve

Do you think i'm doing it right? If you need some particular test, feel free to ask.

For the Y axis it stop every time at 82hz with the following error: Traceback (most recent call last): File "/home/pi/klipper/klippy/klippy.py", line 185, in run self.reactor.run() File "/home/pi/klipper/klippy/reactor.py", line 251, in run g_next.switch() File "/home/pi/klipper/klippy/reactor.py", line 278, in _dispatch_loop timeout = self._check_timers(eventtime) File "/home/pi/klipper/klippy/reactor.py", line 136, in _check_timers t.waketime = waketime = t.callback(eventtime) File "/home/pi/klipper/klippy/extras/resonance_tester.py", line 132, in test_single_freq probe_time, meas_time, meas_offset, raw_output) File "/home/pi/klipper/klippy/extras/resonance_tester.py", line 285, in _run_test meas_time, meas_offset) File "/home/pi/klipper/klippy/extras/resonance_tester.py", line 371, in _calc_vibrations self._integrate(raw_values, i, j), File "/home/pi/klipper/klippy/extras/resonance_tester.py", line 384, in _integrate avg_ax = integrate(raw_values.ax) File "/home/pi/klipper/klippy/extras/resonance_tester.py", line 383, in integrate return res / T ZeroDivisionError: float division by zero klippy.log

the command was: TEST_VIBRATIONS X=117 Y=132 Z=20 AXIS=Y FREQ_START=10 FREQ_END=120 FREQ_STEP=0.5 OUTPUT=/tmp/vib-th-y.csv with max_accel and max_accel_to_decel set to 10000.

[dmbutyugin]

@WindoC

30 Hz seems is the best setting for me. I think it is a trade-off to turn on "Input shapers" for my case. Still, the enhancement is not bad.

Yes, 30 Hz is determined from the properties of the printer, so it should be set as it is, there is not much you can change here. You can still see if some other closer value works better with MZV, or use EI with 30 Hz. But, by adjusting other parameters (square_corner_velocity, max_accel) you can hopefully get less smoothing.

Edit: I would also invest into making the printer more rigid, so that the resonance frequency increases. For delta printers, there is this nice mod. I have installed it on my printer, and I can highly recommend it: it makes the frame very stiff, and reduces its wobbling quite a bit.

[dmbutyugin]

@alocin73 Thanks for sharing your experience!

A bit of feedback:

• I would not change damping_ratio to 0.05, I'd leave it at default (which is 0.1). Or was there a reason for you to change it?
• You could probably slightly adjust the settings to shaper_freq_y = 40 and shaper_freq_x = 50 - it may better cover different resonances that you have measured with the accelerometer.

For the Y axis it stop every time at 82hz with the following error:

I'll need to check, but it is probably that the vibrations get too small for the code to successfully find the start of the move. In general, the amplitude of vibrations is relatively small in your measurements, I don't know exactly why is that.

[alocin73]

@alocin73 Thanks for sharing your experience!

A bit of feedback:

• I would not change damping_ratio to 0.05, I'd leave it at default (which is 0.1). Or was there a reason for you to change it?

Looking at this graf, the intent was to smooth less the lowest resonance to avoid to mutch smoothing of the corner. Surely i dont understand how it work :)

Just to know, when is advisable to change the damping ratio?

• You could probably slightly adjust the settings to shaper_freq_y = 40 and shaper_freq_x = 50 - it may better cover different resonances that you have measured with the accelerometer.

I've chosen the ones in the middle of the resonances for the X and Y axis. Must the values ​​be chosen taking into account the resonance on all axes?

For the Y axis it stop every time at 82hz with the following error:

I'll need to check, but it is probably that the vibrations get too small for the code to successfully find the start of the move. In general, the amplitude of vibrations is relatively small in your measurements, I don't know exactly why is that.

It can be the stiffener on the frame? Or the soft gum under the printer?

P.S. I'm trying to write correctly in English, sorry for mistakes

[BlackStump]

@dmbutyugin

I'm slightly worried that printing the text in vase mode is going to be rather difficult. I've modified a test print to have a small protrusion on each side, maybe that one will be easier to print and reason about?

MY goal was always to make a model that is fast to print and to use as little as possible material but be difficult enough to print to show any problems that may or may not be there. S3D will slice the model in vase mode, ideamaker also had no problems reproducing to text tho I did not check if it was in vase mode. Of course layer height/width play a part in fine detail reproduction.

Perhaps. I wonder if 30 mm/sec is still too much? Also note that you have much higher frequencies - 75 and 63 Hz, at least 2x more than 30 Hz. This makes a huge difference.

I agree 30 is too high, 5 is default and should be the parameter to use for issues and testing. Yes too many variables with all the different printers out in the wild and the ever increasing variation in build qualities.

[robthide37]

Do you think their is any benefit to increasing sqv past say 10 or even 5 or really won't see time decrease. Also if mzv works great is it worth trying zv for less shaping if i barely saw ringing all the way to 7000 at 200mms and at 120mms had to really angle light to see one or two rings . at 5000 accel no ringing at 200mms. so i would say mzv is amazing btw i am at 50hz both axis on a corexy and i was running 4000 accel before with results that were identical to my 7000 accel settings now maybe a little worse actually. I was running 10 sqv tho and now am running 5 as per your rec

[robthide37]

Also i do believe that lack of positional error is making previous "workarounds" now ineffective. Like kevin had said i am using a .6 width with .4 nozzle and now i notice perimeters not reaching as well as they were but they were set to default superslicer overlap aka 15 percent and they should technically be 0 to just touch and rob around 30 to have no gaps . I actually have to think about this one now cause i am really not sure which way should go in a perfect zero backlash and zero filament spring theoretical application.

[dmbutyugin]

• I would not change damping_ratio to 0.05, I'd leave it at default (which is 0.1). Or was there a reason for you to change it?

Looking at this graf, the intent was to smooth less the lowest resonance to avoid to mutch smoothing of the corner. Surely i dont understand how it work :)

Hmm, I fail to understand how this chart relates to your point regarding damping ratio. So maybe it is that. Basically, the top chart shows how much of vibrations is left at the given frequencies and several possible damping ratios of the printer (0.05, 0.1, 0.2) when the shaper is configured for 42.5 Hz and damping_ratio = 0.1. So, the lower the better, and different lines correspond to different damping ratios of the printer. Normally, you don't know which line corresponds to your printer (because you don't really know the true damping ratio), but this chart demonstrates that the reduction of ringing is good for many possible damping ratios (0.05 is quite low and means not much of vibrations dissipation, and 0.2 is relatively high and vibrations quickly stop in this case) - that's why I think that 0.1 (the value for the input shaper) is a good default value.

Just to know, when is advisable to change the damping ratio?

Well, pretty much, never :) Unless you can confirm the actual value with some elaborate measurements.

• You could probably slightly adjust the settings to shaper_freq_y = 40 and shaper_freq_x = 50 - it may better cover different resonances that you have measured with the accelerometer.

I've chosen the ones in the middle of the resonances for the X and Y axis. Must the values ​​be chosen taking into account the resonance on all axes?

I would think it is better that way. Because it looks like certain frequencies excite vibrations of other axes (e.g. vibrations of X axis at 60-61 Hz seem to excite vibrations in Y direction). But these are still vibrations, so I would think it makes sense to cancel those too. So I would suggest you to try that configuration (50/40 Hz for X/Y) and see if that improves, or even not makes things worse visibly, I would keep that configuration.

Separately, for Y axis vibrations, did you move the sensor to the bed?

I'll need to check, but it is probably that the vibrations get too small for the code to successfully find the start of the move. In general, the amplitude of vibrations is relatively small in your measurements, I don't know exactly why is that.

It can be the stiffener on the frame? Or the soft gum under the printer?

I am not sure. It might also be the case that the frame of your printer has some very low-frequency resonances (the response chart grows towards 10 Hz), but you have some frame stiffeners, so it probably wouldn't be the case for at least X axis. You can check the belt tension however and if you have a play in any of the moving parts.

[dmbutyugin]

@BlackStump

MY goal was always to make a model that is fast to print and to use as little as possible material but be difficult enough to print to show any problems that may or may not be there. S3D will slice the model in vase mode, ideamaker also had no problems reproducing to text tho I did not check if it was in vase mode.

Sure, any feedback and suggestions are welcome. I welcome the feedback as to which approach better demonstrates the defects of smoothing, and I am fine either way.

[dmbutyugin]

@robthide37

Do you think their is any benefit to increasing sqv past say 10 or even 5 or really won't see time decrease.

The feedback from Kevin previously was that there isn't much point of increasing sqv past 5 mm/sec, as you get diminishing returns in print times. I'd say there's definitely no reason to go past 10 mm/sec (and better leave at 5 mm/sec, or at least confirm with some testing that 10 mm/sec does not make things worse).

Separately, I remember using higher sqv to reduce the effects of pressure advance - basically, since the toolhead would traverse the angles at higher velocity, it would have to retract less, which could make a difference on long bowden setups. But since the changes in PA algorithm last year, I'd say it is no longer worth it, as now you can get similar effect by bumping acceleration instead.

Also if mzv works great is it worth trying zv for less shaping if i barely saw ringing all the way to 7000 at 200mms and at 120mms had to really angle light to see one or two rings

Well, if it is all good, and you don't see any smoothing issues, then I'd say no need. Also, 50 Hz frequency should be well within a reasonable zone for MZV shaper.

Also i do believe that lack of positional error is making previous "workarounds" now ineffective. Like kevin had said i am using a .6 width with .4 nozzle and now i notice perimeters not reaching as well as they were but they were set to default superslicer overlap aka 15 percent and they should technically be 0 to just touch and rob around 30 to have no gaps .

I'm not sure, which 'previous "workarounds"' are you talking about? What have you been using before? Separately, I wounder if you would get those gaps at 7000 accel without input_shaper too? At any rate, it would be great to test less aggressive overextrusion mode, like 0.5 or better 0.45 line with 0.4 nozzle and see if the problem disappears?

[robthide37]

I mean 3d printing before klipper and even more so your fork has been a series of estimations and compromises and then we would mitigate these problems with pseudo solutions. Like combing,coasting and archaic jerk. And I am wondering if line width being larger and overlap "besides when for backlash" have been a case of this. Basically I almost feel like everything I thought i knew should go out the window and I should start from scratch as far as tuning my printer.Basically I really am nowhere near as advanced as most of you but i feel a combo of pressure advance and the tool path following more accurate path would make infill not squish into the perimeter as much .

On Mon, Jul 13, 2020, 3:07 PM Dmitry Butyugin notifications@github.com wrote:

@robthide37 https://github.com/robthide37

Do you think their is any benefit to increasing sqv past say 10 or even 5 or really won't see time decrease.

The feedback from Kevin previously was that there isn't much point of increasing sqv past 5 mm/sec, as you get diminishing returns in print times. I'd say there's definitely no reason to go past 10 mm/sec (and better leave at 5 mm/sec, or at least confirm with some testing that 10 mm/sec does not make things worse).

Separately, I remember using higher sqv to reduce the effects of pressure advance - basically, since the toolhead would traverse the angles at higher velocity, it would have to retract less, which could make a difference on long bowden setups. But since the changes in PA algorithm last year, I'd say it is no longer worth it, as now you can get similar effect by bumping acceleration instead.

Also if mzv works great is it worth trying zv for less shaping if i barely saw ringing all the way to 7000 at 200mms and at 120mms had to really angle light to see one or two rings

Well, if it is all good, and you don't see any smoothing issues, then I'd say no need. Also, 50 Hz frequency should be well within a reasonable zone for MZV shaper.

Also i do believe that lack of positional error is making previous "workarounds" now ineffective. Like kevin had said i am using a .6 width with .4 nozzle and now i notice perimeters not reaching as well as they were but they were set to default superslicer overlap aka 15 percent and they should technically be 0 to just touch and rob around 30 to have no gaps .

I'm not sure, which 'previous "workarounds"' are you talking about? What have you been using before? Separately, I wounder if you would get those gaps at 7000 accel without input_shaper too? At any rate, it would be great to test less aggressive overextrusion mode, like 0.5 or better 0.45 line with 0.4 nozzle and see if the problem disappears?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KevinOConnor/klipper/issues/3025#issuecomment-657738149, or unsubscribe https://github.com/notifications/unsubscribe-auth/APNYI6AVHEJIL2I65YYRT6TR3NLQBANCNFSM4OKGVTIA .

[dmbutyugin]

@robthide37,

the tool path following more accurate path would make infill not squish into the perimeter as much .

That is a good point. @KevinOConnor I'd think this could be another point: when the toolhead decelerates, it typically 'overshoots' its commanded position, and goes further than it is supposed to. In this case, when printing the infill, the infill could stick better to the perimeters. Now that we are 'fixing' the toolhead path with the input shaper, even without too much of smoothing, the toolhead may not overshoot its target position and this could make infill adhesion to the perimeters worse. If that's what really is happening here, then improving the toolhead cornering could reduce the print quality ironically (saying it differently, poor cornering could improve the print quality counter-intuitively). Then, we would need to tune infill overlap differently.

[alocin73]

Hmm, I fail to understand how this chart relates to your point regarding damping ratio.>

No, it's my fault, i pretend to understand too much some time(often...), thanks for the explanation.

Well, pretty much, never :) Unless you can confirm the actual value with some elaborate measurements.>

OK

Separately, for Y axis vibrations, did you move the sensor to the bed?

No, the sensor was on the tool head.

I am not sure. It might also be the case that the frame of your printer has some very low-frequency resonances (the response chart grows towards 10 Hz), but you have some frame stiffeners, so it probably wouldn't be the case for at least X axis. You can check the belt tension however and if you have a play in any of the moving parts.

I checked, and the belt were too loose. I also moved the sensor from the bl-touch bracket to the heatblock.

I measured again, this time on the tool-head and on the bed: vib_th_X.txt vib_th_Y.txt vib_BED_X.txt vib_BED_Y.txt

I'll try some new print with the settings you suggest and the default damping ratio this time.

Thanks again.

[BlackStump]

@dmbutyugin Thanks I am with you in regards to using what ever model that works to show the defect, I printed your model with the updated notches but I can not reproduce any fine detail problems on either model so we need someone that does have a issue to report back if the new notches do there job. In summary I can not fault the input_shaper.

[KevinOConnor]

@dmbutyugin , FWIW, the reason I use a larger than default extrusion width is because of https://github.com/slic3r/Slic3r/issues/3449 . That is, the default slic3r extrusion width settings actually cause the extruded tracks to overlap. So, I increased the extrusion widths so that the tracks would actually match the nozzle width..

As far as I know, all the recent slic3r derivatives (eg, prusa slicer) have this same bizarre behaviour.

To your point, though, since setting slic3r's extrusion widths are so complicated, it's unclear to me how slic3r implements its "infill/perimeters overlap" setting.. I've been meaning to investigate, but haven't had a chance yet.

-Kevin

[robthide37]

i went with .6 cause this https://dyzedesign.com/2018/07/3d-print-speed-calculation-find-optimal-speed/ it says speed but i suggest a quick read as it is about line width

[robthide37]

Also their is not much clear info on max accel to decel the test says to set it to 7000 as well but then to delete when done which would put it to half of the accel. Should we be setting it to equal the max accel we find or is it just to make sure the test isn't limited but in real world printing we don't want it to equal the accel

[robthide37]

https://s.amsu.ng/ZYZGta8m0emN 353mms @7000 ringing test Also I managed 353 mms with 7000 accel and no ringing this input shaping is amazing

[n8bot]

@dmbutyugin , FWIW, the reason I use a larger than default extrusion width is because of slic3r/Slic3r#3449 . That is, the default slic3r extrusion width settings actually cause the extruded tracks to overlap. So, I increased the extrusion widths so that the tracks would actually match the nozzle width..

As far as I know, all the recent slic3r derivatives (eg, prusa slicer) have this same bizarre behaviour.

To your point, though, since setting slic3r's extrusion widths are so complicated, it's unclear to me how slic3r implements its "infill/perimeters overlap" setting.. I've been meaning to investigate, but haven't had a chance yet.

-Kevin

I'm glad you have your eyes on this bizarre behaviour, too. I haven't been using slic3r since I abandoned it in 2014, but it amazes me that this "feature" is still present. All it does is add noise to the GCode.

There is really two related components to this odd behaviour:

1. Underextruding paths because of the "rectangular-path-paradox" i.e., our ideal paths are rectangular prisms, but physics gives us rounded sides.
2. Overlapping these paths in an attempt to fill the void left by rounded sides.

The slic3r manual is nice enough to document it for us, at least:

Slic3r flow math

In this documentation they describe how (and why) they underextrude paths. They also talk about how and why they overlap paths. The external perimeter remains positioned correctly, while all paths that contact it are overlapped slightly, with this formula:

spacing = extrusion_width - layer_height * (1 - PI/4)

Which, if we do the calculations, is almost always a value that is less than a full X/Y step. Essentially, purposely adding noise into the GCode that can't reliably be executed (the motor may, or may not achieve this position. It depends on a lot of things, really).

I don't know why I'm explaining all this to you, you are probably way too aware of this.

I'm not a software development expert, or a coding genius, or anything, but I've been trying to understand this problem better and I have been directed to the place in the Slic3r (fork) source code which they are implemented:

• perimetergenerator.cpp (in the beginning) for the use of it.
• flow.cpp for the multiplication.

The PrusaSlicer fork SuperSlicer has added a feature (link to commit) that can disable this (overlapping, not underextrusion) functionality, but it's a bit convoluted for my tastes. I would much prefer that the feature is just completely removed. I think many people would immediately see print quality improvement if both the overextrusion and overlapping of paths was removed from all Slic3r variants. (which is a moot point to discuss here, on the Klipper issue tracker... but I like hearing the sound of my own keystrokes I guess)

[dmbutyugin]

@robthide37

Also their is not much clear info on max accel to decel the test says to set it to 7000 as well but then to delete when done which would put it to half of the accel.

No, actually this is not how it works. max_accel_to_decel is only used to calculate the maximum velocity for the move, but Klipper uses the full acceleration for the move anyways (link). So there is no need to worry about that.

[dmbutyugin]

@KevinOConnor

As far as I know, all the recent slic3r derivatives (eg, prusa slicer) have this same bizarre behaviour.

To your point, though, since setting slic3r's extrusion widths are so complicated, it's unclear to me how slic3r implements its "infill/perimeters overlap" setting.. I've been meaning to investigate, but haven't had a chance yet.

I see. Yes, I must admit I do not know in much details how slicers deal with cornering and overlap. Moreover, I have been using Cura for the last few years, so I have not much of experience with Slic3r. Though I am not sure if there is similarly strange behavior in Cura.

My current thinking for the results that you have observed is as follows:

• Without input shaper, the toolhead overshoot the commanded position around the ends of infill (the error can be up to ~0.2 mm with 25 Hz resonance), so this helps with infill adhesion to the perimeters.
• With 2hump_ei at 40 Hz, the error is largely corrected (the positional error can be ~0.1 mm in the opposite direction, so the total difference is up to 0.3 mm vs no input shaper). This can lead to poorer adhesion of the infill, blesmishes increase.
• 3hump_ei shaper at 35 Hz smooths too much and can give positional error at the corner of up to ~0.3 mm (+0.2 mm positional error vs 2hump_ei at 40 Hz); position is about 0.5 mm different than with no input shaping - and blemishes become very visible all across the printed part.

Some illustrative simulation (3000 mm/sec^2 accel, 2hump_ei 40 Hz on the left, 3hump_ei 35 Hz on the right), the interesting point is at around 0.25 sec:

Still, it would seem that there are some issues with infill and perimeter overlap, and some weirdness in how the extrusion width is handled in Slic3r (and I have no idea how this affect the filament flow through the nozzle). It would probably make sense to compare with some other slicer, e.g. Cura - even another slicer has some hiccups as well, it very well may handle this case differently. And it would be great if we could find some workaround or recommendation what to do in this case so that we could put it in the docs. Fortunately or unfortunately, it would seem that ~50 Hz of my printer is rather high and not so much prone to positional errors of both direction, so even if I tried Slic3r, I don't it would change anything on my printer.