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

[BlackStump]

@dmbutyugin @KevinOConnor If I was to walk away from S3D my first choice to try would be Ideamaker I have used it a few times now and for a out of the box free slicer is works pretty well. But all slicers seem to have there quirks, kisslicer as a slicer works pretty well but the frontend is what puts me off every time. craftware I have looked at multiple times look at the settings think to myself I should give it whirl but never do, maybe it is ok but I have not used. icesl maybe has a lot of potential but needs programming skills to setup and get the best out of from what I can see, be nice if someone has gone and setup a klipper friendly config for icesl. Hard to find a slicer that ticks every box and does not have it own issues.

[n8bot]

[...] icesl maybe has a lot of potential but needs programming skills to setup and get the best out of from what I can see, be nice if someone has gone and setup a klipper friendly config for icesl. Hard to find a slicer that ticks every box and does not have it own issues.

I'm having the same slicer pains. I can not find one that works perfectly for me. That said, I'm kind of an IceSL fanboy. IceSL is the closest thing I've found to the perfect slicer, even though it's still quite a bit off from being 100% utter perfection.

What I like about IceSL is the configurable accuracy of the X/Y/Z toolpaths, and the impeccable consistency/accuracy of the extrusion amount values.

I'm still just a "Klipper observer," I have not had an opportunity to try it out yet, but I would be happy to help make a Klipper IceSL profile. I recently completed making a RepRapFirmware-specific profile template for IceSL, which could likely easily be re-purposed to work for Klipper. The profile I created can be seen here.

What are the differences in operation between RRF and Klipper? That would be the only question to answer, as well as other must-have features, and I could go ahead and make some changes to the profile to suit Klipper users.

[BlackStump]

@n8bot I would say RepRapFirmware is Gcode everywhere firmware, klipper is not. klipper Gcode I did make a off the cuff remark about icesl because I have not actually used apart from a basic test print so I really do not have the experience to say what would be needed. I am looking at your RRF profile and it looks very impressive.

[n8bot]

Thank you. I'm not sure if it's really that impressive, per se. What is impressive is the flexibility provided by IceSL to tailor the output as needed. It does not need to strictly be G-code. In theory, one could build a Lua script to pre-process a ton of the movement, as klipper does, and output a file of completely new format to send to the printer.

I digress, this might not be the most appropriate place to continue this discussion. If you go here you can create an issue in my IceSL profile repo, and we can sort out what needs to be done. I took a quick look, and I know that the temperature control Gcode will need to be changed from G10 based-commands to the traditional M104/M109 commands. This should be easy.

Please feel free to create an issue on my repo and we can go from there. (Make sure you create the issue in my forked repo -- I'm not affiliated with IceSL in any way! They'd be confused about your issue if it was on their main repo.)

[dmbutyugin]

@Fenixin, in the other thread you mentioned that you have ~33 Hz resonance frequency, and you did try EI shaper. Did you happen to observe an effect like described in this comment - the gaps between the infill and perimeters? If no, which slicer do you use and which line width vs the nozzle diameter?

@vadsh In the same thread about S-Curve acceleration you said that you have resonances on Y axis at 25 Hz due to large moving bed. Did you try to switch to scurve-shaping branch since then, or simply to the Klipper mainline, now that input_shaper is integrated? If yes, I have the same question: did you observe the effect of gaps between infill and perimeter lines with just [input_shaper] enabled?

[Fenixin]

@Fenixin, in the other thread you mentioned that you have ~33 Hz resonance frequency, and you did try EI shaper. Did you happen to observe an effect like described in this comment - the gaps between the infill and perimeters? If no, which slicer do you use and which line width vs the nozzle diameter?

I haven't printed that much recently. I will give it a look in the next prints. Right now I use PrusaSlicer. I'll report back when I have some results.

[robthide37]

i am going to ask supermerril to take a look at this since he added the perimeter overlap control he should have no prob adding the extrusion modifier control

[supermerill]

Some insight, to clarify things.

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)

there is no underextrusion/overextrusion. By default (100% ovelap), it will extrude exactly the volume of plastic to fill the given volume. If you set a "spacing" instead of a "width", it's exactly what you want. If you use a "square" function, you will have problem even more with dimensional accuracy.

Which, if we do the calculations, is almost always a value that is less than a full X/Y step.

I don't see the point. The line position depends also on the model. If you grow your model by 1,1245% for whatever reason and this does not align your 'full step' again, you can't blame the slicer anymore. A gcode path will almost never be at full step, or you're being lucky & printing a very simple piece.

I can add a "xy min step" feature to discretize the gcode output, so you'll have a blocky print.

