[BUG] High acceleration peaks at high velocity (S-Curve and trapeziodal)

[Legion23705]

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

Yes, and the problem still exists.

Bug Description

Hello, dear Marlin community

I´ve discovered a strange behavior when I was trying to improve the control parameters of one of my servo motors which drives the X-Axis of my large printer (Leadshine iSV2-RS6020V24H). Currently, I have set some milliseconds of smoothing time for the motor to make the axis move softer. Back in the day when I was initally setting up the motor, I was happy to make it run at all and didn´t spend too much time to finetune it to the very absolute limits. This is what I´m trying to do now. The reason is: I noticed that this signal smoothing leads to slightly rounded edges on printed parts. I can´t get the edges as sharp as with other printers, even with pressure advanced enabled.

This is why I´m trying to enhance the control parameters, starting with lowering the smoothing time to almost zero. So much for the background.

After i´ve changed the settings, I noticed that at the end of longer, faster movements the motor stops quite hard, like if the jerk would have been set way too high. So I did a test to investigate: I wrote a small Gcode to move the axis with maximum velocity (400 mm/s) G1 X0 F24000 G1 X200 G1 X0

The motion settings are the following: DEFAULT_MAX_ACCELERATION XY: 4000 (Set via EEPROM command, the config says 8000) DEFAULT_ACCELERATION XY: 10000 (Set via EERPROM command, the config says 1500) DEFAULT_TRAVEL_ACCELERATION: 1000 (This setting ultimately sets the acceleration for the test Gcode and is only relevant) DEFAULT_XJERK: 10.0 MINIMUM_STEPPER_POST_DIR_DELAY 30000 MINIMUM_STEPPER_PRE_DIR_DELAY 30000 MINIMUM_STEPPER_PULSE_NS 3000 256 Steps/mm Servo: 3200 Steps/rotation

The servo motor has a tuning software which can generate graphs for chosen parameters, this is how the move looks like:

The blue line shows the command velocity, the hand drawn red line shows the expected ideal velocity. As you can see at the end of the move, the velocity suddenly drops to zero. I´ve imported the plot into Excel and calculated the speed and acceleration according to the command position setting, which is stored in the orange channel of the graph above:

There are clearly visible acceleration spikes (value = right scale) at the end of each move. (The calculated velocity is smoother than the reported position command velocity, I think that the tuning software doesn´t calculate this channel very accurate and does some simpification or rounding. )

I tested the same G-Code, but halved the Steps/mm in Marlin and the resolution of the servo:

You can see that the velocity drops at the end are a little bit smaller than before, the acceleration for the first peak is also much lower (the difference is noticable in reality as well), so the step resolution seems to have in impact on this problem.

It becomes even more visible when I switch to S-curve-acceleration:

You would expect that the velocity slowly fades out at the end of the move like an ideal S-curve (like I´ve drawn in red), but the velocity is just cuts down to 0 at ~300 1/min, which hits the axis quite hard.

This is the same move at 50% speed:

At this speed (200 mm/s), the acceleration spike is much lower, but still a little noticable

There seems to be something wrong with the step generation at high speeds.

I have the same motor installed on a different printer which runs with Repetier-firmware, I can´t see such an acceleration spike there. This graph is not exactly as above (the speed is a bit lower and the distance short), but I tested it with higher speeds on Repetier and didn´t see the same acceleration spike as with Marlin.

The Manta M8P V2.0 has a 550MHz high speed MCU, so I don´t think that I hit the maximum step rate. At 400 mm/s, I´m only at 102,4 kHz and the problem is still there with halve the step rate (=51,2kHz) Has someone seen a comparable behavior or are there ideas how to get the acceleration ramps straight?

Bug Timeline

No response

Expected behavior

ideal trapeziodal or S-Curve move

Actual behavior

acceleration peaks

Steps to Reproduce

No response

Version of Marlin Firmware

2.1.x Bugfix from 07.08.2024

Printer model

custom built

Electronics

BIGTREETECH Manta M8P v2 with Raspberry Pi 4

LCD/Controller

None

Other add-ons

closed loop servo motors and external steper drivers

Bed Leveling

None

Your Slicer

None

Host Software

Other (explain below)

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configuration.zip acceleration calculation.xlsx

[DerAndere1]

