Proportional acceleration control

[Piezo]

@koconnor

If this setting is causing confusion to users, then I’d recommend trying to resolve with documentation updates. (Actually renaming the option would break many working setups.)

I haven’t mentioned specific changes like renaming max_accel for this very reason. I do agree that backward compatibility is important.

I’m (lightly) suggesting that max_accel could be kept as an immutable parameter acting as a hard limit on a new parameter/state accel. It would initially be set from a default_accel (or whatever) in the config, and then, altered by M204 during the print.^[1]

@koconnor

It’s not clear to me that max_accel_to_decel should scale with max_accel. It was intended to prevent resonances - for example, if set to an appropriate value, I don’t see why it should further decrease when decreasing max_accel.

If I were traveling at 20k mm/s² and extruding at 2k mm/s², I’d have to chose a max_accel_to_decel value that would either not affect extrusion moves at all (ie. 15k), or a value (ie. 1.5k) that would needlessly enforce that 92.5% of the traveled distances are cruised. I don’t see a way around this without scaling max_accel_to_decel with M204.

In my opinion this use case against resonances is mostly deprecated when using input shaping.
As a limit on “change of acceleration", it remains useful for saving a print that would otherwise be severely acceleration bounded, by enforcing a smoother motion profile on the extruder. Not only that, but it is sensitive to local feature lengths in the print and can act as a safeguard on details even on print with well tuned v²/a. For this usage, it is more intuitively defined as enforcing a faction of cruised distance, which implies that max_accel_to_decel = (1 - min_cruise_ratio) * max_accel.

However, it’s not perfect for that use case either, because it introduces short bursts of acceleration / deceleration between cruised sections^[2]. I mitigates this by converting some trapezes into linear velocity ramps if the relative time cost for the change is low enough. This further smooths the toolhead velocity in curves bounded by SCV.
This two heuristics work well together and it may be possible to derive an unified approach from them, since you’re looking for an improved system.

@koconnor

I think converting from “junction_deviation” to “square_corner_velocity” was a big user improvement.

Indeed it was a big improvement. And, to be clear, I’m not advocating for a comeback of junction_deviation.

What I’m trying to say is that it would be better if it were computed from the config’s max_accel instead of the acceleration set at runtime. A constant junction deviation is equivalent to setting scv = sqrt( max_accel / config.max_accel) * config.scv.

I need to gather more data to weight this, but I’m mostly convinced that this is needed to keep the same motion profiles when changing the acceleration. (along with scaling the gcode velocities by √accel)

@koconnor

I saw users try to calibrate acceleration and not realize that increasing max_accel also increased corner velocities - thus invalidating their calibration test (changing corning speed also alters extruder quality and resonance - so the test wasn’t limited to the effects of acceleration)

That would be an issue, yes. I’d argue that an informed user would understand that acceleration is a proxy for the forces applied to the tool-head, thus affecting cornering velocity under the centripetal model (but that might be asking too much). Also that the test itself might not be ideal if it requires out of the ordinary kinematics parameters. (Assuming that we are speaking of the PA tower test here, I think that @dmbutyugin is onto something with his new PA tuning method)

@koconnor

In my opinion, this would only add another knob. In my opinion, one of the most important thing 3d printing needs right now is less knobs.

I can’t agree more.
Now, to change the acceleration of a print while keeping overall shape of the motion profile, I need to do some calculations and turn at least three knobs.

Ok, maybe I’m the weird one needing this and frantically making v²/a and v0*√(a1/a0) calculations while tuning a print.

I’ve opened this topic to challenge these ideas and to see what workflow improvements could come from them. Nothing more.

---

1. Actually, I have refactored the accel state out of toolhead.py into the gcode.py, if that’s of interest for discussion. ↩︎

2. I think this was discussed in this issue: Junction velocity limits: sharp corners and smooth traversal of circles are mutually exclusive #4228 ↩︎