[n8bot]

there is no underextrusion/overextrusion.

When I said underextrusion, I was only referring to the concept of lowering the extrusion amount to accommodate the rounded-edge cross section of extrudate. This concept of underextruding the paths seems silly to me. It only seems "helpful" on prints with relatively low resolution: thick layers, with wide traces. A user could merely lower their extrusion factor manually to achieve the same effect. On prints with small layer heights and thin extrusion widths, the difference in "width" caused by this flow math is ridiculously small. There is much more error in other parts of the system than the "error" that is trying to be corrected by these calculations.

As for the path overlap -- I guess it makes sense in the context of artificially lowering extrusion amount. But why play these silly games? I do not think they add up to a better experience. They certainly don't add up to more accurate or better-looking prints.

You say that the line position depends also on the model -- it should depend ONLY on the model. The software can't reliably adjust the location of every (internal) line and ensure they line up the way they should have before making the adjustments, especially when that adjustment purposely overlaps extrusion. It will introduce additional errors and noise.

It seems a bit like the ArcCompensation that was tried and removed from slic3r, which altered the centerline of corners to attempt to correct where the plastic ends up. I don't think trying to have the slicer to automatically adjust these things is the best approach on anything but the simplest models. The best approach (IMO) is to just follow the model 100%. This is what nearly every other slicer does.

Think about a gently sloped surface with a large radius -- how is adding this random noise to every layer supposed to help? I've seen what it does compared to slicers that don't perform these antics -- it performs worse. Randomly misaligned/oddly extruded layers.

Now, are the problems in the print tests I've done cuased directly because of the underextrusion and overlap? Maybe not. But that's where I'm placing my wager. It could also be caused by the fact that the extrusion values output by the Slic3r variants fluctuate 5 times more than the slicer (IceSL) that provides the cleaner print.

I don't think anybody is asking for discretized steps. I'm certainly not. I'm just suggesting it might be useful to remove all of these weird approximations that actually, IMO, show detrimental effects, and no benefit.

If you grow your model by 1,1245% for whatever reason and this does not align your 'full step' again, you can't blame the slicer anymore.

Ok, sure. But let the errors lay where they lay. Trying to adjust errors by adding more errors seems silly to me.

We've built physical systems with physical resolution. Let's let that physical resolution dictate error, and not introduce noise to the equation. Just my opinion. [Edit: This statement is quite ironic, in retrospect, being in the "input shaper" issue thread. Buuuut I consider the firmware part of that physical system. Once we hand off control to firmware, I don't mind a little bit of the 'ol messin' about with numbers. I'm sorry if I seem opinionated or rude, I just speak frankly and my tone is often not well-chosen.]

[robthide37]

The front and the back right both were better the back riight .15 test was perfect. I believe with the concentric and perimiter moving it actualy makes a slight oval on the back left one .I think thats why it happened. My next set i am turning off overlapping perimeters "the thinperimeter checkbox one that allows 2 perimeters converging to still print" so it uses gap fill instead and also setting both perimeter overlap to 0. I understand that it does move outside perimeter as the first setting out of the two integer value ones says the outer perimter will contribute to overlap. I would understand with that it would move the perimeter in slightly and then over extrude slightly to make up for this. I also was confused about setting line spacing manually ,is that an option currently as it seemed that supermerril was saying that would work . overlaptesttolerance_gage.3mf.txt

[robthide37]

i realized that the outer never moves it just allows you to set the distance between multiple inner ones an then you can also just have the inner shell not overlap the last one. See and my wife says i accomplish nothing when i stay home from work.

[supermerill]

A user could merely lower their extrusion factor manually to achieve the same effect

that would create underextrusion, it's not the same.

On prints with small layer heights and thin extrusion widths, the difference in "width" caused by this flow math is ridiculously small.

it's on small layer heights and BIG extrusion widths that the effect is small.

You say that the line position depends also on the model -- it should depend ONLY on the model.

So the extrusion width shouldn't exist? it's nonsense.

Think about a gently sloped surface with a large radius -- how is adding this random noise to every layer supposed to help? I've seen what it does compared to slicers that don't perform these antics -- it performs worse. Randomly misaligned/oddly extruded layers.

? what 'noise' , 'antics' you speak about ? And if a slicer is adding "Random" thing, something has gone very wrong imo. There is no random in slic3r (&derivatives).

It could also be caused by the fact that the extrusion values output by the Slic3r variants fluctuate 5 times more than the slicer (IceSL) that provides the cleaner print

depends on your settings. Also what do you mean by 'extrusion values' ? mm3/sec ?

