[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.

[dmbutyugin]

@KevinOConnor Hi Kevin,

I wanted to discuss the following idea regarding input shapers: smoothed lookahead, as it stands in the documentation, is designed to reduce the vibrations of the printer and reduce the stress on it. However, when input shaper is enabled, it itself generates a motion to reduce the vibrations. So I wonder if it would be a good idea to increase max_accel_to_decel parameter from its default max_accel * 0.5 when input shaper is enabled? For example, this could be recommended in the tuning guide, to set it to something like max_accel * 2 / 3 or max_accel * 0.75 (or even to max_accel itself). This would reduce the print times, potentially considerably, without significantly impacting the quality of the prints or increasing the printer vibrations too much. I have already been using Klipper in this setup (max_accel = 3000 and max_accel_to_decel = 2000 on Ender 3 Pro) for a while without any issues.

[KevinOConnor]

I do think that "smoothed look-ahead" is a bit of a hack. I'm certainly open to replacing it with something else. I'm not sure that input_shaper is a good replacement though.

FWIW, I think of input_shaper as being good at preventing resonances in the 30+ hz range. I think of "smoothed look-ahead" at targeting resonances in the 1-10hz range. This was just my high-level impression though, so I could be totally wrong. It's also worth pointing out that max_accel_to_decel isn't great at suppressing resonance in general.

We can certainly tune the default max_accel_to_decel. However, when I last tested this (with a handful of prints run in "batch mode") I generally didn't see a huge time difference in total print time. The code tries to target "troublesome" moves - it doesn't impact long moves. It also should have minimal impact on moves that are largely in the same direction.

The impact can vary pretty dramatically from print to print and with slicer settings (eg, with different infill patterns) though.

At a high-level, if there is interest in changing the default, one way to proceed would be to identify some "typical prints", check the differences in print time, and then make a judgement call if that additional time is a "good thing" or not.

-Kevin

[yschroeder]

A typical print where smoothed lookahead saves my printer is a long thin bar with a few millimeters of infill between the outer walls and rectilinear infill at 100%.

A marlin firmware would shake like mad (seen on a stock prusa i3).

[dmbutyugin]

A typical print where smoothed lookahead saves my printer is a long thin bar with a few millimeters of infill between the outer walls and rectilinear infill at 100%.

That's in general a good point, so I do not propose to eliminate the smoothed lookahead at all - after all, not all folks use input shaper for one reason or another. However, when input shaper is enabled, the smoothed lookahead can be set to a more aggressive motion planning (by bumping up max_accel_to_decel). So maybe the only thing that's necessary is the documentation update.

@KevinOConnor

FWIW, I think of input_shaper as being good at preventing resonances in the 30+ hz range. I think of "smoothed look-ahead" at targeting resonances in the 1-10hz range.

My understanding is that smoothed lookahead gives printer some time to 'stabilize' the cruise motion and let vibrations die out (due to damping) before the deceleration phase. I'm not sure about the range of frequencies though; I imagine this effect can work for a wide range of frequencies.

We can certainly tune the default max_accel_to_decel. However, when I last tested this (with a handful of prints run in "batch mode") I generally didn't see a huge time difference in total print time. The code tries to target "troublesome" moves - it doesn't impact long moves. It also should have minimal impact on moves that are largely in the same direction.

I'll try to run some batch-mode simulations. I would generally expect this to have some effect on small models (or with small parts, at least in one of the dimensions) sliced with high print speeds. I do not expect this to have any significant impact on very large models. FWIW, there is subjective perception of printer 'speeding up' on small models, even if the total print time reduction is not very significant.

At a high-level, if there is interest in changing the default, one way to proceed would be to identify some "typical prints", check the differences in print time, and then make a judgement call if that additional time is a "good thing" or not.

So, maybe the right approach would be not to change the default, but have a suggestion in the input shaper tuning guide about this possibility, and also mention when one may expect to see any improvements.

[yschroeder]

My understanding is that smoothed lookahead gives printer some time to 'stabilize' the cruise motion and let vibrations die out (due to damping) before the deceleration phase. I'm not sure about the range of frequencies though; I imagine this effect can work for a wide range of frequencies.

I understood that smoothed lookahead would check if the nominal print speed can be reached with normal acceleration (the full acceleration ramp is used) before it needs to decelerate again. If not, it uses the lower accel_to_decel value. The ramps will still not be fully used (they are even longer after all) but when changing from acceleration directly to deceleration without some constant speed travel in between, the overall acceleration at the point where acceleration and deceleration meet is halved (as accel_to_decel is generally half the normal acceleration).

[dmbutyugin]

Not really. It uses accel_to_decel to check which velocity it can reach (pic), but then it uses full max_accel for real acceleration and deceleration. So accel_to_decel is only used to limit the cruising speed. But the default accel_to_decel = 0.5 * max_accel ensures that there is some cruising after each acceleration.

[Sineos]

I'm using max_accel = 3000 and max_accel_to_decel = 2000 since quite a while now and I'm happy with the results in combination with the shaper.

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[aschor]

Hi, It's been a while I've printed PLA, for long time I've printed PETG without issues (faceshields etc, and PETG reflects more easilly resonance). fact is that with PLA, speed 100mm/s accel 4000mm/s2 and pressure advance 1.38, my extruder is skipping steps on input-shaping (bondtech on TMC2208, stealthshop disabled, 0.7 A run_current) . I had disabled "scurve" for testings, I'll try to re-enable it and see if I can avoid skipping steps on extruder. But it seems like scurve, at least to me, is a life-savier even with input shaping.

[Sineos]

pressure advance 1.38

If this value is correct then it is no surprise. PA values over 1 do not work.

[dmbutyugin]

pressure advance 1.38

If this value is correct then it is no surprise. PA values over 1 do not work.

In general, PA=1 is not a magic number above which PA does not work. PA coefficient is a dimensional value (in mm/(mm/sec)=sec), and so PA=1.38 sec is just another value. But I agree with a general sentiment: higher PA values put more stress on extruder and force to limit the acceleration to lower value, and at some point PA becomes prohibitively limiting the max_accel. And PA~=1 is frequently quoted as a turning point.

So, @aschor, I would say that max_accel=4000 is indeed too much with PA=1.38. BTW, if you printed PETG previously, did you update the PA value for PLA? In my experience, PETG requires 15-20% higher PA values than PLA, probably because it is more flexible.

... my extruder is skipping steps on input-shaping

FWIW, input shaping does not change extruder kinematics in any way. So this behavior will very likely remain if input shaping is disabled.

But it seems like scurve, at least to me, is a life-savier even with input shaping.

Can you elaborate why? Because of the bowden extruder and high PA values? Or because it helps further reduce ringing? Or because of something else?

[aschor]

In general, PA=1 is not a magic number above which PA does not work. PA coefficient is a dimensional value (in mm/(mm/sec)=sec), and so PA=1.38 sec is just another value. But I agree with a general sentiment: higher PA values put more stress on extruder and force to limit the acceleration to lower value, and at some point PA becomes prohibitively limiting the max_accel. And PA~=1 is frequently quoted as a turning point.

that's my experience, for this particular filament, I DID tune the P.A. and it worked on the test pattern @1.38, or I would not have set it. But the test pattern is printed at low acceleration, so speed/acceleration are not limiting factors.

So, @aschor, I would say that max_accel=4000 is indeed too much with PA=1.38. BTW, if you printed PETG previously, did you update the PA value for PLA? In my experience, PETG requires 15-20% higher PA values than PLA, probably because it is more flexible.

As a matter of fact, I have very different kinds of filaments : I have some PLA that require 0.92 P.A., and those I can print at 100mm/s 4000 mm/s² with no fear. my PETG requires 1.05 P.A to work nicely at 80mm/s, 4000mm/s² and 0.28mm height. And I have this metallic-ish glitter PLA that requires 1.38 P.A.

... my extruder is skipping steps on input-shaping

FWIW, input shaping does not change extruder kinematics in any way. So this behavior will very likely remain if input shaping is disabled.

But it seems like scurve, at least to me, is a life-savier even with input shaping.

Can you elaborate why? Because of the bowden extruder and high PA values? Or because it helps further reduce ringing? Or because of something else?

As a matter of fact, I was wrong. Or more specifically, when I was on branch "scurve-smoothing-jerk-limiting" (or something like that ?) when there was no input shaping, S-curve+jerk did help reduce stress on extruder, by limiting acceleration at that driver I suppose.

But I tried with my filament to re-enable s-curve (on input shaping), I upped the TMC run_current to 1.15A, I upped the temperature up to 220°c ...... and it was better until I got heat-creep... cough .... I have not tried to lower acceleration, that a good next experiment. For now, with metalic filament, I can't go pas the absolute maximum of 80mm/s with 0.4mm nozzle and 0.2mm layer height and 4000mm/s² acceleration

[dmbutyugin]

It is possible that metallic filament creates more resistance to the filament flow and therefore requires higher PA values, or maybe it is more flexible. All I'm saying is that PA=1.38 and max_accel=4000 are probably not going to work very well together. But maybe s-curve can help a bit due to specific acceleration profile (that is also applied to extruder) and additionally limiting acceleration on short moves.

[Sineos]

As a matter of fact, I have very different kinds of filaments : I have some PLA that require 0.92 P.A., and those I can print at 100mm/s 4000 mm/s² with no fear. my PETG requires 1.05 P.A to work nicely at 80mm/s, 4000mm/s² and 0.28mm height. And I have this metallic-ish glitter PLA that requires 1.38 P.A

I would recommend to work on your bowden setup. Going from a 75cm bowden down to 50cm did lower my PA values by around 30% to 40%.
Using high quality bowdens, e.g. Capricorn, together with high quality push-fits did bring another 5% to 10%. Best results I have obtained using hydraulic screw couplings with a ferrule insert into the bowden (my worst materials, like ASA, did require PA 0.70 in this setup).

But I never will regret my move to a direct drive. With the "normal" printing speeds and accelerations, the added weight plays no role in my opinion but the quality boost is significant.

[Deneteus]

I followed the FAQ for input shaper. I got the ADXL345 hardware installed. It works with the ADXL345SPI utility and I can see the output in Octoprint but I cannot get past this error even though I have completely removed and re-install numpy. I have literally tried starting from scratch and numpy actually works.

BTW I also tried installing Numpy in a virtual environment in the Klippy-Env folder.

[dmbutyugin]

@Deneteus In the future, please refer to the contacting instructions to request help with Klipper software. FWIW, in this case your command pip show numpy does not indicate that numpy was correctly installed to ~/klippy-env following the instructions as described.

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[WojciechBednarski]

Hello,

Is it possible to make the accelerometer collecting samples during the regular prints?
I believe raspberry has plenty of power to make it (especially 4B), and it could be used to determine on regular basis if something is not deteriorating in the mechanics

[KevinOConnor]

Input shaper has been extremely successful and it is a very impressive feature! At this point, I think at this point we can close this github issue as I think the original goals have been met. Let me know if otherwise.

Thanks,
-Kevin

[github-actions]

This ticket is being closed because the underlying issue is now thought to be resolved.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.