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:
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.
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.
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?
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.
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.
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: https://www.trinamic.com/fileadmin/assets/Support/AppNotes/AN026-Adaptive_Microsteptable.pdf
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).
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.
