What is the state of accelerometer support and input shaping?

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.

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.