Have you tried decreasing Jerk values? Does the situation improve when you disable classic jerk (//#define CLASSIC_JERK) and modify junction deviation values?

[dbuezas]

Very interesting plots! I recently bought a logic analyser to do exactly this, but haven't tried it yet.

The behaviour you found looks exactly like what I would expect from marlin working exactly as intended.

There are clearly visible acceleration spikes (value = right scale) at the end of each move.

That's most likely jerk. The acceleration profiles don't exactly match the exit speed of one block to the entry speed of the next one. Instead the planner allows them to differ by at most the configured jerk. This is by design, if we take a 90° corder as an example, a non zero jerk means the machine doesn't have to gradually slow down to zero speed on one axis before starting to move the other one. If you use junction deviation instead, the jerk will vary depending on the angle of the corner and the max acceleration configured, but these hard stops/hard starts on an axis happen the same way.

To confirm this you could try setting jerk to a very low value and measure again. You'll also see why jerk exists since this makes the printer take curves really slow and also make the extruder work a lot more (because it also has to slow down to a full stop on 90° corners)

I tested the same G-Code, but halved the Steps/mm in Marlin and the resolution of the servo [...] the velocity drops at the end are a little bit smaller than before, the acceleration for the first peak is also much lower .

Are you sure you also updated AXIS_STEPS_PER_UNIT? if you have twice the microstepping, then marlin has to make twice the steps to travel the same distance.

At this speed (200 mm/s), the acceleration spike is much lower, but still a little noticable

This I can't explain

The reason is: I noticed that this signal smoothing leads to slightly rounded edges on printed parts

I would expect this to happen if the stepper is smoothing its input. I believe this to be a bad idea since marlin is in charge of keeping tight control of each step.

Actually, the extruder may be an exception when you use linear advance, since this may allow you to set a higher e-jerk, which will reduce linear advance induced slow down.

[Legion23705]

The jerk is set to a value of 10. I am aware how the jerk is supposed to work. When I look at the graph with 400mm/s peak speed, I can see that the acceleration ramp ends at ~300 1/min. The axis moves with ~62,5mm/s at this point, so it looks like the jerk is set to 60, which is not the case. It looks like the jerk is scaled up with higher velocity. This is definitely not how it should be. However, I am also not 100% sure if it´s not the motor itself that somehow messes up the input signal, but I can´t verify this yet. In my opinion this is unlikely since it seems to work very accurate otherwise. Does anybody know if there is a cheap logic analyser which can measure the STEP- and DIR-signals and do further analysis to calculate the velocity an acceleration? Maybe it has even something to do with multistepping. I´ve already discovered that the motor moves quite rough at high velocity when I increase the step rate even further. Mulitstepping limit is set to 16 (default value, i didn´t change it)

I will test some different settings:

• Jerk = 0
• Junction deviation enabled
• modified test move (instead of 400 mm/s -> 0mm/s, a stepped ramp like 400-200-0 mm/s or 400-10-0mm/s
• lower multistepping limit

[dbuezas]

I got this one: 5,89€ | NanoDLA Logic Analyzer SCM ARM FPGA Debugging Protocol Analysis 24MHz SampleRate 8 Channels Sigrok PulseView For arduino Module https://a.aliexpress.com/_EzbvutJ

I tried it with a 50khz signal and it seems to work fine. Haven't tested it on the steppers yet

[Legion23705]

I testet some different jerk settings with trapezoidal acceleration:

Jerk=0

Jerk=50

The jerk setting only seems to change the beginning of the acceleration ramp, while the deceleration ramp doesn´t change. Even if I set the jerk to zero, the acceleration peak at the end is still there. So the problem doesn´t seem to be jerk related.

I did some further tests with modified motion profiles.

G1 X50 F24000
G1 X250
G1 X258 F4800
G1 X58 F24000
G1 X50 F4800

Here I added a slow move (8mm at 80 mm/s) after the long fast move (200mm at 400mm/s):

It is interesting to see that the acceleration bump is completely gone when I stop the deceleration exactly at the point were the speed is cut to zero in the tests I did before.

When I add an even shorter slow move (1mm at 80 mm/s), it almost looks like a perfect trapezoidal ramp:

When I reduce the slow move to 0,1mm lenght, than the acceleration bump reappears:

I did another test were I increased the speed of the second move segment to 160 mm/s, 32mm lenght. The acceleration peak is still removed:

Another thing I just checked is the duration and shape of the acceleration and deceleration ramps. I overlayed the actual velocity with the velocity of an ideal trapezoidal motion. While the acceleration ramp looks perfect, the deceleration ramp seems to have a bump at the lower 2/3 of the motion, while the first 1/3 of the motion looks fine. It looks like the motion planner moves the deceleration ramp too fast, then finds out that the end of the commanded move distance has been reached before the actual planned time for the move is over and then stops the axis hard immediately to prevent the axis from overshooting.

This is really strange and I have no clue how to fix this. Since I seem to be the only one affected by this problem (I at least didn´t read from it anywere before), It may has something to do with my stepper timing: I am using external drivers (servo motors), so the step and direction delay times are quite long compared to other, integrated drivers, especially newer ones from Trinamic. A TMC2xxx-Driver needs a stepper driver pulse of 100 ns while my drivers need a pulse of 3000ns. Same for the post / pre dir delay: TMC needs 20 ns, mine need 6000ns (i set them to 60000ns which I needed to do to solve another problem with a shifting Z-axis, which I´ve discribed in another thread).

[Legion23705]

I quickly installed Klipper and tested the same gcode.

As you see, the trapezoidal shape looks perfect here. There is also no noticable acceleration peak on the axis. This proves that it is definitely an error related to the Marlin firmware and has nothing to do with the servos or anything else hardware related.

The acceleration is set to 2000 instead of 1000. I tested Marlin before with ACC=2000 before without a change in behavior.

Well, Klipper has some different, strange problems: For example Klipper seems to reduce the maximum speed below 400 mm/s when I set the acceleration to 1000. Furthermore, I can´t set individual values for MINIMUM_STEPPER_PRE_DIR_DELAY and MINIMUM_STEPPER_PULSE_NS, I can´t always check endstops and when I run the Z-axis-test-Gcode which I used to diagnose this problem #27347 , ALL axis were shifting with every move, so there is quite much wrong here also which prevents me from using Klipper.

[DerAndere1]

Does the situation improve with this gcode?

G1 X0 F24000
G1 X200
G1 X0
M400

[Legion23705]

I tried this gcode, it doesn´t change the behavior. The motion planner is empty anyway at the end of the last move, so I don´t think M400 has any impact here.