[FR] Input shaping and pressure advance from Snapmaker J1

[KimmoHop]

Is your feature request related to a problem? Please describe.

Marlin has original input shaping solution and Ulendo.io fixed-time motion in progress. Original input shaping supports currently only one shaper algorithm, not sure about FTM.

Are you looking for hardware support?

Nope.

Describe the feature you want

Snapmaker has published their Marlin-based firmware for J1 printer supporting Klipper-style input shaper supporting multiple shaper algorithms (?) and pressure advance.

Would it be feasible to merge Snapmaker input shaping to part of main Marlin FW?

What I don't want is too many input shapers complicating compilation and creating conditional hell into source code. Maybe special motion types could be separated in file level behind common interface or in separate branches (not a popular opinion I'd guess :) ) ...

Additional context

IDK if Snapmaker implementation would be any better for core-XY or delta printers, as J1 is bedslinger.

Links: https://snapmaker.com/blog/2023/05/12/snapmaker-j1-controller-firmware-open-source-release/ https://github.com/Snapmaker/SnapmakerController-IDEX

ps. I asked about this (and Prusa MK4 input shaping, also published, hint hint nudge nudge) in discussion, but it seems pretty dead.

[ellensp]

Prusa mk4 input shaping is not even out of alpha yet, and the code is not available yet (last I looked)

[narno2202]

@KimmoHop , if you want, have a look at my repo https://github.com/narno2202/Marlin. It's current Marlin bugfix with integration of FT_MOTION PR (#25719). Choose between integrated IS or FT_MOTION in Configuration_adv.h (mutually exclusive). In FT_MOTION there are ZV, ZVD, EI, 2HEI , 3HEI and MZV shapers. Works fine with XYZE printer (perhaps but non tested with 2 extruders), sensorless homing supported without reconfiguration.

[thisiskeithb]

Prusa mk4 input shaping is not even out of alpha yet, and the code is not available yet (last I looked)

They posted a version a couple weeks ago: https://github.com/prusa3d/Prusa-Firmware-Buddy/releases/tag/v5.0.0-alpha1

[KimmoHop]

What I'd also like to know, if FTM is "as good" as Klipper input shaping - in other words is it good enough to not be interested in other solutions? I'm also not fan of Klipper, though Klipper Screen (still extra $$ better spent on e.g. kinematics) makes printer usage (you know, manual stuff on screen) almost as easy as Marlin :D

[KimmoHop]

@KimmoHop , if you want, have a look at my repo https://github.com/narno2202/Marlin. It's current Marlin bugfix with integration of FT_MOTION PR (#25719). Choose between integrated IS or FT_MOTION in Configuration_adv.h (mutually exclusive). In FT_MOTION there are ZV, ZVD, EI, 2HEI , 3HEI and MZV shapers. Works fine with XYZE printer (perhaps but non tested with 2 extruders), sensorless homing supported without reconfiguration.

Thanks, I'll take a look, though my problem is not-so-supported printer (Voxelab Aquila N32). Currently I'm using classicrocker883/MriscocProUI (fairly well updated from Marlin) so I'd have to merge one way or another to get a good build :/ Might not be too hard :)

Edit: branches are so close that merge seems trivial :D

[narno2202]

When i rapidly look at klipper, prusa, snapmaker or marlin (Ulendo' ft_motion) code, mathematical computations are the same. The difference is in the motion control loop wich can generate trouble as in marlin because of his "universality" (interaction between 2 motions systems). This is not the case in proprieratary implementation

[KimmoHop]

I did the merge (not many files, comparing to stock Marlin helps a lot) of the changes. N32 has enough flash, if bilinear mesh is used instead of UBL. Frankly, using Jyers and Creality board would make life simpler ;)

I have 2 little questions (code or M493 does not have much documentation) before updating firmware:

1. FTM works with standalone 2208 drivers, yes?
2. Which linear advance feature should be used? If FTM, does "normal" linear advance need to be disabled?
3. What is the difference between S1: Fixed-Time Motion and S10: ZV Input Shaping? Both use FTM but first doesn't compensate vibration? Oh. I have 3 little questions... (repeats first 3 and :D)
4. Should vibration test be done with S0 or S1 (my guess)?

[narno2202]

@KimmoHop. With this PR #25719, we have 2 motion modes in Marlin : standard with optional integrated ZV shaping and ft_motion with optional shaping modes (ZV, ZVD, EI ...).

1. Yes, with any driver
2. Standard linear advance and integrated ZV shaping are bypassed whenFT_MOTION is enabled (mode 1 or higher ). If you don't switch between standard motion mode and ft_motion mode for printing, standard linear advance and integrated ZV shaping could be disabled (saves ROM size)
3. ftMotionMode 1 : ft_motion enabled but no shaping applied, only the motion mode is activated. The other modes use different shaping algorithms.
4. Calibration test print must be done with one of the available shaping mode activated (higher than S1)
5. In my last repo update, M493 S0 is forbidden during a job (so, avoid layer shifting).

[KimmoHop]

Thanks again @narno2202 for answers.

Currently I have the following problems (flash size: turned off arcs, FW retract and some smaller features to keep UBL):

• my environment uses ProUI, I might try "stock" Marlin + Jyers + build stuff for N32
• when FTM is enabled, homing works, but none of the other probings (tramming, levelling) using 3D touch
• if FTM is disabled, probing works, but alas no FTM
  • workaround: turn off during tramming & levelling in terminal
  • UI should be doable for Jyers and ProUI
• some of these could be related to how ProUI does tramming and mesh creation (FTM should be turned off for them)
  • should be fixable

--> I'll stick with IS ZV + UBL for now. I will likely try stock + Jyers some time (tomorrow, next week, autumn), but since

• Marlin has 2 good shapers
• not much discussion is going on here
• Snapmaker implementation merging is not imminent (or even needed),

I think we can close this issue for now, unless someone has other reasons?

[KimmoHop]

Closing this, as

• ZV IS might become easier and faster to calibrate (PR on Marlin Docs)
• FTM is progressing, though not quite yet ready for mainstream
• Printing with less acceleration reduces ringing :D
• Out-of-the-box cheap Klipper printers are more available than ever

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.