Independent input shapers per axis

wesc

Some before and after pix (ignore the schmoo near the bottom. i have a fan connection that is wonky). 2K to 14K accel at top. 200mm/s

CCS86

This definitely seems worth the effort. I can't wait for input shaping to release in RRF!

wesc

I should try the same shaper and freq for both axis to see how that impacts print results. Away from printer until monday...

CNCModeller

@wesc I'd imagine that for "bed slinger" this is even more significant, and definitely will be for my polar printer. It's a perspective I hadn't properly thought through so far.

dc42

@wesc, we're leaving the option open to support different input shapers per axis. However, this brings with it two potential problems. The first is that RAM usage would be increased; so we may not be able to support it on the Duet 2 series. The second is that if you use per-axis input shapers, then the print head will not longer follow exactly the path specified in the GCode. This generally doesn't matter for travel moves, but does for printing moves. This may be what the Klipper documentation refers to as "smoothing" when more complex input shapers are used.

wesc

@dc42 if ram is a constraint, then that's an acceptable reason for duet2. But, i'd prefer if some other features were limited (like the LPC port does) to free up ram to support it.

If there isn't 2 axis input shaping in rrf3, I will await the klipper port to duet3. Duet3 mini port has been completed.

Input shaping is THE killer feature. And 2 axis is essential for it to work well.

dc42

@wesc said in Independent input shapers per axis:

And 2 axis is essential for it to work well.

On bed slingers, maybe.

CNCModeller

@dc42 said in Independent input shapers per axis:

@wesc, we're leaving the option open to support different input shapers per axis. However, this brings with it two potential problems. The first is that RAM usage would be increased; so we may not be able to support it on the Duet 2 series. The second is that if you use per-axis input shapers, then the print head will not longer follow exactly the path specified in the GCode. This generally doesn't matter for travel moves, but does for printing moves. This may be what the Klipper documentation refers to as "smoothing" when more complex input shapers are used.

Would it be possible to filter both frequencies on both axes to keep them synchronised for printing moves?

elmoret

Just chiming in to say that input shaping is the single most requested feature/reason people use Klipper over RRF/Duet3D products in my experience.

dc42

@cncmodeller said in Independent input shapers per axis:

Would it be possible to filter both frequencies on both axes to keep them synchronised for printing moves?

It may be theoretically possible, but I haven't found any papers about how to do it. However, I have now added support for custom input shapers to the code,;so anyone who can calculate the required impulse amplitudes and timings will be able to set them, subject to the maximum number of impulses supported.

I haven't found any information on the MZV input shaping supported by Klipper either.

CNCModeller

@dc42 said in Independent input shapers per axis:

@cncmodeller said in Independent input shapers per axis:

Would it be possible to filter both frequencies on both axes to keep them synchronised for printing moves?

It may be theoretically possible, but I haven't found any papers about how to do it.

In my uneducated mind, could you not apply the shaping to the demand twice in series, take the output from the first shaping and feed it into the second?

I'm sure I'm talking 8ollocks... but I had to ask.

Plus I guess the processing overhead would be significant even if it were possible.

Feel free to tell me it doesn't work like that and that I'm a total numpty...

dc42

@cncmodeller said in Independent input shapers per axis:

In my uneducated mind, could you not apply the shaping to the demand twice in series, take the output from the first shaping and feed it into the second?

No, unless the higher frequency was at least 2 to 3 times the lower frequency, so that each individual step taken by the shaper for the lower frequency could itself be shaped to cancel the higher frequency.

However, if a sequence of amplitudes and times that cancel the two frequencies and damping factors concerned can be calculated offline just once, then they can be fed into the RRF input shaper and the run-time cost of implementing it should not be excessive.

CNCModeller

@dc42 thanks for the education... please don't take this as meddling, I just would really like to understand the practicalities of the technology. I'm not sure I'd be able to get my head around the research like yourself.

I'm thinking that frequency difference might be valid in special cases such as for bed slingers with a very heavy bed.

When I get round to measure my polar radius arm and bed frequencies I'll let you know what I find.

Really interesting, great work BTW. Much respect.

CCS86

@dc42 said in Independent input shapers per axis:

The second is that if you use per-axis input shapers, then the print head will not longer follow exactly the path specified in the GCode. This generally doesn't matter for travel moves, but does for printing moves. This may be what the Klipper documentation refers to as "smoothing" when more complex input shapers are used.

You could argue, that because of the resonance / ringing, the unaltered input isn't allowing the nozzle to exactly follow the path, and that the shaped input's intentional path "deviations" actually allow more precise tracking of the nozzle to the path, no?

dc42

@ccs86 said in Independent input shapers per axis:

You could argue, that because of the resonance / ringing, the unaltered input isn't allowing the nozzle to exactly follow the path, and that the shaped input's intentional path "deviations" actually allow more precise tracking of the nozzle to the path, no?

Maybe.

Diamondback

@dc42 This one maybe?

https://www.researchgate.net/publication/224606974_Input_shaping_for_nonlinear_systems

GeneRisi

@dc42 Would the "offline" calculation solution work on both axes on Duet2 boards, or are the RAM limitations still an issue?

dc42

@generisi said in Independent input shapers per axis:

@dc42 Would the "offline" calculation solution work on both axes on Duet2 boards, or are the RAM limitations still an issue?

If we can use a single shaper to handle two frequencies, that is likely to be usable on Duet 2.