What is the state of accelerometer support and input shaping?

T3P3Tony · 11 Oct 2021, 17:47

@zapta input shaping is implemented in 3.4b, We should be releasing 3.4b5 soon which would be my recommendation as 3.4b4 has a bug with pausing that you may want to avoid. You can capture the data with 3.3 using the accelerometer plugin (different from input shaping plugin)

zapta · 11 Oct 2021, 19:06

Thanks @t3p3tony, I will play with the accelerometer with 3.3 and will wait for 3.4b5.

pkos · 15 Oct 2021, 07:34

This post is deleted!

pkos · 15 Oct 2021, 07:34

I'll latch on to this topic and ask about the future plans of Input Shaping and more specifically - separate values for X and Y.

With CoreXY - I values will be quite close together unless I mess up the build totally.

But with bedslingers - the variance to me has a chance of being much bigger and not always much can be done about it. Individual values would help here.

So... do you have plans to introduce individual settings for X and Y or is it going to be just one value for good?

T3P3Tony · 15 Oct 2021, 11:27

@pkos we will evaluate separate input shaping for X and Y, there is certainly a logical argument for it. As it stands it wont be part of 3.4 release though, so for consideration in 3.5.

pkos · 15 Oct 2021, 18:05

@t3p3tony Understood. Thank you for the answer.
Now I have to decide whether I will wait for 3.5 or sell my bedslinger (just as I was starting to like it ).

zapta · 15 Oct 2021, 18:22

@pkos said in What is the state of accelerometer support and input shaping?:

the variance to me has a chance of being much bigger

Have you tried to measure X and Y independently with the current RRF and see what you get?

pkos · 15 Oct 2021, 18:26

@zapta That's not the issue. We can already measure X and Y separately.

The problem is that you can only pick one value for both axis for the input shaper configuration and they can be quite different.

I am always quite reluctant to use comparisons to others, but unfortunately here Klipper does have the upper hand and allows for separate values on X and Y in it's input shaper config.

And I don't like klipper. Not one bit I like my duets.

zapta · 15 Oct 2021, 18:28

@pkos said in What is the state of accelerometer support and input shaping?:

The problem is that you can only pick one value

I wonder what value you got for X and what value you got for Y.

Klipper seems to have a good momentum. I want to give it a try. Not sure if I can use my Mini5 wiring as is and just flush Klipper firmware and add a SBC.

pkos · 15 Oct 2021, 20:26

@zapta I think there's a thread somewhere here about the mini and klipper support - and that it's not fully working yet.

Personally, I can't stand klipper and this would be the only thing that would push me towards it - independent IS on X and Y working on all modes - be it cartesian, corexy or corexz.

I dislike the fact that any config change requires you to restart the whole firmware, that you need the PI and SD Card to store data. If you shut the printer down too fast - you risk trashing the data on the SD card. Or the fact that you have no control over what's on the display if you use a mini 12864.

Soooo many problems

But this actually brings me to another question I hope @T3P3Tony would answer as well - independent X and Y would work on bedslingers, CoreXY and CoreXZ too, right? This would nicely cover the Voron family of printers.

EDIT: I see I never answered your question. I didn't get values yet. For now, I only have the newest beta firmware on a CoreXY and will start testing this soon. Here, values were pretty much the same on both X and Y. But I need to run a test print on the CoreXZ Voron Switchwire. There the values I expect will be very different.

zapta · 15 Oct 2021, 22:47

@pkos

"If you shut the printer down too fast - you risk trashing the data on the SD card. "

Is that because the use of the SBC? Is it the same for Duet /RRF with SBC?

I am running a standalone duet for simplicity, one less computer to maintain.

dc42 · 16 Oct 2021, 06:42

@pkos said in What is the state of accelerometer support and input shaping?:

That's not the issue. We can already measure X and Y separately.
The problem is that you can only pick one value for both axis for the input shaper configuration and they can be quite different.

Until you measure the resonances, you won't know whether you have significant resonances on both X and Y axes, and if so whether they are too far apart for a single shaper to suppress both of them adequately.

Also bear in mind that there is a cost to having different input shapers for X and Y. The cost is that the tool head no longer follows the path commanded by the GCode, because the X and Y accelerations have different profiles.

pkos · 16 Oct 2021, 14:59

@zapta Yeah, that's a general RPI problem. If you don't shut it down properly, you can get the card filesystem messed up.

I am also running standalone for the same purpose - simplicity.

@dc42 - I printed out a DAA test cube (one from thingiverse) - for now, this is faster for me than hooking up an accelerometer. The difference is about 7 Hz. Understood on the path problem. That is good to know and pushes us I guess more into trying to even out the frequency between the X and Y (but makes the whole thing so much more difficult) Then again, I guess it should be understood that any input shaper will impact the print and how close it is to the actual model used for slicing.

zapta · 16 Oct 2021, 18:03

@pkos said in What is the state of accelerometer support and input shaping?:

I guess more into trying to even out the frequency between the X and Y

@dc42 had a good point. What also matter is the relative magnitudes of the two resonances, not just the frequencies. If one dominates the other, possibly just targeting that frequency will provide a good solution.

dmpmassive · 17 Oct 2021, 23:06

@t3p3tony Hi There, would you mind checking my work too? I'm connecting an LIS3DSH to a Duet 2 WiFi

I think I've got it right for use with the Gcode provided in the Dozuki: M955 P0 C"spi.cs4+spi.cs3"

Cheers!

T3P3Tony · 18 Oct 2021, 05:59

@dmpmassive that looks correct.

zapta · 24 Oct 2021, 20:07

@dc42 said in What is the state of accelerometer support and input shaping?:

The cost is that the tool head no longer follows the path commanded by the GCode, because the X and Y accelerations have different profiles.

@dc42, instead of modeling independently by X and Y, can't this be modeled as a single frequency that depends on the direction of movement? That is, F = f(alpha) where F is the compensated frequency and alpha is the angle of movement on the X/Y plane.

The function f() can be acquired for example by measuring the dominate frequency in a few directions and then interpolating in between.

dc42 · 25 Oct 2021, 08:25

@zapta yes that would be possible. However, in many cases I suspect it will be possible to define a single input shaper that suppresses the major resonances of both X and Y axes. For example, a EI3 input shaper centred at 40Hz is effective over the frequency range 20Hz to 60Hz.

CNCModeller · 25 Oct 2021, 08:31

@dc42 so in my case I have most of my resonance between 10 and 20hz. Should I be using a wider band filter such as you mentioned above?

dc42 · 25 Oct 2021, 08:55

@cncmodeller said in What is the state of accelerometer support and input shaping?:

@dc42 so in my case I have most of my resonance between 10 and 20hz. Should I be using a wider band filter such as you mentioned above?

Probably, but I would need to see your accelerometer results to be sure.

I've put graphs of the vibration reduction for various input shapers at https://docs.google.com/spreadsheets/d/1R23r0KRFosGNWJEqsnCXL6ylpuayGqDvm8ocOszalV4/edit?usp=sharing.