What is the state of accelerometer support and input shaping?

zapta

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

@zapta I have tested a 2.7m USB-C cable and have had success

Thanks @jay_s_uk. BTW, the documentation mentioned I2C and SPI, which one is better for this application?

jay_s_uk

@zapta SPI is all that's supported in this implementation

zapta

Thanks @jay_s_uk. My accelerometer should arrive tomorrow and I can't wait to get some graphs.

I am quiet happy with the way my printer prints and even didn't turn on pressure-advance but sometimes things get into resonance which makes the printer noisier that I would like.

CabalSoul

@jay_s_uk

Since I know that you have also a predator, do you care to share the result of your resonance analysis?

Sadly I have more resonant frequencies and the input shaper isn’t helping much in my case. The most prominent frequency is around 41.5 hz and it looks like the zvd is my best option.

I was Even wondering if installing steppermotor
Dampeners would improve my situation.

zapta

Before I connect and cause any damage, does this wiring diagram look right? It's for a Mini5+2 and this accelerometer https://www.amazon.com/gp/product/B082W63MWL and is based on the information here https://duet3d.dozuki.com/Wiki/Accelerometers

T3P3Tony

@zapta It looks good to me

zapta

Thanks @t3p3tony. My printer currently has the stable version below. Do I need to upgrade (to what version?) to use the LIS3DSH and input shaping?

T3P3Tony

@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

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

pkos

This post is deleted!

pkos

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

@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

@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

@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

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