Mihai

Now looking at changes with `S_CURVE_ACCELERATION`. #### Before I've marked the issues with red - it's mostly deceleration going abruptly to 0 instead of smoothly.  There's a bit of...

> Is it confirmed that the number of steps is not being modified in any way? I ask because in the past we have had issues where steps were off...

@thinkyhead I added a couple comments on a couple of commits you've added (Making a comment here since I'm not sure if they're easily visible)

Re step counts: I've checked before/after captures and did a diff of the steps to verify they are correct. For the simple gcode above, the capture shows X going from...

> I don't know whether instantaneous small speed changes will affect print quality or not but believe they might and I suspect they will at least be audible. @tombrazier I've...

Hi, I'm checking in on this PR. - There's the laser question that I've tried to address with #27031. - There's also the `accelerate_before` vs `accelerate_until` rename thread. I have...

> > There's the addition of NOMORE(initial_rate, block->nominal_rate); which is a pareto improvement - there's no case that goes from working to broken. > > There is a case: if...

> > I can't find what you're referring to in that link. Sorry, can you remake the comment? > > My comment was that `deceleration_time = 0;` on line 2320...

I agree it's getting complicated. That said, this change ensures that `minimum_planner_speed_sqr` is correctly passed through and followed such that the resulting `initial/final_rate` are not degenerate in edge cases, and...

> Another quickie optimization… For values that don't exceed +- 2^30 (i.e., long time periods? counting clock cycles?) it's safe to square before coercing to `float` (instead of coercing to...