Square corner velocity and smoothness of movement

[Muz94]

Basic Information:

Printer Model: custom I3 - IDEX wwith nema23 motors on X1, X2, Z1, Z2 and Y
MCU / Printerboard: BTT Octopus Pro + 2x EB42
Host / SBC: Desktop PC

Hi, I’m facing some weird behaviour on my custom i3 style printer that I want to share.
The machine is equipped with ballscrews on the Z and Y axes, belts on the X axes (it’s an IDEX machine), and everything is actuated by nema23 motors.
I already faced a few issues when trying to obtain smooth movement with such big motors with the drivers I choose (tmc5160t pro plus), see this discussion, but they were limited to the X and Z axes as I was using a brushless servo on the Y axis.
For various reasons I now put a stepper motor on the Y axis as well, and due to the speed and acceleration, weigt of the plate, inertia of the motor, “directness” of the screw drive etc I’m having issues with that as well. The movement seems very HARSH, noisy both when changing direction and (especially) when printing curved profiles at speed.
I tried pretty much everything: I switched to TMC2209 drivers (small improvement), reduced the current, increased microstepping, played with different acceleration values, different drivers voltage, belt tension etc, but the only thing that unexpectedly worked was increasing the Square corner velocity from 5 to 10-15.
In this video you can see the difference that going up to 8 made.
Why should this be the case? Is the controller trying to slow down / speed up ad every different G-CODE line? Is there any other way to smooth the movement of the machine? In general I always found the movement of the motors to be more harsh and noisy if compared to when the machine was running on linuxcnc.
The next move will be to swap the motor for a smaller 56mm NEMA23 that I know for a fact works better with TMC drivers (I’m honestly a bit disappointed with the improvement I got going from TB6600 to the 5160t pro plus), but any other way to make the machine a lillte less jerky (without compromising quality) would be welcome.

I’ll upload the log tomorrow if needed, I don’t have the machine at home.

[nefelim4ag]

Well, first of all.

### Basic Information:
...
[x] klippy.log

There are a lot of different things that could happen. From the scarce information that I see, it seems like you do use StealthChop on the ballscrew axis.

Stealth has limited speed range before EM resonance happens:

TMC StealthChop Rotor Positional Lag and Compensation

The problem definition According to the Klipper docs, Stealth has a positional lag. If you have an encoder, you can validate that data on your machine. [Spread vs Stealth] CoreXY 1 motor test Gcode Spread has low lag, less than 1/4 of fullstep distance, which increases with higher speeds (>200mm/s in my case), stealth has a steeper lag increase over a full speed range, and clamps it around 1 full step. Why bother? Well, the open-loop control 3D printer is built around time precision, with …

It would happen around ~5 RPS in general.

@Muz94

was increasing the Square corner velocity from 5 to 10-15.
In this video you can see the difference that going up to 8 made.

Unfortunately, I do not hear the difference. Anyway, basically, SQV is just a speed limiting factor to travel angles, that is, it. The wider the angle, the faster it would travel.

Kinematics - Klipper documentation

If you utilize an input shaper, increase of SQV would increase the rounding on the corners and basically would make angle movements more “smooth” (round).

Analyzing your footages from the Reddit:

-Z, SC ON: https://imgur.com/XgzLbzf

This sounds like a high RPS stealth resonance.

-Z, SC OFF: Imgur: The magic of the Internet

This sounds like normal spread.

• X right, SC on: Imgur: The magic of the Internet

It is silent, and there are mechanical noises.

• X left, SC on: Imgur: The magic of the Internet

It is slightly hitting the resonance speed zone.

Hope that helps.

[Sineos]

Just some general remarks, without commenting or judging your design:

• Ball screws are velocity and acceleration limited. The smaller the diameter, the more limited. Solid manufacturers give this data in their data-sheets.
• Nearing their critical values will make them bind.
• Affordable ball screws are known in the community for their abysmal quality. High-quality ball screws cost a multiple of what most folks spend for their entire printer.
• All designs I know have abandoned the idea of ball screws, even for the z-axis.

[Muz94]

I’m not using SC anymore (only on the X axis, but that’s not the core of the issue here).
I linked the previous discussion just as a background.

[Muz94]

@Sineos

• Ball screws are velocity and acceleration limited. The smaller the diameter, the more limited. Solid manufacturers give this data in their data-sheets.
• Nearing their critical values will make them bind.
• Affordable ball screws are known in the community for their abysmal quality. High-quality ball screws cost a multiple of what most folks spend for their entire printer.

