Input Shaping makes no difference whatsoever

infiniteloop

@mrdui said in Input Shaping makes no difference whatsoever:

It seems to me, according to the noise my Z axis makes during the print, that it compensates during the whole print, which, in my mind doesn't really makes sense because it would report the bed planeity errors over the whole print, so every face of it is being very slightly deformed.

I think you are looking for M376.

@mrdui said in Input Shaping makes no difference whatsoever:

Didn't want to edit config.g mid print

A wise decision: in order to apply changes from the config, you have to run config.g - a bad idea while printing. For modifications "on the fly", you simply send gCodes from the console.

oliof

@MrDui you would not need to change acceleration, but speed -- https://docs.duet3d.com/User_manual/Reference/Gcodes#m220-set-speed-factor-override-percentage

gnydick

This post is deleted!

Diamondback

@dc42 said in Input Shaping makes no difference whatsoever:

@mrdui do you have mesh bed compensation enabled, or move segmentation enabled? It has come to light that move segmentation interferes with input shaping, where the segment length or mesh spacing interval is too short to contain the acceleration or deceleration part of the move.

Interesting info, I heavily rely on mesh bed compensation and always failed to see any real difference with IS enabled...

MrDui

@infiniteloop said in Input Shaping makes no difference whatsoever:

I think you are looking for M376.

Oh, that's great, exactly the feature I was dreaming of! Thanks a lot for sharing it!
Noob question: should I put this gcode in the config.g or in the bed.g file?
I suppose probably in the bed.g file right after the G29 command ?

There's so many features in those firmwares it's hard to keep track sometimes.
Anyway, thanks, that will definitely help, I'll try it right away!

infiniteloop

@mrdui said in Input Shaping makes no difference whatsoever:

should I put this gcode in the config.g or in the bed.g file?

That's a really good question. As M376 is not persistent (i.e. doesn't survive a reset) and is not a property of the mesh either (the taper is not stored in heightmap.csv), we have several options - the config being one of them. bed.g is fine, too, as long as you always level your bed after a restart of the Duet.

As I do not use compensation all of the time, I have macros to switch it on (G29 S1) or off (G29 S2), and that's where I put M376, too. In case you want to apply taper on a per-print base, start.g is another option.

EDIT The S parameter of the second G29 command was wrong. Now corrected.

MrDui

@oliof said in Input Shaping makes no difference whatsoever:

@mrdui if you modify the speed of the printhead while printing, does the distance of the ringing artifacts change (should be wider when faster)? If not, the artifacts is likely not from printheads vibration but another cause like belt cogging or related phenomenons.

Ok so I did the test and it seems like the artifacts vary depending on the speed, as expected.

oliof

@mrdui OK. You can measure the distance between repeats of the ringing (peak-to-peak) and divide your speed by that distance to get the ringing frequency. Compare that to your accelerometer values and let us know what the results are.

MrDui

@gloomyandy I tried another print to check if the input shapers were active during the print after I click on apply, and it seems like the shaper is active indeed after applying it when I ask using M593. So everything seems to work perfectly normally, aside from the fact I get no actual difference on the print quality of course.

I think the issue might be in the input shaper code somewhere, as suggested by @dc42

So I guess I will have to wait for a fix someday, hopefully.
Let me know if I can be of any help for testing when/if this gets fixed!

Ah also I tried the bed compensation taper (M376) and it worked great, thank you very much @infiniteloop !!
(did no difference on the input shaper after the printer finished tapering though, same results during bed compensation and after tapering was done)

MrDui

@oliof said in Input Shaping makes no difference whatsoever:

@mrdui OK. You can measure the distance between repeats of the ringing (peak-to-peak) and divide your speed by that distance to get the ringing frequency. Compare that to your accelerometer values and let us know what the results are.

The measures indicate about 20 Hz. The accelerometer said 16Hz so I guess it's close enough.

oliof

@mrdui pretty close by, true. I would try with 20Hz mzv and a damping factor 0f 0.1 just to be safe.

MrDui

@oliof said in Input Shaping makes no difference whatsoever:

@mrdui pretty close by, true. I would try with 20Hz mzv and a damping factor 0f 0.1 just to be safe.

