Z axis input shaping is not something that other firmwares do. KUSBA is also dependent on the Klipper multi MCU implementation.

One way to get measurements from an accelerometer is shown in https://www.youtube.com/shorts/OjjMlhe9nOs (unfortunately unpublished, TL;DW: accelerometer taped to moving part with processing and display of results on an m5stick)

Interesting. Thanks for sharing. I am unsure what multi-MCU support is, but I don't understand why we need 'multi-MCU' in Marlin firmware. I suggest the calibration is done on the host (being a microcontroller), so not Marlin. Marlin has then to take the settings using M593 and M493. I'm only requesting Z-Axis Input Shaping support in Marlin Firmware. This way, Marlin should not have to deal directly with the accelerometer, usually having limited hardware to do so.

For example, OctoPrint, running on a printer host, could handle the accelerometer hardware and measurements and then send it to Marlin. I suggested that here: OctoPrint/OctoPrint#4912.

I guess I misunderstood your initial issue description then; the m5stick solution I showed does what you ask for (but you would still manually input the results).

I still don't understand why you say Z measurements are needed, input shaping is applied to fast moves in X and Y only, never on Z. The only reason you see 2 accelerometers on bed slingers is that you measure the Y on the bed and X on the nozzle (and this could be done by two separate runs with a single accelerometer as well).

Using Input Shaping on X and Y makes most sense indeed as they are moving faster. Sorry, I did make a mistake in my previous text, which I will clear up.

Essentially, Z-Axis Input Shaping would allow for faster and smoother Z-axis movement. It is especially helpful for things like non-planar Prints.

It is for example also suggested here: https://klipper.discourse.group/t/feature-request-advanced-input-shaping-for-klipper-dynamic-mass-y-axis-x-in-relation-to-z-height-z-axis-input-shaping/7642.

I wonder how prominent Z ringing is in real world prints, with only a few mm of travel at a time. Tests are necessary before considering implementation. For now i see Z shaping as very least concern of non-planar prnting. Gotta have working, maintained slicer first.

Z-Axis Input Shaping would allow for faster and smoother Z-axis movement

@JaneX8 Can you give an estimate of Z axis speed that you expect with Z-axis input shaping? What kind of issues do you personally have where you don't have enough speed and acceleration for Z?

With Z, it's either bed or toolhead that is moving and you can't move it fast because both of those are heavy. Realistically, even for non-planar prints distance in Z direction is so small (due to nozzle clearance) that you won't be getting speeds that are close to what you get in X and Y directions anytime soon.

I would like to but I'm not sure I will be able to answer that.

For me personally, I use a Creality Ender 3 V2 with dual axis upgrade. The Z axis speed for that printer is also discussed here: https://www.reddit.com/r/3Dprinting/comments/10ehzf1/can_i_damage_my_ender_3_v2_if_i_increase_the_max/. I think the max mechanical speed is up to 150mm/s or 180mm/s. But that's probably not what you meant. However, I'm planning to experiment with non-planar prints, where Z axis speed will matter more, maybe I'll be even upgrading my printer for that.

Again, I know the z-axis is the slowest (in planar prints) and I know nearly enough about Input Shaping, I just suggested an idea to get support in Marlin because that's basically the fundament on which many build.

I think KUSBA or any other USB accelerometer, connected to a host of a printer would make Input Shaping very accessible to many even budget printers, and low entry because it doesn't require any soldering or wiring. All I'm requesting here is to consider supporting Input Shaping on all axes (and take the values from the host using some G-code), Marlin is used on a huge variety of printers so my personal acceleration speeds won't matter much.

I think KUSBA or any other USB accelerometer, connected to a host of a printer would make Input Shaping very accessible to many even budget printers

For that you need printer to act as USB host, which is not possible for (probably) most Marlin-based printers

To clarify by 'Printer Host' I meant for example a computer or Rasbperry Pi (OctoPi/OctoPrint) that controls the printer. In my case I print everything through OctoPi, which controls the printer over USB from the Raspberry Pi to the Creality Ender 3 v2 printer. Clearly the printer itself wouldn't have capabilities for adding USB devices, or perhaps even any accelerometer. So, in this case I'm thinking to connect a device like KUSBA to my Raspberry Pi, which can then use it to do Input Shaping calibration on demand, as it can control the printer and it can read the accelerometer, automated.

This should theoretically already be possible which is why I requested that here: OctoPrint/OctoPrint#4912 (comment). The point of this issue in the Marlin repo is simply for Z-Axis Input Shaping.

KUSBA or any other USB accelerometer, connected to a host of a printer would make Input Shaping very accessible to many even budget printers

It's very accessible now, including AVR, and you dont have to buy accelerometer. It's nice fancy option, but calibration print works perfectly fine.
Again, necessity of Z shaping is extremely questionable. For anyone to consider working on it, at bare minimum, you must provide real world usecase and benefits. Starting with photos of prints affected by Z ringing.

I have a situation that would benefit from input shaping in Z:
My Ultimaker 2 (replaced 32 bit board) moves the bed up and down and the bed is supported only from the back. It is very boncy.

Specifically when I use z hop (0.1mm), there is clear ringing after unretractions.
I have to lower z acceleration to 50mm/s² and Jerk to 1 to avoid that. This works but it makes xy travel moves stutter in the first layers because the z axis is working to follow the bed levelling mesh.

I initially thought it was some sort of intermittent VFA, but this 1 layer concentric pattern I made shows clearly that the issue is actually on unretractions.

Needless to say, the artefact piles up on layers and results in holes in the walls of the print.

Concentric pattern.3mf.zip

Sliced with Orca slicer, these settings are important:

I should mention that even at the extremely low accelerations and jerks, this artefact is still visible with the right light, and it results in a VFA like defect

I should also mention that the same effect happens on each layer change regardless of zhop, it is just more time consuming to print tests

@dbuezas That image and your analysis is really interesting to see. @JonBr306 is working on Z axis input shaping. Do you fancy helping to test it?

Sure thing. I think this pattern may be useful to tune the parameters

I think this pattern may be useful to tune the parameters

I have been wondering about that. I was thinking of a variation of https://marlinfw.org/tools/input_shaping/freq-calibr.html.

@JonBr306 is working on Z axis input shaping. Do you fancy helping to test it?

I’ll have a CoreXZ machine built here soon that would probably be a good test for this as well.

I have been wondering about that. I was thinking of a variation of https://marlinfw.org/tools/input_shaping/freq-calibr.html.

Yes! that calibration is fantastic.

A bunch of straight lines (each starting with a z hop) should would do the trick for z IS

Yes! that calibration is fantastic.

Thank you. It was my idea.

[Edit: and kudos to KimmoHop for implementing it.]

Please test & report findings in #27073