Trying to adjust errors by adding more errors seems silly to me.

?? unless you have an angstrom nozzle diameter, you can't follow the exact shape of the object and you need to follow it from a distance. How that can be told as an 'error' ?

some lecture: Part strength evolution with bonding between filaments in fused deposition modelling Characterization and Optimization of Mechanical Properties of ABS Parts Manufactured by the Fused Deposition Modelling Process The effects of voids on structural properties of fused deposition modelled parts: a probabilistic approach

[robthide37]

Doesn't the granular control of the extrusion width kinda fix alot of these problems?

[n8bot]

@supermerill I think you're not understanding exactly what I mean when I describe the behaviour I'd prefer.

I do not want the extrusion width to be an infinitesimal. I want the extrusion width to be exactly like the user specifies, or the algorithm auto-calculates, without any of the flow compensation that is meant to correct for the extrudate becoming oval, instead of a rectangular prism.

Alongside that, I would want the overlapping of paths that is done to compensate for the reduced flow from above to be also removed.

E.G., if we have an extrusion width of 0.4, I want that calculated extrusion value to be exactly correct for a rectangular prism of 0.4 mm wide, and layer thickness height, and x length. I want the inner perimeters to be spaced exactly the extrusion width apart, i.e., 0.4 mm -- not 0.357 or something.

That is all I'm talking about.

Edit: Oh, right, as for the "fluctuation" comment I made about E value. I just mean the consistency. There are (very small) errors somewhere in the calculation that cause the min and max extrusion rate to fluctuate ~5 times more than the values output by IceSL. See the following images:

[robthide37]

question so when we turn the overlap to 0 percent it is still doing the flow math as if was spaced tighter ? Their is no chance it will then calculate off of the base number since its not being altered anymore . Or would it actually add more flow to try and compensate for the larger spacing ? I know i prob am not wording this best but i am not nearly as educated on the matter . in fact if i am not adding anything of value ill shut up and sit back at this point .

[n8bot]

question so when we turn the overlap to 0 percent it is still doing the flow math as if was spaced tighter ? Their is no chance it will then calculate off of the base number since its not being altered anymore . Or would it actually add more flow to try and compensate for the larger spacing ? I know i prob am not wording this best but i am not nearly as educated on the matter . in fact if i am not adding anything of value ill shut up and sit back at this point .

I do not think the flow math automatically changes based on removing the perimeters overlap. I'm no C/C++ expert, though, so I could be wrong.

[robthide37]

im trying this to see tolerance_gage.3mf.txt

[n8bot]

I confirmed yesterday that when the perimeter overlap External and Inner are both at 0%, the extrusion is still adjusted lower to "compensate for the rounded extrudate." Which, to some people, is undesirable behaviour.

I'm going to try removing the adjusted extrusion myself and see if I don't mess too much up. It should be as simple as removing all the different times it is calculated for various instances. I do not understand why it's calculated in so many places (at least three six that I know of). Wish me luck.

[n8bot]

[...] And if a slicer is adding "Random" thing, something has gone very wrong imo. There is no random in slic3r (&derivatives). [...]

I was digging around in PS source, and couldn't help but notice something...

        size_t num_samples = size_t(ceil(areas.back() * samples_per_mm2));
        std::uniform_real_distribution<> random_triangle(0., double(areas.back()));
        std::uniform_real_distribution<> random_float(0., 1.);

I'm just teasing.

[robthide37]

I confirmed yesterday that when the perimeter overlap External and Inner are both at 0%, the extrusion is still adjusted lower to "compensate for the rounded extrudate." Which, to some people, is undesirable behaviour.

I'm going to try removing the adjusted extrusion myself and see if I don't mess too much up. It should be as simple as removing all the different times it is calculated for various instances. I do not understand why it's calculated in so many places (at least ~three~ six that I know of). Wish me luck.

please lmk the outcome i am very curious. I would like to print a bunch of tolerance tests but where i think the best improvement would be is in part strength and possibly finish ,afaik a slightlyt thicker perimeter is always better especially if its being altered after i specify it

[n8bot]

please lmk the outcome i am very curious. I would like to print a bunch of tolerance tests but where i think the best improvement would be is in part strength and possibly finish ,afaik a slightlyt thicker perimeter is always better especially if its being altered after i specify it

I was able to remove the six occurrences of the "underextruded path" math, successfully build the project, and confirm that the paths are now extruded as rectangular prisms of extrusion-width width. However, I noticed a few more occurrences of the math that were written in a slightly different way, and weren't caught by my search and replace. I'll let you know.

