S-Curve/ sinusoidal , Jerk +acceleration

[stewwy]

Just my 2 pence worth, reading this thread it is going to be of great benefit to some but make no difference to others.

From a practical perceptive it would be most useful to have S-curve available under an M-code, it could then be used per print.

I've used it on my Cartesian before I got my Duet (using Marlin2 and an MKS-Sbase) it does allow me to print faster at the same quality, Plus my desk didn't vibrate as much

However it did have those awful stepper drivers, so theres that.

[T3P3Tony]

@stewwy the option to select which acceleration type is used is part of the plan.

[Hardware_SortingRobotics]

When S-curve acceleration is applied will the curve look more like this picture instead of a trapezoid? I got the picture off of the prusa calculator website.

[dc42]

That picture doesn't illustrate S-curve acceleration.

[stewwy]

Is this what is trying to be achieved?

If so, do we also need to think about the timing ? As it effectively moves the area under graph in a positive way which is going to lead to an overrun. or am I over-thinking this?

Apologies if this has already been discussed, I didn't notice it on a quick re-read of the thread.

[dc42]

The problem with changing the profile like that is that it makes the total acceleration and deceleration times longer, which slows the print down. You could keep the trapezoidal profile but reduce acceleration and deceleration to lengthen the acceleration and deceleration phases instead, and that too would typically reduce ringing.

To get an accurate comparison, you need to use a higher peak acceleration in the S-curve profile than you do in the trapezoidal profile, so that the total acceleration time is the the same in both cases. Similarly for deceleration.

[markdashabout]

Did you say higher pint speeds?

[stewwy]

@dc42 makes sense, heading towards the classic bell shaped curve, if you had unlimited speed and limited acceleration that is where you would want to be anyway.

[JoergS5]

just for info: I saw the TMC5161 uses S-Shaped motion. I'll test whether it reduces vibrations at the extruder.

[Neonode]

I am using printer with ball screws and I can say that for me S-curve is really important. While belt motion got some elasticity ball screw got 0. This is really cool as I have no ringing at all and really smooth print but I need to live with very low Jerk and acceleration settings like 200 Jerk and 300 acceleration. If I got faster the ball screws start producing noise like hammering during direction change. Current jerk implementation is just stupid. It is okay to change the speed with jerk but it is not okay to change the direction with half of the jerk speed. So I am really waiting for S-curve to come as it really will make my system to perform really well and to be silent.

[Catalin_RO]

@neonode What size of ball screws are you using (length, diameter and pitch) and what size of stepper (NEMA* and the torque)?

[Edgars Batna]

@dc42 said in S-Curve/ sinusoidal , Jerk +acceleration:

Unfortunately, in 3D printing we have a much worse problem, which is that curves are approximated by straight lines. This unfortunately forces us into making the first derivative of position discontinuous, to avoid dropping the speed to zero at every boundary between line segments in a curve. As long as we are forced to do this, there is very little point in worrying about the discontinuity of the second derivative.

If we ever reach the situation where the model files we slice represent curves properly, and the slicers that generate gcode from them generate Bezier curves, cubic splines or some other representation of curves, then implementing smooth changes in acceleration may be worth looking into.

Yes, but that would also mean whole new generation of modelling tools, gcode, slicers - generally the whole toolset. Can't we have a feature which approximates segmented movement using curves? Supporting curves way down the pipeline in the firmware is a thing that can be reused once the slicers are up to par.

The thing about curves is that nothing is a 100% curve. The 3d models are meshes or a mix of corners and curves that would otherwise need to be approximated somewhere, be it in firmware (if hardware permits) or PC application software as a pre-processing step.

[Urban]

@neonode I agree!! The line segment jumps can be handled with filtering in the servo driver even if that is not a perfect solution.

[gnydick]

I agree with trying out s-curve. My printer is turning out great, and I want higher speed printing.

These ripples are more visible than they are palpable, but the corner ringing is detectable to the touch.

https://dyzedesign.com/2016/10/printing-300-mm-s-part-1-basics-hardware/

https://www.controleng.ca/servosoft/SSHelp1033/source/MotionProfile.htm

I'm making another post with the photo with a different topic, keep an eye out

[dc42]

Have you looked at the dynamic acceleration control feature in RRF 2.02RC6? It may help you to control the ringing. See https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M593_Configure_Dynamic_Acceleration_Adjustment.

[gnydick]

@dc42 worth a try. Still would like s-curve. I'm not too worried about being slightly slower, my printer is printing cleanly at 150mm/sec, probably could go faster if I had a more powerful system of drivers and motors.

[Twigz]

Good morning

I've run into a problem that may or may not need a s curve.

I'm driving the x and y gantry with a brushless/ encoder + lead screw setup and am able to get speeds up to 1mtr/s.

