Input Shaping makes no difference whatsoever

gloomyandy

@mrdui said in Input Shaping makes no difference whatsoever:

Do you mean that if I click on "Apply" next to the selected input shaper it doesn't send the command to apply this shaper configuration and use it and I actually have to send it manually? That would explain why it wouldn't work, but that would be strange, what would be the purpose of the "Apply" button then?

I don't know if pressing that apply button during a print will be setting the input shaper configuration. The "normal" use for those settings is while testing different configurations with the acclerometer. The best way to check what is happening is to....

In the console run M593 this should display the current input shaper settings.
Start your test print.
Set an input shaper configuration using whatever method you have used before.(make sure you use a different setting to whatever is shown by the M953 in step 1).
Switch back to the console and run M593, does the output match what you have just set?

If the above shows that the settings are not being made, you can easily change the input shaper settings during a print by simply running M593 with parameters to set your desired configuration. See: https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m593-configure-input-shaping for the available options.

MrDui

@gloomyandy I just did as per your recommendation and it seems like it does apply the input shaper when i press on "apply" then check with M593. But there is still no difference on the print result.
Very weird.

oliof

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

gloomyandy

@mrdui Just to be clear did you check the Apply/M593 during a print (as it may do things differently if a print is not active)?

As a further data point I've often used that same test print to check input shaping options and have certainly seen differences in the print quality. But when doing that I've always applied the input shaping values by entering them into the console during the print.

One thing I noticed is that you have a relatively low acceleration limit set on X and Y. I wonder if that might be preventing input shaping from operating correctly? It might be worth temporarily increasing that limit to see if it changes anything.

dc42

@mrdui said in Input Shaping makes no difference whatsoever:

I indeed use mesh bed compensation, so there might be something there. Is there any workaround? I really need the bed compensation on this machine because its size makes it difficult to find a mirror flat enough to get consistent good first layers on the whole surface.

Do you use Z hop? I am looking at change the code so that if a travel move is executed when Z hop has been used before that move, segmentation won't be used on that travel move. So the height at the end of the move will still have mesh compensation applied, but the intermediate points won't. This should be OK provided that the amount of Z hop is greater than the maximum compensation amount in the height map.

MrDui

@gloomyandy said in Input Shaping makes no difference whatsoever:

@mrdui Just to be clear did you check the Apply/M593 during a print (as it may do things differently if a print is not active)?

No I did it at idle, I will try during a print tomorrow just to be sure, but I'm pretty confident it will be the same (still gonna try it for good measure)

One thing I noticed is that you have a relatively low acceleration limit set on X and Y. I wonder if that might be preventing input shaping from operating correctly? It might be worth temporarily increasing that limit to see if it changes anything.

Yeah I wondered about that too, I can go higher on accelerations just to try it.

MrDui

@dc42 said :

Do you use Z hop? I am looking at change the code so that if a travel move is executed when Z hop has been used before that move, segmentation won't be used on that travel move. So the height at the end of the move will still have mesh compensation applied, but the intermediate points won't. This should be OK provided that the amount of Z hop is greater than the maximum compensation amount in the height map.

I have z hop enabled for every travel <5mm, optional for any travel >3mm. z hop height is currently set up at 0.5mm

Earlier you were mentioning bed compensation, and I have a question regarding how bed compensation works, if you don't mind:
Does it compensate for the bed planeity during the whole print or only for the first few layers?

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.

Wouldn't it be better to compensate the bed deformations for just a few layers that we could define ourselves, the printer gradually correcting by averaging differences layer after layer so it eventually comes down to no correction after a while?
In my opinion that would marginally correct some tiny inacuracies, but more importantly on my machine at least, this would make the Z axis a lot quieter.

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.

Yeah that's a good question, I wanted to try that but I couldn't remember the command to change the acceleration while the printer is running. Didn't want to edit config.g mid print since I was afraid it might cause some trouble.
I'll try that too and report back

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.