[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.

1 Like

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.


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

Or my tests with a gcode like

G4 P500
G0 Y5 F300
G0 Y0
G0 Y10 F600
G0 Y0
G0 Y15 F900
G0 Y0
G0 Y20 F1200
G0 Y0

(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:

Is there still any attentionon this topic here?
I’m fighting against VFAs/marks as well and have a range from about 70 to 110 mm/s where you can see the following ripples/marks:

Same with TMC2209 and now with TMC5160.
I read in other forums that some users want to exclude the bad speed ranges to get rid of the ripples but it does not seem to be that easy.
Others seemed to have edited the MSLUT in the stepper drivers to avoid sine wave artefacts causing the VFAs.
And I’m currently struggling in getting the fast decay settings for the Constant off time mode set up:

This solved the issue for a friend but he is using RRF where this is possible easily.

Either with the measurements from @dmbutyugin or with such a vase mode tower you can determine the speed range quite easy but then we need the option to exclude those speeds from being used.
But in my opinion this would be the easiest way to get rid of those marks.

The marks look like GT2 belt not VFA,s I would check that you don’t have the belt teeth running over a smooth face pulley. It is a mechanical issue not a driver issue for what I am seeing.

I don’t want to hijack this thread for troubleshooting my issue but the belts are running on their smooth side except for the motor pulley.

1,8 degree Motors? You can hide them a bit with 0,9 Stepper Motors

It was present with 1,8° stepper motors and now even with different 0,9° motors after my big upgrade session.
On my KP3S it was resolved with installing 0,9° motors.

it depends also on the resonance. Unfortenately I also cant hide them completely on my Princore ONE with 0,9. But it is much better as with 1,8. After 0,9 I Made it as Good as possible with perfect input shaper calibration and in my Case damping ratio with 0,125 and 3hump on y and 2hump on x

I think the fva are coming from the vibrating toolhead / rail/linear rail in Z direction when moving. This is minimal but can be seen in adxl345 resonance measuring

Btw: Any sucess with chm 1 and fast decay time? How Do you Set the chm to 1 with klipper?

These were my fva before perfect input shaper calibration but with 0,9 steppers

And here with perfect input shaper:

Still visible but much better

Often lighting is everything.
I can’t explain the effect of input shaping on VFA. Especially on straight lines when it is occurring everywhere.

CHM can be easily set in the TMC5160 section via driver_chm: 1
But I don’t know about the fast decay time…
In CHM=1 mode the stepper motors are really loud and varying htstr affects this so it seems to alter the fast decay time but I don’t know about the MSB and TFD.
We only seem to have TPFD parameter.

Let us continue this in my thread even though this thread is about avoiding VFA too.

A couple of cents on the topic:

  • One may observe both VFA and 2mm defects from belts. If 2mm defects appear only at certain speeds, then it is usually related to resonances of the frame (basically, belt or pulley create some tiny irregularities in the motion that are then amplified by several times due to resonances). In such cases, it might be desirable to avoid these ranges of velocity.
  • Different motors can affect VFA (especially, switching to 0.9 degrees motors) and the 2mm defects to a [much] lesser degree. A plausible theory on this that I heard is that a motor with different parameters (e.g. different inductance) may resist more to these small oscillations, thus reducing the magnitude of the 2mm defect after the resonance. So, if one has different stepper motors at hand, they may wish to try to swap and test them, but purchasing a bunch probably is not worth it as there is no strong evidence that the 2mm defect will be significantly reduced (and it is unclear which ones to buy in first place).
  • Tuning TMC driver settings (e.g. modifying MSLUT or optimizing chopper parameters) may affect VFA (especially MSLUT) but is not very likely to affect 2mm defects. TBH, optimizing chopper parameters is not likely to affect things much (unless it is really detuned and you hear loud sounds when motor is moving). Alas, there is no easy way to tune the sine wave table (the process suggested by TMC is quite fiddly).
  • Input shaper does not affect constant speed motion and therefore will have no effect on VFA or 2mm defects.

@LifeOfBrian to your question, there is some interest from my side, but I didn’t go forward with the implementation [yet]. I wanted to gather some thoughts and feedback first, as implementing something that’s doomed from the start to be thrown away is actually pretty sad, and I could spend my time elsewhere instead.

Do you maybe have experience in optimizing the MSLUT or anybody else here?

As far as I understood this requires a current probe to get a clean sine wave on the oscilloscope but I have none yet…

No, that’s not it. In spreadcycle mode you should be getting a perfect sine wave because TMC driver actually measures the current and makes sure it follows the sine wave from the table (which is as close to sine as it can get). You may need to optimize some params a bit so that the current better crosses 0, but that’s only it. You may need to adjust the sine wave table to account for imperfections of the stepper motor (and thus the wave form will deviate from the sine). TMC had some suggested procedure:
But I’ve never followed it and thus cannot say whether you can achieve some good results or not.

Anyone managed to try it(tmc microstep table)? I’m on the verge of trying it myself. But that would require a new board and drivers. Would be glad to have some extra information on it.

Yeah, a while ago I tried that. My experience was so-so: on the stepper motors I have tested this with, having an ability to program 1/4 of a sine wave (1 full step) was not sufficient. Meaning that deviations from the perfect sine wave were not 1/4-sine-wave-symmetrical, and one would have to define 1/2 or even the full sine wave correction (2 or 4 full steps) to achieve satisfactory results. I suspect this was due to some imbalances between stepper magnetic poles. What’s worse, the required corrections seem to be velocity- and direction-dependent. So, I didn’t manage to achieve good results with TMC sine wave table. FWIW, I was using accelerometer data to ‘tune’ the sine wave table, and not the procedure suggested by TMC (with mirror, laser, and distant wall, which would be difficult for me to implement).

Thanks for sharing your experience, Dmitry.

Every time I think about this problem I tend to like the idea of a step + pulse timing correction in mcu instead of TMC way. But that correction algorithm is still difficult to fully understand for me.