The whole hotend assembly is rather hefty at 0.5 kg. At quick direction changes (corners of Infill at 45 degrees in a cube) it shakes uncomfortably much and I have to reduce to 500mm/s^2. At this acceleration it would take 1.5 seconds and approximately 500mm to get to its maximum speed.

I did some tests and when printing a corner in a radius of 75mm an acceleration of 10.000mm/S^2 even seems reasonable
My thought would be that the slower ramping up is what is causing this improvement. (as the direction turns from x to y the y gantry has to move exponentially faster)

At 10.000mm/s^2 it only takes 0.07 second and 25mm to get to its maximum.
If we interpolate between the two that gives 0.75 seconds and 262mm to obtain maximum speed. (in reality this would only be 25% quicker) this could decrease the overall print time on long complicated prints by quite a lot.

I think printers with either a high capability of speed or a heavy hotend assembly will greatly benefit from a ramping acceleration/deceleration.

I don't know if this is easier to setup than a s curve but perhaps it would be an idea to multiply the acceleration by time and by a factor in time to reach the max acceleration.
In this case we could ramp up to 10.000mm/s^2 in 1 second and it would look like this:

Acceleration = (acceleration*((t/factor) ^2))

After 0.1 seconds:
Acceleration= (10.000*((0.1/1) ^2)=100mm/s^2

After 0.5 seconds:
Acceleration=(10.000*((0.5/1) ^2)=2500mm/s^2

After 0.75 seconds:
Acceleration=(10.000*((0.75/1) ^2)=5625mm/s^2

After 1.0 seconds:
Acceleration=(10.000*((1.0/1) ^2)=10.000mm/s^2

Ramping up to 5000mm/s2 in 3 seconds:

After 1 seconds:
Acceleration= (5000*((1/3) ^2)=555mm/s^2

After 2 seconds:
Acceleration=(5000*((2/3) ^2)=2222mm/s^2

After 2.5 seconds:
Acceleration =(5000*((2.5/3)^2)=3472mm/s^2

After 3 seconds:
Acceleration=(5000*((3/3) ^2)=5000mm/s^2

Applying the same formula to the extruder would also ramp the extruder to not create under or over extrution during the ramping up.

I've never heard of issues caused by the jerk between acceleration and max speed so this may or may not be a problem.

Keeping acceleration and deceleration seperate would lead to even more tuneability as acceleration tends to be able to be a little bit higher.

Jeff

[Twigz]

After some more calculations and thinking i figured the reverse might be beneficial as a replacement for jerk. To stop extreme shaking and ringing the best would be to get to a full stop before changing direction.
In this case reversing the above formula to jerk=jerk*(SQRT(T/Factor)) would start from a stop with a high acceleration where the acceleration increases exponentionally less.

You could then finetune the jerk for sharp corners and direction changes after which you can tune the acceleration to the max your printer is capable off.

I made some Ghraps to show what i mean in the hopes of it making things more clear in my explanation.

EDIT: When the jerk speed has been reached it would continue using acceleration instead.

jeff

[dc42]

What I am looking to do at the same time as implementing S-curve acceleration is to replace jerk by junction deviation, but for the deviation to be planned instead of mythical. This will make it possible to eliminate attempts to change the speed of the motor instantaneously. In fact i see little point in implementing S-curve acceleration without tackling jerk (i.e. commands to change motor speed instantaneously) at the same time, because instantaneous speed change is much worse than instantaneous acceleration change.

When implementing S-curve acceleration, you can either keep the peak acceleration constant (which lengthens the acceleration time, and hence printing time), or you can increase the peak acceleration so as to keep the acceleration time constant. Lengthening the acceleration term in itself reduces ringing in most cases. So where S-curve acceleration has been reported to improve print quality, it may actually be the increased acceleration time that is making the difference. Also, the Bezier curve implementation of S-curve acceleration in Marlin has the side effect of reducing average acceleration when the acceleration takes place over several short segments, for example when printing curves.

I do expect S-curve acceleration to improve the sound of the printer when cornering; although I think there are probably easier ways to do that.

[Edgars Batna]

@dc42 said in S-Curve/ sinusoidal , Jerk +acceleration:

Have you looked at the dynamic acceleration control feature in RRF 2.02RC6? It may help you to control the ringing. See https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M593_Configure_Dynamic_Acceleration_Adjustment.

I'm using it and I can see an improvement in ringing on some corners. Overall ringing is less, but it is predictably now more inconsistent over multiple layers. Also, it depends on a well calibrated single ringing frequency, but here I've got X, Y ringing to actually take into account. On CoreXY ringing is different for both axes, plus things like tool changing means we need to sort of recalibrate each time. I assume E and Z are not directly affected, but I think they do need to have their own ringing controls.