Doesn't make any difference at all.

oliof

@mrdui very interesting. Maybe due to the heavy print head?

gloomyandy

@mrdui 20Hz is a pretty low frequency for the input shaper. You might want to try something higher like 40Hz, just to see if that makes any difference. Some of the shapers cover a fairly wide frequency range so even if not on the primary frequency they may still help with the ringing.

MrDui

@gloomyandy said in Input Shaping makes no difference whatsoever:

@mrdui 20Hz is a pretty low frequency for the input shaper. You might want to try something higher like 40Hz, just to see if that makes any difference. Some of the shapers cover a fairly wide frequency range so even if not on the primary frequency they may still help with the ringing.

I've got the same result with 40Hz, and tried many other frequencies, both lower or higher.
I don't think its a problem of settings anymore, there would be at least some pattern change, it looks like it is just off.

gloomyandy

@mrdui Unfortunately whatever is happening on your setup is not a simple problem, input shaping certainly works on my own setup (which includes a height map, so I don't think that is the problem). The only difference I can see is that I either set the input shaper values directly in my config.g file (once I have tuned them), or set them manually via the console during tuning. I would suggest that you try that (simply enter the M593 command plus the required parameters in the console during the test print), to see if that works for you. Perhaps as suggested above the mass of your print head means that input shaping simply does not work?

MrDui

@gloomyandy said in Input Shaping makes no difference whatsoever:

@mrdui Unfortunately whatever is happening on your setup is not a simple problem, input shaping certainly works on my own setup (which includes a height map, so I don't think that is the problem). The only difference I can see is that I either set the input shaper values directly in my config.g file (once I have tuned them), or set them manually via the console during tuning. I would suggest that you try that (simply enter the M593 command plus the required parameters in the console during the test print), to see if that works for you. Perhaps as suggested above the mass of your print head means that input shaping simply does not work?

I've already tried that, unfortunately it didn't work.

It would be a bummer if it couldn't work on high mass setups, those are arguably the ones that need input shaping/inertia correction the most (at least I think so).
But I do understand that this is the very beginning of the implementation of this feature, so I'm not complaining or anything, I've been printing hundreds of kilos of plastic with this machine without input shaping over the past few years and I'm very happy with it! The ringing doesnt' bother me 99% of the time, it's only annoying when I try to print some very detailed parts, which rarely happens since most of the stuff I print is functional, not aesthetic.

Just reporting some strange behavior in case it helps improving the firmware is all. It could also come from my machine itself, but I assume if it were to be the case I would at least see some difference in the ringing patterns when trying different shapers, the same way I see different patterns after increasing the speed. It's a bit weird

deckingman

@mrdui Maybe what you are seeing isn't ringing at all. In fact, with an 8Kg print head I'd be very surprised if it is. Have you tried printing at different speeds to see if the pattern changes?

MrDui

@deckingman said in Input Shaping makes no difference whatsoever:

@mrdui Maybe what you are seeing isn't ringing at all. In fact, with an 8Kg print head I'd be very surprised if it is. Have you tried printing at different speeds to see if the pattern changes?

Yes, as suggested earlier by @oliof .

deckingman

@mrdui I have a theory which is purely conjecture, and based on two things that you have mentioned. Firstly that your print head has a mass of 8Kgs and secondly that you only see the artefacts when printing detailed parts. So it could be that small, probably segmented moves, start and end at some micro-stepping value in between full steps. However, because of the high mass involved, the current required to achieve that micro-stepping position, might be insufficient to hold it, so the steppers move either forward or backward to the nearest whole step at the start and end of each small segmented move. That positional inaccuracy might be what you are observing. Like I said, this is just conjecture.
Out of curiousity, what is this print head that has a mass of 8Kgs? I have a 6 input, liquid cooled hot end with parts made from stainless steel and brass as well as aluminium, mounted on a metal gantry between two parallel rails but that only has a moving mass of around 2Kgs. Above that, I have 6 extruders mounted on a separate gantry (the UV axes) which weighs in around 3Kgs. The combined mass of both gantries is around 5Kgs so I'm curious to know what your configuration is that has a mass is 8Kgs.