S-Curve/ sinusoidal , Jerk +acceleration

  • Give me this, and you will change somany lives.


    Thank you ❀

    ps Lars is impressive, I dont think he even uses trinamic drivers that natively support S-curve ramps either.

    edit* Thank you for your hard work DC42

  • administrators

  • Oh no. Not this again!

  • Haha, pints.

  • correct me if im wrong- but the other thread asked for different acceleration values based on speed
    not a whole different acceleration profile to make for more efficient movement over-all and less ringing..
    is Ian discrediting lars's findings with less ringing artifacts and higher print speeds?

    Perhaps im just too stupid to understand? haha.

    i think this is a whole new topic?

    Ringing is caused (generally) by flex in the belt and oscillation thereafter.- the new acceleration profile not only myself but others theorize will reduce oscillation frequencies that trigger belts to act erratically therefore better surface finish.

    is this an incorrect assumption stemming from the video evidence presented?

    why would Trinamic invest R&D if its not a useful feature?
    why would Lars invest time and effort to implementing this also, Is his findings inaccurate?

    please educate me πŸ™‚

    a quote from Lars's findings

    I'm currently up to about 550mm/s travel, 425mm/s infill printing (extruder permitting) and 100-150 mm/s perimeters (depending on quality & planner speed – and if sharp corners are needed -- extruder response limits crisp corners at high speed). Even at lower speeds, the s-curve profile gives better print quality -- for example, less oscillation / waves after hard corners .

    we can theories till the cows come home- but it seems from the evidence that Sin- wave acceleration profiling as the future of high quality fdm movement? once again i am open minded to be crushed - if you can give me evidence to prove its not effective please present it here.

  • administrators

    What the OP is arguing for is to make the second derivative of position (commonly called 'jerk' by mechanical engineers, although that term has a different meaning in 3D printing) continuous, instead of discontinuous as it is with trapezoidal velocity profiles.

    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.

  • non-poliginal vector STL files? in a perfect world πŸ˜›

    i mean surely it can be implemented without that πŸ˜•
    seems lars figured it out. maybe with some sort of approximation technique?

    im hoping he publicizes his documentation maybe you can take a look at it?

  • administrators

    I haven't yet seen any videos or other hard evidence that S-curve acceleration improves 3D printing - except for those in the habit of putting beer glasses on top of the hot end!

    From a theoretical perspective, S-curve acceleration should reduce the higher frequency components of the forces applied, and so would reduce the tendency to excite high frequency resonances.

  • The notion that the ripples and oscillation in the water would correlate to the ripples and oscillation in the belt is compelling.
    I hope Lars uploads his firmware and i will do some test prints and compare.
    Lars has claimed it reduces ringing not quite hard evidence i agree- perhaps not enough for you to invest time and effort- i respect that.
    thanks for considering it at the very least.
    I hope this is revisited. if only for the purpose of learning.

  • @dc42: second derivative of position called acceleration not jerk IIRC. So the OP suggest make acceleration smooth. IMO it is worth of considiration not sure about implementation cost.

  • administrators

    You are quite right of course, jerk is the third derivative of position. I started writing one thing and ended up writing another, without editing what I had already written.

    I remain of the opinion that implementing smoothly-varying acceleration is of dubious value unless we first deal with the elephant in the room i.e. discontinuous commanded velocity changes, aka jerk in the 3D printing sense.

  • @mak:

    non-poliginal vector STL files? in a perfect world πŸ˜›

    i mean surely it can be implemented without that πŸ˜•
    seems lars figured it out. maybe with some sort of approximation technique?

    im hoping he publicizes his documentation maybe you can take a look at it?

    STEP files.

  • does duet firmware not handle jerk as-well as marlin?

  • @T3P3Tony:

    don't get Ian started πŸ˜„

    Thank you Tony for bringing this into (at least) my focus!
    Very interesting thread!
    I learned to not make things more complex then they need to be!

  • administrators


    does duet firmware not handle jerk as-well as marlin?

    Very old versions if RRF (about 2.5 years old) didn't handle jerk very well. I don't think Marlin handled jerk properly at that time either.

  • Alden Hart
    4 years ago
    Acceleration is performed using a piecewise linear representation of a constant-jerk equation. This is the 3rd derivative of position instead of the 2nd derivative (constant acceleration) that is commonly used. The pulse rate is computed for each of the S-curve segments. Each axis is run as a "minor axis" of the 50 Khz clock rate. This minimizes jitter and aliasing - at the expense of running a fast clock rate all the time. The code is on github under tinyg if you want to take a look.

    perhaps look here.

    Id donate for you to take a serious look at this but something about your intellect tells me you're good for money dc42 πŸ˜›



  • administrators

    Yes I know there is code out there to do S-curve acceleration. What I am saying is that it's pointless using it in 3D printing unless we do something about the requirement to command instantaneous velocity changes in 3D printing, which is necessitated by the approximation of curves by straight line segments together with the need to avoid stop/start motion for each line segment.

    Commanding instantaneous velocity changes is likely to be far worse than commanding instantaneous acceleration changes, because it's asking for infinite acceleration. I could implement S-curve acceleration, but unless you set maximum jerk to a very low value, you would still excite vibrations when printing curves. And if you did set jerk to zero, it would print the curves very slowly and jerkily.

    S-curve acceleration may make more sense for CNC machines for two reasons. The G2 and G3 commands are more commonly used to print arcs, rather than approximating curves using line segments. Speeds are much lower, so jerk can be set very low, perhaps even to zero.

    I'm not saying that I won't implement S-curve acceleration in the future, I am saying that it has limited value in the context of 3D printing. OK for printing straight lines, useless for printing curves. If it was easy to do it properly, I would probably have done it already. But doing it properly requires the solution of cubic equations to calculate the step pulse times (currently RRF solves quadratic equations to calculate them).

    So I would rather focus on a solution to jerk first, probably by deliberately deviating the tool path from the commanded path a little. When that's sorted, I can look at S-curve acceleration.

    It would be interesting to calculate the forces generated in a typical 3D print due to to jerk and step changes in acceleration, then take the Fourier transform and see what the various contributions are in the most important frequency bands.

  • I wonder if you can put an accelerometer onto tool head and input on the duet, to record the feedback,

    you perhaps could use that data… and the real time data to create a PID tuning system to dampen out the oscillation real-time.. perfect printing. also you could use that accelerometer to judge if there have been skipped steps or nozzle crashes..
    ...imagine having that setup then somebody mounts their accelerometers off axis and the whole printer goes haywire correcting wrong values lol
    alright Thanks for hearing me out Dc42- I hear you’re doing exciting things with duet. Keep up the good work- best wishes.
    the struggles to get rid of belt wobble are real.

  • So a few weeks late to the party but…


    So I would rather focus on a solution to jerk first, probably by deliberately deviating the tool path from the commanded path a little. When that's sorted, I can look at S-curve acceleration.

    I think this is the best solution and could greatly help out. Machine tools that use Fanuc controllers have an option to use a technique called Smoothing/Nano smoothing that does exactly what you are proposing. Many modern day CAM packages approximate complex curves as straight lines, same as our slicers do with STL files. There are some high performance machine tools that can approach 3d printing speeds while machining. Fanuc's answer was to allow deviations in the tool path by using look-ahead and building a NURBS curve. It is even intelligent enough to automatically turn off when the movement vector exceeds a specified angle.



  • Both AMF and OBJ file formats support curve approximation in different ways. It seems that Microsoft's 3MF does too. Doesn't mean any common CAD software actually properly exports that feature of the file formats. I understand that there aren't any slicers which would properly handle this yet either.

    Looks like Cosine Additive has some G2/G3 stuff figured out. I know this is already implemented in Firmware. It's beyond my capabilities but maybe a post processor could bridge the gap between current slicer capabilities and what the firmware is capable of?

  • Curve approximation as straight segments would really be fine if there was hardware accurate/precise enough to create artifacts in FDM prints just from the "error" of microstepping, right? Polyjet machines are amazing because they show stl roughness. We still don't have proper pressure regulation within hotends. Nor do we have common methods for modeling kinematics (which may follow with the dissemination of higher order movement planning in desktop printing platforms). Perhaps a feature like s-curve movements will drive better hardware. It should lift the acceleration/payload and velocity ceilings a bit. I'd like to know if s-curves even match to "advance" behavior in a standard hotend like a titan aero.

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


    Bottom is a square wave, not a trapezoid. You'd see 4 sploshing events if it were a trapezoid.

  • I have ready 3D printing s-curve velocity profile. And continuing velocity to next move in tangential directiin. Support corner shape to move without stop to next directiin and start from 0. Now i rewrite code to custom moderboard with pic32mz 200mhz. On pic24hj128gp202 calculate next move is abow 4us. . Now i must write communication protokol to support g code. In this moment i have G0 G1 G2 G3 and G4. Hi this pass for testing.

  • administrators

    While I was on vacation I did a Fourier analysis of the effects of trapezoidal and S-curve acceleration on exciting ringing. My conclusion was that whether S-curve acceleration helps or not depends on the relationship between the time spent accelerating or decelerating and the frequency of the ringing that you are trying to avoid.

    Here is the summary. Let T be the time spent accelerating or decelerating, and let F be the frequency of ringing that you want to avoid.

    • If F << 1/T then constant acceleration and S-curve acceleration are equally bad.
    • Otherwise, if F < 1.3/T then constant acceleration is better than S-curve (triangular profile) acceleration. In particular, when F = 1/T then constant acceleration will hardly excite the ringing at all; whereas S-curve acceleration will excite it greatly.
    • When F > 1.3T, S-curve acceleration wins at most frequencies. The higher F is, the better S-curve acceleration is - although the tendency to excite ringing when using constant acceleration also falls with rising F.

    Here is a chart to compare how the two acceleration profiles excite ringing at different frequencies.

    alt text

    Based on this analysis, I discussed how to adjust the acceleration time to reduce ringing in this thread https://forum.duet3d.com/topic/5951/periodicity-of-ringing/39 and received reports that it worked. Today I found time to do my own beer-sloshing tests (see the video I posted to that thread), and they too have confirmed the theory for constant acceleration (trapezoidal) motion.

    So before you decide that you must have S-curve acceleration, you really need to know the frequency of the ringing that you are trying to eliminate. If the ringing frequencies are high enough, then S-curve acceleration will help. But if they are low, then it will probably be better to use trapezoidal motion, and cancel out the lowest ringing frequency by choosing the acceleration carefully.

    I'll write up the maths in a blog post when I find time.

  • Hi, it is not too surprising that there is a certain time between the acceleration changes, which causes to increase or reduce ringing.

    Every time the acting force (acceleration) changes the system gets bumped and stars to oscillate. So every acceleration change introduces one oscillation and all oscillations together get super-positioned, meaning the waves can amplify or cancel each other. If the big bumps (ramp start and end) are spaced in time in a way the big waves overlap, the ringing will be maximized and vice versa. This effect will appear at multiple acceleration times (it is periodic).

    But it is surprising, that a more gentle change of acceleration will increase the problem anywhere. More gentle means less dominant waves and less chance of amplifying these dominant waves. Maybe it is just bad luck or a bad coincidence. At least in theory it seems hard to find a not too academic explanation for that behavior.

    Which s-curve profile did you use ? How big was the maximum acceleration using s-curve compared to the constant ramp acceleration ? How much was it higher ? Was the max speed or speed at the end the same ?

    What also should help to avoid amplifying interference is to use different acceleration changing shapes at start and end of a ramp. E.g. start with d(acceleration)/dt <> 0 and end with d(acceleration)/dt == 0.

Log in to reply