As for your calibration print. I loaded it up the other day into slicer and I noticed that the model itself is really low resolution. You seem to be testing how well the tolerance between an inner cylinder and a cylindrical hole can be adjusted -- but those cylinders are very faceted. The facets don't even line up. I would recommend finding a model with higher resolution that can allow you to test the same thing, but where the cylinders aren't blocky, disoriented polygons.

[robthide37]

i am using a much better one that was a small quick one the main one i use is down to .05 which i caouldn't get it to go . im good to .1 at 150mms but i have to try slower if .05 even is possible

[robthide37]

Tolerance_tester.STL.txt

[robthide37]

the reason i use a tolerance test is i figure that any bonding issue would show most with clearances . either by them gettign loose from under extrusion or by them getting tight from the perimeters coming apart and being thicker. i figure it would show if any problems would come form this cause overhangs would be only other thing affected imo.

[n8bot]

That model is not much better. The parts which should be single bodies are made up of overlapping mesh shells. Also, the resolution is basically insufficient for what you're trying to test. The cylinders that are "free" sometimes overlap with the sections which contain it.

But that's not super relevant to this issue thread, I just wanted to point it out to you because it's testing the tolerance of the 3D mesh more than it's testing the tolerance of your printer.

[robthide37]

got it and i know wht your talking about but ill drop after . you have to lower the fill gaps in mesh under the slicing tab to .24 otherwise it makes it solid but if their are other probs ill look for better one. the setting is slice gap closing radius

[n8bot]

For anyone interested, I made a release for an updated version of PrusaSlicer with the odd flow math and spacing removed. Let me know if you find any problems with it, but it seems to work fine. Only windows version is built.

I also made a couple other changes, so read the notes on the release page:

PrusaSlicer n8 Precision Minus Edition

[robthide37]

For anyone interested, I made a release for an updated version of PrusaSlicer with the odd flow math and spacing removed. Let me know if you find any problems with it, but it seems to work fine. Only windows version is built.

I also made a couple other changes, so read the notes on the release page:

PrusaSlicer n8 Precision Minus Edition

Is this easy to transfer to superslicer and is their a reason you chose prusaslicer over superslicer ? I figured might just eb so less chefs in the pot

[n8bot]

I can try to port it over to SuperSlicer. SuperSlicer already implements features and settings which this change would interfere with. This is a pretty crude deletion of the math that calculates the flow and spacing from flow. I didn't realize that simply removing one would remove the other! In SuperSlicer, there is more control over specific instances of it.

I realized though, after releasing this, that stock PrusaSlicer has no Klipper support. Is that the problem? What other features would you need? I can see what will be easier: porting the changes to SuperSlicer or porting the features from SuperSlicer into my PS test branch.

[n8bot]

I've ported the Klipper support from SuperSlicer into my modified version of PrusaSlicer. I just took the 4 commits that I could find that mentioned Klipper. It has not been tested at all. Please confirm functionality before printing.

Keep in mind, this is just to test input shaping with the extrusion-width and path-spacing math reverted to "normal," not intended for long-term use.

PrusaSlicer n8 Precision Minus Plus Klipper Edition

[robthide37]

no the klipper support is great it just lets macros go through and i think changes the heating so it recognizes my start code the other stuff i could worry about later. i think mostly just some naming changes and little more control im trying now to see how it goes. one thing that i do for round prints or when i print carriages is i turn perimeters to like 10 so instead of solid infill its just all perimeters but with superslicer i get weird prints i think the spacing was the problem ill know shortly i am doing a polycarbonate print that last time was mess . none my threads printed right but cura did it no prob

[robthide37]

reverse on overhang prob the only real thing i would care about but it might do that when you select add perimeter as needed and imo idc for now this is just proof of concept like you said. Hopefully if i can get some real world proof merril will do it in his fork.

[n8bot]

The differences will be small, if noticeable at all. I generally am looking at my prints under magnification, if that gives you any clue about the hairs I'm splitting.

[robthide37]

i thought kevin had said he noticed something as well tho and thats why he calculated his line width ?

[n8bot]

Yeah, and this fixes that needed workaround, but the real-world effects/benefits of the original math and this change/removal are likely negligible, hence my comment about "adding noise."

In a system with a noise floor, x, we should not try to send signals as weak as 0.2x.

[robthide37]

got it . its ok once i get it perfect ill start looking for a diff upgrade or problem or lose interest and waste money and time on something else its a curse i love the build more than the use after . used to build water cooled and refrigerated gaming pc's but i don't play pc games lmao

[robthide37]

so i may have found an application and a reason for this which i will make seperate topic if that is the case. lithophane prints may be where this would make a difference

[robthide37]

