What is the state of accelerometer support and input shaping?

pkos

@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

@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

@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

@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

@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

@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

@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

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

WiFi Hookup.png

T3P3Tony

@dmpmassive that looks correct.

zapta

@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

@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

@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

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