I understand that. However I dont’ see much choice on such a heavy build plate. I choose to build a bed slinger and this is the price to be paid.
I bought the ballscrews directly from Hiwin, but they are rolled screws (not ground) so they are not top notch quality.
I still don’t think I’m that close to have them bend, it just sounds like the motor is slamming hard on it even when it should not: I modeled that part with fillets, there is no reason to have the perimeters print with that kind of jerky motion, something between the meshing, the slicing and the controller reducing everything to linear movements is creating unnecessary stutter on a smooth profile
I was honestly convinced that it was a driver issue (based on my previous problems), but seeing that SQV pretty much fixes the issue makes me think otherwise.
Consider that when I was using a BLDC servo I still had to reduce the proportional gain to “relax” the motor and avoid creating that same noise.

I know that linuxcnc or other industrial controllers make som kind of arc-fitting to smooth the movement of the machine, is there something that can be enabled on klipper to do the same thing?
The weird thing is that it doesn’t struggle with zig-zag motion, but small curved sections sound like cr*p.

[nefelim4ag]

@Muz94

is there something that can be enabled on klipper to do the same thing?

As mentioned above, the input shaper does smooth the entrance and exit of the trapezoidal movement.

TMC Adaptive Microstep Table

I said above that hypothetically tuned motor registers would look at the micro-step level similar to StealthChop. Looks like - yes. I was not successful again with the oscilloscope and tuning, cause I can’t reliably see current without a good current probe, but I used it to validate tmc table data and end the expected chopper frequency. So, I used ~30kHz as the target, all data below are with offset90 and TMC2240. Interpolation enabled. There is the remark that I drive my motor with ~75% RMS…

[Muz94]

It seems to me like the issue is deeper: why should square corner velocity come into play when printing round profiles?
In understand that everything is a straigh line in printing toolpaths, but still it’s kind of weird.
I thought about enabling G2-G3 in the slicer, but it is stated in the documentation that those moves are converted back into lines with some approximation, so that wouldn’t probably do much.

[nefelim4ag]

@Muz94

It seems to me like the issue is deeper: why should square corner velocity come into play when printing round profiles?

Well,
I suggest you read your G-code. It consists completely of straight lines.
I’m not aware of slicers that are able to produce arcs.
In Prusa/Cura slicers (and all derivatives), arcs are produced by the post processor (Arc Welder), which does approximations of the G-code path and produces the arc commands.
(Also, I would suggest checking your STLs and looking for any non-straight lines).

Basically, we have always worked with straight lines historically, and there are no problems with that. Steppers do have steps, and also do the straight line moves. Quantization depends on the microstepping available.

It is not a problem by itself.
Moreover, you are free to increase the resolution down to the stepper resolution (count of lines), which would better approximate the curves.

@Muz94

I thought about enabling G2-G3 in the slicer, but it is stated in the documentation that those moves are converted back into lines with some approximation, so that wouldn’t probably do much.

Mostly yes, it is intended to round bad models and to decrease the throughput required to run the G-code commands over UART (Marlin).

ARC commands would be split back into straight lines. It does not matter a lot on a normal scale.

Circular arc approximation using polygons

By default, gcode_arcs uses resolution = 1mm.
With some adequate radius circles, we can calculate the maximum error.
For me, for 3d printing, dimensional error < 0.1mm seems acceptable.
I personally think that 0.1mm resolution is better from the approximation endpoint.
But it does put additional load on the host.

Minimal radius 5mm.

If you do, decrease the chord length to 0.1 mm, you can generate even smaller circles, with a minimal radius of 0.5mm:

Python code

#!/usr/bin/python3

import numpy as np
import matplotlib.pyplot as plt

# Constants
min_diameter = 5  # mm
max_diameter = 100  # mm

chord_lengths = np.linspace(0.1, 1, 100)
radius = np.linspace(min_diameter / 2, max_diameter / 2, 5) # mm

# Sagitta function: s ≈ R - sqrt(R^2 - (L/2)^2)
def sagitta(R, L):
    return R - np.sqrt(R**2 - (L / 2)**2)

# Compute sagitta for each radius
errors = {R: sagitta(R, chord_lengths) for R in radius}

plt.figure(figsize=(10, 6))
for R in radius:
    plt.plot(chord_lengths, errors[R], label=f"R = {R} mm")

plt.title("Approximation Error (Sagitta) vs Chord Length")
plt.xlabel("Chord Length (mm)")
plt.ylabel("Error (mm)")
plt.grid(True)
plt.legend()
plt.tight_layout()
plt.show()

---

Maybe it would make sense to limit the path error instead of directly specifying the chord length in the config. But this is not directly related to the topic.

[Muz94]

Here it is
klippy.log (22.2 KB)

[nefelim4ag]

Git version: 'v0.12.0-131-gd9043345'

You may want to update your Klipper; there were some corner handling changes that could affect your issue.

toolhead: Fixed junction deviation calculation for straight segments

[Muz94]

Intresting.
Is that fix just related to the use of gcode_arcs or does it affect the movement of the machine in other cases?
edit: i found the explanation, but it doesn’t look like something that can actually happen in normal printing conditions
link