could this be a case where the overlap is what is causing the issue meanwhile simplify3d slices it properly https://github.com/supermerill/SuperSlicer/issues/348#issuecomment-660681012

[KevinOConnor]

FYI, @jdlongenecker put together a youtube video on the input_shaper module: https://www.youtube.com/watch?v=pH-1RWdC75E

-Kevin

[dmbutyugin]

FYI, @jdlongenecker put together a youtube video on the input_shaper module: https://www.youtube.com/watch?v=pH-1RWdC75E

-Kevin

@jdlongenecker That's a really nice video!

[eddietheengineer]

@dmbutyugin thanks for all your hard work!

[zbrozek]

I gave this a whirl and it's amazing. There's probably still some room for optimization, but this is the most significant advancement in FDM quality I've seen in years. And it was painless to try out. Incredible.

[trevjonez]

Seeing similar great results on my MK3 Bear. 0.9 degree LDO motors being pushed by tmc5160's & Bondtech MK3 extruder .xyz all in stealthchop. Only able to get up into 3-4000 range for accel but still a huge improvement! Bit of tuning to go on the X still. Belt being too slack is suspect...

type: mzv

[DruckiMcDruck]

I'd also like to thank everyone involved. I tuned the input shaper on my AM8 and here's the result. I still got a tiny bit of resonance on the Y axis, but i haven't tried other types than MZV yet. Still an amazing result and i now need to improve my cooling because i can print faster than the part is able to cool down 👍

Settings:

[printer without input shaper]
acceleration: 1250 (bottom) to 7500 (top)
speed: 100mm/s

[printer with input shaper]
acceleration: 10000
speed: 250mm/s
pressure advance: 0.035
pa smooth time: 0.05

[input shaper]
x frequency: 55Hz
y frequency: 55Hz
type: mzv

[dmbutyugin]

Thanks all for sharing your experience!

@DruckiMcDruck, I think the quality improvement is really good in your case. I only had a small feedback that it looks like you have too much smoothing right now. In particular, the notch with a tiny gap seems to have a quite large gap in the input shaping mode than without it. Did you try to follow the part of the guide on selecting max_accel (link)? Or is your photo simply to demonstrate that even at 10K accel the ringing is not there? FWIW, I do not think that you need to use a different input shaper (MZV should be good at this resonance frequency).

[KevinOConnor]

Following up on my previous comments on "rounding of the corners" causing poor infill with input_shaper (https://github.com/KevinOConnor/klipper/issues/3025#issuecomment-652145579 ), I took a look at my settings for slic3r and found I had overlap set to 15% where the default is 55%. After changing overlap to 55% I no longer see the issue.

From left to right: no input_shaper (overlap=15%), 2hump_ei 40hz input_shaper (overlap=55%), 2hump_ei 40hz input_shaper (overlap=15%) (all had pressure_advance enabled):

So, with the higher overlap there are still some blemishes, but it's no worse than before.

I'm not sure why the larger overlap setting is so important with input_shaper. I looked at the generated slic3r moves and it does perform overlap based on the actual "line spacing" and not its bizarre "extrusion width". Sadly, my analysis found that slic3r over-extrudes at the perimeters with increasing overlap, but so far I haven't seen it adversely impact quality.

Anyway, ultimately, I found increasing overlap to be a simple fix for the problem. -Kevin

[dmbutyugin]

@KevinOConnor BTW, did you try to print the updated test model which has a test for too much smoothing built-in?

[KevinOConnor]

BTW, did you try to print the updated test model which has a test for too much smoothing built-in?

I just ran two prints. Unfortunately, it doesn't look like that test works great when using a single wall print on this particular printer. (I'm using a 0.35mm nozzle and a relatively low print temperature - rapid movements of the nozzle tend to pull the filament with it.)

I can see the gap getting slightly larger with input_shaper as the acceleration increases, but there is a noticeable gap even at low acceleration (and even when input_shaper is disabled).

It's hard to see on the camera, but here's two pics (top is 2hump_ei input_shaper 40hz, bottom is no input_shaper, both have PA enabled (which doesn't seem to change for me when I enable input_shaper)):

I guess I could try the print with 2 or 3 walls to see if I can get a signal that way.

-Kevin

[dmbutyugin]

Yes, printing 2 walls should help with this effect. But will take more time to finish, of course.

Separately, it may be happening in prints in general (pulling the filament by the nozzle), and be one of the reasons for blemishes.

[robthide37]

https://duet3d.dozuki.com/Wiki/Gcode#Section_M593_Configure_Dynamic_Acceleration_Adjustment Did they copy you already ? @dmbutyugin