[BUG] S-Curve acceleration causing huge vibration

[tturpin]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I have been trying to measure acceleration with an ADXL345 and see how it reflects Marlin's movement control logic on my delta printer. It didn't match at all, until I found that disabling S-Curve acceleration gave much more sensible results (it was enabled for some reason in the config that I started with). My printer is an experimental kinematics type (radial delta) for which the cartesian move/steppers move ratio is relatively stable and close to one (much more "linear" than a classic delta)

I plot the data from accelerometer (with some low-pass filtering at 100Hz) while executing back-and forth constant speed travel moves. What I observed in my experiments didn't look like the expected phases of constant acceleration and constant speed at all. Instead, I mostly observed jerk: very high oscillating acceleration spikes (possibly exceeding the 16G limit of the sensor). I did my best to avoid "intentional" jerk:

• disable "classic jerk" to use junction deviation instead (which is normally not supported for delta, but seems readily usable)
• increase microsteps from 16 to 32 (maybe a minor improvement)
• reduce minimum_planner_speed, which I suspect to be a little bit high.
  This didn't work, and I could still get arbitrarily high acceleration spikes although the max accel was set to 1G through M201/M204, just by increasing speed.

But disabling S-Curve had a dramatic effect on the plot. Below are the plots for the same gcode (attached bellow) with and without S-Curve, with identical scale:

The maximum acceleration drops from around 6G to 2G, and the acceleration phases start to appear (not clearly) beyond the oscillation. There is still a long way to go to observe smooth movement, but note that the printer is already working normally even with S-Curve enabled.

back-and-forth.gcode.zip

Bug Timeline

No response

Expected behavior

As the name implies and the description says, S-curve should yield smoother movement

Actual behavior

In my setup, it causes a lot of additional jerk/vibration instead.

Steps to Reproduce

I understand that many parameters affect movement and that my setup cannot be easily reproduced (partly because the printer is a unique prototype) but I think that the problem might be broad enough to be reproducible in different contexts (maybe even with a cartesian printer ?). I'm not aware of experimental (working) results of S-Curve acceleration, and I don't have the necessary knowledge about this to have an idea of what could be wrong.

Here are some parameters that I have in mind:

• kinematics
• board (Robin Nano V3)
• steppers drivers/configuration (using TMC2209 with 200 steps per turn 16 or 32 microsteps
• movement limits
• ft motion (I gave it a try but only had more vibration)
• input shaping, linear advance (not using it)
• bed leveling, maybe

Version of Marlin Firmware

dev-2.1.3-b3 + local changes (kinematics)

Printer model

Radial delta

Electronics

Robin Nano V3 TMC2209

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

ABL Linear grid

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

config.zip

[Nuck-TH]

To achieve same acceleration time as trapezoidal, s-curve overshoots set acceleration by 1.875 times.

[tturpin]

That seems a lot ! (but I'm not familiar with this technique, and I don't understand the rationale explained in the provided reference).
Still, I don't think it accounts for the 3x increase in measured acceleration spikes. And if it does, I wouldn't call it "smooth" !

[tturpin]

I just realized that there has already been a lot of investigation about S-curve: #12491 and #27013, also causing jerk at direction changes. The subject is large, I didn't read everything, my investigation is far from the level of detail achieved in those (with logic analyzer plots), and I don't know if this can be related, but I find it worth mentioning here.