[Proposal] Forbidden velocities for printer steppers

In 3D printer operation users often face a problem that certain velocities for the [kinematic] stepper motors should be avoided. Certain velocities on X or Y axis for cartesian printers (and similarly for diagonal moves on CoreXY and similar kinematics) may result in:

  • VFA, vertical fine artifacts
  • 2mm vertical defects (from GT2 belts and pulleys)
  • steppers and/or frame resonances, producing disturbing sounds

To avoid that, the users now tend to fiddle with the slicer velocity settings. However, that is not robust because one can fix the velocities of, say, the moves parallel to X and Y axes, but not moves at angles that could still hit the unwanted velocity on either of the steppers.

The best way to address this problem would be to implement such support in the firmware velocity planner, because it actually plans the velocities for each moves and can calculate per-stepper velocities and limit them, if necessary.

@koconnor, I wonder if you previously approached this problem and have some thoughts or ideas? I actually think it might be possible to implement this feature with fairly small amount of changes in the lookahead and velocity planner code (though I may have made a mistake in my estimations, it might be that something won’t work out as expected) to achieve the following guarantees:

  • With ‘forbidden’ velocity ranges configured for XY steppers for simple kinematics like Cartesian and CoreXY, no cruising will happen such that the stepper motion would fall into any forbidden velocity range.
  • Accelerations and decelerations can pass through forbidden velocity ranges though.
  • Velocity plan may be suboptimal (i.e. velocities will be just reduced where appropriate instead of trying to do an ‘optimal’ plan that would be some accelerations followed by decelerations).

Maybe you and others will have some feedback on this idea? And whether it might be accepted into the Klipper mainline, assuming it’s properly implemented. But as I mentioned, I didn’t go for the implementation yet, and just wanted to gather some feedback beforehand.

The potential ‘weird’ velocity planning that I can anticipate could be on some round perimeters (or other smooth curves) where parts of them will have to be velocity-limited, and different parts may have different velocity limitations. I’m not sure if that would prove to be problematic in practice though.

Alas, I only have a vague understanding of the issue. Do you have a link to a description of the issue, or how users are mitigating it?

I haven’t implemented or looked at anything like that. I’m aware that dc42 did some velocity manipulation in RRF a few years ago - as a kind of “poor mans” input shaper. Otherwise I’m not really familiar with it.

At first glance, altering the incoming g-code to avoid certain velocities seems kinda fragile.

-Kevin

It is hard to find very specific examples, but for example message1, message2 (from zapta), message3.

Or my tests with a gcode like

ACCELEROMETER_MEASURE CHIP=bed
G4 P500
G0 Y5 F300
G0 Y0
G0 Y10 F600
G0 Y0
G0 Y15 F900
G0 Y0
G0 Y20 F1200
G0 Y0
....
ACCELEROMETER_MEASURE CHIP=bed

(velocity goes up to 300 mm/sec in 5 mm/sec increments, with 1 second move in each direction as long as the bed size allows)

Results with spreadcycle, 256 microstepping:


Here the strong resonances are visible (and audible by ear) at velocities around 90-105 mm/sec. And also at 15 mm/sec which would likely result in VFAs.

Basically, in my case I would rather want to avoid that velocity range 90-105 mm/sec on Y axis with this stepper. One way is to print slower than that, but it may be too slow (especially for non-extrude moves), or try to print faster, but then moves at certain angles may still hit that ‘resonant’ speed range. And to make matters worse, the X axis may have different ‘resonant’ velocities, though in my case it isn’t too different: