S-Curve acceleration?

[dragonnn]

klipper uses standard trapezoid acceleration as far I know. I never seen a firmware with s-curve like acceleration and I think it would work better for printers Some video from https://www.youtube.com/watch?v=qYJpl7SNoww

Since klipper has enough processing power and the code is well organized I think it should be easy to implement.

[KevinOConnor]

On Thu, Dec 14, 2017 at 10:22:54AM -0800, Mateusz wrote:

klipper uses standard trapezoid acceleration as far I know. I never seen a firmware with s-curve like acceleration and I think it would work better for printers Some video from https://www.youtube.com/watch?v=qYJpl7SNoww

Since klipper has enough processing power and the code is well organized I think it should be easy to implement.

This certainly would be interesting. I don't have any immediate plans to implement it.

S-curves would only need host code changes (no need to change the micro-controller code).

I think one challenge to implementing s-curves would be proper handling of lots of small moves. The current trapezoid generator can seamless accelerate over many small moves, seamlessly cruise over lots of small moves, and seamlessly decelerate over lots of small moves. In effect, if one big long move is broken up into many small moves, there is no adverse impact. This is a nice feature as current g-code slicers tend to emit lots of tiny moves when handling arcs. Having similar flexibility while using s-curves might be challenging.

-Kevin

[dragonnn]

Yeah I know it would only need host code changes. Probably you are right that handling many small moves like on a arc could be challenging. But I think it could be worth the trouble.

[lenne0815]

https://github.com/synthetos/TinyG/wiki/Jerk-Controlled-Motion-Explained

I stumbled over tinyGs implementation yesterday ( Was searching for an alternative to Mach3 for my cnc ) and thought it might be helpful.

Tiny G even accepts Marlin formatted G-Code but has no pressure advance implemented and relies on doing the calculations on a Arduino Due which is not as elegant as doing them on a pi imo.

In a perfect world i would control Cnc, co2 Laser and 3D printers straight from klipper.

My soul is on sale, what do you need kevin ;)

Edit: interestingly enough, ultimaker cloned tinyg for their next commercial controller ( based on a "Tigershark" motion controller board https://github.com/adamjvr/Tigershark3D )

[ceryen]

That TinyG wiki page is an amazing find! Those graphs are glorious :)

The 6th-order motion planning seems to be implemented here. Pay attention to the code sections that are #ifndef __JERK_EXEC:

https://github.com/synthetos/TinyG/blob/master/firmware/tinyg/plan_exec.c#L243

They're using 5th-order Bezier velocity curves to get 6th-order position planning. The velocity planning takes in a starting velocity (Vi), a target velocity (Vt), and the number of steps over which you would like to change velocity (mr.segments). The code then plans a velocity for each one of those steps using a 5th-order Bezier curve.

When planning each velocity change, the math assumes that acceleration and jerk start at zero. This allows them to significantly simplify the math.

I think this means that velocity can be non-zero at the start of each line, but acceleration must be zero at the start of each line. So if a large line were to be broken into many small colinear lines, I think the motion planning would be able to seamlessly cruise over those lines, but not seamlessly accelerate over them. Acceleration would happen briefly within each small line, but the acceleration would start/stop frequently across the many small lines.

I think they mitigate the issue by ignoring moves that are small until the accumulated error is larger than a certain threshold. I'm not sure how effective that mitigation would be for the gcode generated by 3D printer slicers.

Note that this is just my interpretation of the code/math, I could be wrong =P

[ceryen]

Note that they are still using trapezoids to drive overall velocity changes, it's just that the velocity changes are smoothed using the 5th-order Bezier curves.

If the Bezier math could be updated so that the start of each velocity curve has non-zero initial acceleration and initial jerk, then you could chain the acceleration ramp of multiple trapezoids together. This might then allow smooth acceleration over many small lines segments.

Within the Bezier math, I believe that D corresponds to initial jerk, E corresponds to initial acceleration, and F corresponds to initial velocity. They set the D and E coefficients to zero under the assumption that each velocity curve starts with zero initial acceleration and initial jerk. You could instead set the D and E coefficients to non-zero initial acceleration and initial jerk values. The D, E, and F coefficients would then constrain the values of P_0, P_1, and P_2, they would no longer be set to the initial velocity. The constrained values of P_0, P_1, and P_2 would then have to be propagated into the A, B, and C coefficients, and the rest of the math would have to be updated.

[dragonnn]

Hmmm would be make a difference if we would use a true s-curce or a smoothed trapezoid? I think the second would be even better for printing times and speeds.

[ceryen]

A true S-curve would theoretically lead to the smoothest motion, translating to less vibration, less noise, and higher quality prints. Simply smoothing the trapezoid might be good enough though depending on the smoothing used.

[lenne0815]

I think the main advantage of using s curve smoothing over plain trapezoidal planning is that the inertia of the linear drive is taken into account, doesnt matter that much with belts and pulleys and a light extruder, makes a much bigger difference trying to rotate a 5kg leadscrew. Ill have g2core up and running soonish on my big gantry cnc, im exited to see what it brings to the table irl, especially how it behaves in conjunction with toolpath smoothing from fusion360, beforehand toolpath smoothing was done by mach3 with sometimes more than lacking results.

[hg42]

all these kinds of planning with curves are approximations.

In general, we have a physical system with physical limitations. We calculate some movement for it. But it can only follow the calculated movement if those physical limitations are obeyed.

The perfect planning would simulate the complete physical model with something like differential equations and would optimize movement calculations within the known limits.

For a limited acceleration you get the fastest movement if you always accelerate with the maximum (so the result is constant acceleration, which is used by ).

Acceleration is limited by the mass to be moved and the torque of the steppers, and also limited by the construction of the printer (e.g. you want to reduce resonance). It's not easily determined, so the value will be a result of experimentation and experience or you keep it safe by staying below a limit.

Now the question is, what is the physical meaning of higher derivatives (jerk, etc.) and by which physical conditions they are limited. Sure, you could limit those too, which is done by the 6th-order motion planning.

BUT, who said it's the main problem? All this assumes that these are constant limits. But for example the maximum torque a motor can produce is everything else but a constant. That's why I agree with @lenne0815 that this kind of motion planning is probably most effective for CNC machines, because they have big masses and their motion limits may mostly depend on these alone.

Stepping is a mathematical problem in itself. A pure theoretical step would mean you have infinite velocity for an infinitesimal short time (-> Dirac pulse) at the edge of the step and zero for the rest. In reality there are several physical effects that smooth the behavior, like inductance of the motor coils, mass etc. It needs some clever engineering to optimize the behavior, that's why it takes something like a tmc2130...

I am not sure if simply adding more derivatives will help a lot, when at the same time assuming constant limits is known to be wrong. They claim to be the only that use 6 orders, but I think it has a reason why the industry still uses only three. Probably the higher derivations are hidden by other errors in the model. At least the 3rd order seems to make sense.

Seeing improvements depends a lot on the competition. I am sure 6th order motion planning will be better than Marlin. Though, I also saw improvement when switching from Smoothieware to Marlin, which was caused by Marlin forcing me to use lower acceleration, which improved a lot in the print. But real comparision is done by pushing the limits. However, Klipper was clearly ahead of both. So, I am excited to see some comparison between Klipper and some 6th order motion planning on a real machine.

The general strategy for movement algorithms seems to be trial and error. Usually they assume some physical relations, then implement an algorithm based on these assumptions and try that. Some of this may improve movement, but then it's still not clear, if the success is only based on a random correlation or if the physical behavior is really understood. I am usually missing the measurements to prove those assumptions. I understand that nobody wants to do this because it is a lot of work. Today everything is simulated, but from time to time you need to prove if the simulation provides correct results.

I see some potential in the measurement features of the tmc2130. It could be used to really measure what's going on while moving and to find hotspots where movements could be improved. May be at some time we can manage to log these values together with coordinates. If everything is fast enough, measurements could also be used to adjust movement parameters in real time. TMC seems to have hardware controllers that can use those measurements. May be the distributed nature of Klipper is not ideal to handle this kind of scenario. But at least it allows to have a dedicated MCU for the main axes (usually XY), which could handle such a control loop.

[lenne0815]

@hg42 Hmm, albeit creating a real physical model is obviously the best way to do it i personally think that "6th" order motion planning is close enough, dialing in mms3 on my machine by trial and error will yield a pretty spot on image of the forces at play, after finding these values you usually back of that for atleast 20% because youll need to compensate for cutting forces etc, so dialing it in after a model wouldnt yield to much advantage irl.

Interesting find that you found marlin to be better than smoothieware, can you maybe check at what point in time that was ? Right now smoothieware and klipper are based on the same base model for motion planning and i wouldnt know how to explain a bigger difference there, so i guess it wasnt implemented into smoothieware at that point.

The reason we dont see advanced motion planners anywere is simple i think, machine manufacturers keep them well under wraps, cncs are usually sold by "look at this surface finish in this material at these feeds" which includes the motion planner part but its nowhere discussed.

I think the best bet is to test it but as long as g2core doesnt support pressure advance theres not really a point, that would hold back printing speeds so much that motion planner differences wouldnt really come into play imo.

[hg42]

@lenne0815 my point is that even 6th order calculation doesn't help if it doesn't take into account all important(!) dependencies. Example: on a delta printer, you have the linear axes along the towers where the masses of the carriages have to be part of the calculation and you have to add the mass of the effector with hotend, eventually an extruder etc. via some geometric calculation. This is not trivial, but usually the acceleration is still given as a fixed value for the linear axes. In this case 6th order doesn't help. Or what about microstep length being different depending on the position in the step cycle? The same goes for torque. I guess these kinds of errors always have a greater effect than orders 4-6.

The firmware changed from Smoothieware to a recent Marlin bugfix-2.0.x (some weeks ago, also on the same Smoothieboard) to Klipper on Pi3+Mega2560/RAMPS+some_Melzi. Marlin ran smoother than Smoothieware on my Smoothieboard, but as I tried to say, this was some kind of imaginary improvement, because Marlin somehow forced me to lower the acceleration settings. I am sure if I would use the same settings for Smoothieware it would be similar. But I also found if using sane settings Marlin2 can work as smooth as Smoothieware on my corexy. I mentioned Marlin to show that comparisons are dangerous. There are too many things to forget. E.g. how do you compare the jerk setting in Marlin with the junction deviation in Smoothieware? This has a huge effect on acceleration settings (and in fact this was the reason I had to lower acceleration with Marlin). I found if I use jerk near zero in Marlin it is quite similar to Klipper, but still not as smooth. There seems to be some roughness.

At least my Smoothieware version doesn't compare to Klipper, because Smoothieware uses segmentation (though I read that it now supports segment free planning, which I also tried but it didn't work). And I think Klipper calculates more exact, at least the movement is noticeably smoother than with Smoothie (and Marlin2). I can use higher speeds and I could also use some a higher acceleration if I would want. But I prefer to use low currents on my motors. So acceleration is low but speed is high.

I also used all three firmwares with tmc2130 on XY (in standalone mode for now ~= tmc2100) where you can hear every non-smooth movement as some kind of hum. But I cannot compare because it's difficult to do from memory. The difference is not very big and even some wind can create much different impressions.

[lenne0815]

Hm,i think your over complicating it, a single delta stepper nearly always pulls the same load ( depending on the angle of the 3 axis it can differ a tiny bit obviously but in the grand scheme of things its negligible ) with setting mms3 close to its mechanical properties youll be very close to what the motor can actually achieve under ideal circumstances and then again one would back of that a bit so the motors dont stall when the extruder hits overextruded parts or warping overhangs.

A perfect model would just bring the system even closer to its theoretical maximum performance but after backing of a bit for rl reasons i think you would end up with pretty much the same outcome.

The main reason for scurve being theoretically better than trapezoidal is that accel ramps are not switched instantaneous but rather blended, just as the outcome of a simulation. Blending factors obviously not as precise as from a real simulation but then again as i mentioned already imo, plays no role irl as we have other factors outside of the linear system limiting machine movement.

Jerk from marlin cannot be compared because god bless it doesnt exist in klipper, its just a simple value how big an instantaneous speed change can happen, to high equates to stalling motors as they can compensate only so much oscillating overshoot, any value above 0 results in forced artificial ringing. At jerk 0 marlin is just dead slow as theres afaik none or only very little blending going on at directory changes. ( i never tested jerk 0 on marlin, luckily i could jump straight to klipper once i realized what jerk in marlin does )

[hg42]

isn't that what I said? I doubt the 4th to 6th order are noticeable at all. But if they are, I guess other things have to be taken into account first. 3rd order may be useful, but I am not sure. I want to see it, before I accept it.

Given that a stepper always starts at a minimum speed (it's not analog!) the jerk setting from Marlin may not be too unreal if not set too high. With my low settings this worked good enough. But I have to admit, I used Marlin only for a few weeks.

reason for scurve being theoretically better than trapezoidal is that accel ramps are not switched instantaneous but rather blended

I think this sounds better than it is. If you want to accelerate your car as fast as possible, do you slowly press down your pedal?

[lenne0815]

@hg42 Jerk is used at any cornering entry speed conceivable jerk 20 happens in marlin from f.e. 100mms to 80mms or from 50 up to 70, its used basically to cut of all the nifty motion planning necessary for smooth movements with one big slap.

A car is a bad analogy as its acceleration ramps are self limited by design and thereby "forced 3rd order" the motor is held back by its connection to the street, if you hold back a stepper from its commanded pulsing it just stalls, so ideally you need to estimate how much its held back and account for that.

[dragonnn]

You are taking this topic way too far. Just look at this video https://www.youtube.com/watch?v=qYJpl7SNoww this shows really good how in practice any think like s-curve is a good idea for a 3dprinter. It would allowing to maintain higher printing speed and acceleration without increasing the problem called "ringing". A good example of this problem https://cdn.thingiverse.com/renders/bc/d5/47/4c/c0/_7280628_preview_featured.jpg

[dragonnn]

Note that the s-curve beer is even faster then the trapezoid and it doesn't split out. In a 3d printer we are to moving parts with have high inertia - a direct drive extuder, heatbead in a prusa like printer. When such mass stops or accelerates the belt stretches due the not smooth acceleration and this causes ringing

[hg42]

Play the beer video at speed 0.25 in youtube. There is no noticeable acceleration phase at all or at least not appropriate for such a beer. The video created by Trinamic https://www.youtube.com/watch?v=PGYBqAphBHw looks more correct, but you cannot see it in comparison. The beer may be good for promotion and looks funny, but it is not exactly our problem.

However, I accept your explanation about the belts. It's a system with masses, springs and friction. Instead the beer has no damping at all. But anyways, I understand the effect. I already said 3rd order may be useful. But 4 or even 6?

The slower acceleration at start and end of the move has to be compensated by a higher speed in between. This has disadvantages:

• to reach the same performance in total the moves must be longer
• the speed is limited by extrusion

But on the other side bowden systems could have additional benefits? For bowden systems there are people that want to keep the speed constant, especially at direction changes, so acceleration near zero might be good for that.

To be clear, I am not speaking against experimenting. Klipper is the perfect platform to try this. Anyone can do...

[lenne0815]

I think the beer is good to visualize the effects but as its running a single up / constant / down ramp it doesnt reflect that much on what we are doing with our printers, the differences between scurve and trapezoidal arent that big imo. Still, it would be great to see somebody a lot more intelligent than we are implementing it in a way that it can handle shoddy slicer gcode output. Maybe some day soon slicers will be more akin to cnc gcode generators aswell, right now even basic functions like min segment length are not existing and i havent seen an arc ( might be wrong on that ) at all.

[mabl]

I had a quick look at the math here to and tried the follow it in plan_exec. See here.

What is missing is a proper understanding of the trapezoid generator and derive its math. But at least it is a start.

[richClubb]

I'm really interested in seeing s-curve motion profiling on Klipper. I was going to have a crack at it myself.

This might be a bit long, but I set myself a task recently of figuring out the trapezoidal and s-curve motion profile maths. I've done the trapezoidal motion, but I've hit a roadblock on the s-curve. It ends up being a bit more complex and I've not found a nice method of representing it. So if anyone has an idea then please met me know.

This might be a bit long, but I'll try and explain my current logic.

As the acceleration profile is a order equation, this gives a velocity profile of the order and a position of the this gives the following equations.

Integrating gives velocity

Integrating again gives position

if we have a cruising speed of and a cruising time of we can figure out the and times by

and

substituting these into the equation for x and solving for

solving the roots for this equation with gives you a positive root for

If the value for exceeds your then you rearrange this to solve for

The problem with s-curve equations is that each term is at least 1 order more complex, so you have to solve for a lot more variables. Basically the acceleration and deceleration phases are this complex and it just makes things that little bit more difficult. There are probably analytical methods to find the solution, but I'm trying to be a purist and find a numeric method.

Anyway. I thought this might be interesting for people.

[Islandman93]

Ignore my last comment, turns out scaling a sigmoid isn't as easy as I thought. But Wikipedia to the rescue https://en.wikipedia.org/wiki/Smoothstep. Is exactly what is needed for this problem and provides a generalized solution to any desired order/degree.

Here's a better picture (at least it helped me understand better) of how the smoothstep order affects the various degrees. Vel 0 -> 100 over 0.5 seconds. The labeled values show the max.

Also the ipython notebook file where I created this image and some smoothstep helpers. https://gist.github.com/Islandman93/33f242a2f768452019739b05b50be414

[hg42]

Nice...

Based on my limited physical knowledge and my experiences with 3D-printing, I would say the limiting factor is mainly the acceleration.

Reasoning: The mass to be moved is constant, so force and acceleration are directly proportional (force = mass × acceleration). For a stepper motor the torque is limited. The torque is proportional to the force for a given lever arm (= constant).

The second diagram shows an increase of acceleration, e.g. the red curve has nearly twice the acceleration.

So, I think, to see realistic dependencies for a 3D-printer, the diagrams should be recreated with keeping the maximum acceleration constant.

[ceryen]

@Islandman93 In an earlier comment, you asked why Bezier curves. Here is something you might find interesting: smoothstep is equivalent to the same-order Bezier curve with the first half of the control points set to 0 and the second half of the control points set to 1. So smoothstep is a Bezier curve with the control points set to specific values =P

[richClubb]

For anyone looking at this thread who isn't 100% familiar, I put together these graphs to demonstrate the differences.

Trapezoidal Acceleration - 0th Order Accel Calculation

Trapezoidal Velocity - 0th Order Accel Calculation

Trapezoidal Position - 0th Order Accel Calculation

The kicks occur at each of the acceleration transitions, I don't have any traces to hand from accelerometer data, but I've seen it before and it's quite noticable. If you're using a small microstepping then this can de-cog the "position" due to the inertia. This results in a 2nd order position equation

S-Curve Acceleration - 1st Order Accel Calculation

S-Curve Velocity - 1st Order Accel Calculation

S-Curve Position - 1st Order Accel Calculation

Obviously this smooths out the kicks between transitions, but the equations are much more complex than the trapezoidal. This results in a 3rd order position equation

S-Curve 2nd Order Accel - 2nd Order Accel Calculation

S-Curve 2nd Order Velocity - 2nd Order Accel Calculation

S-Curve 2nd Order Position - 2nd Order Accel Calculation

This is again more complex than the 1st Order Accel Calculation, but I can't really see any benefit over the 1st order and it results in a 4th order position equation.

Thinking more about it, I'm making some assumptions on these profiles. The distance travelled is the same, the maximum velocity is the same, the time for the profile is the same, and the time travelled at a constant velocity is the same. However any optimisation performed on these profiles will have to be specific to the profile type. For trapezoidal profiles, we have "max accel", "max velocity", and a "min constant travel time". You can calculate the time for the manoeuvre based on these constraints. For an S-curve profile, we don't have to worry so much about the "min const travel time" as we're smoothing out the transition between max accel and max decel, so this removes a constraint from the modelling. For the 1st and 2nd order S-Curve profiles I've increased the max accel to make sure that the movement completes in the same time frame and with the same max velocity.

I've got the mathematica workbooks for these three if anyone is interested. I'm working on some python code to do the same thing. I'm hoping to set up some tests to instrument the difference between the three so that it can be more precisely quantified.

[KevinOConnor]

FWIW, there are three key math formulas that I think would be necessary to implement an S-curve acceleration scheme: 1 - given a start velocity and a move distance, what is the maximum final velocity that can be obtained? 2 - given a start velocity, a cruising velocity, and a distance under acceleration, what is the time it takes to move that distance? 3 - given a start velocity, a cruising velocity, acceleration parameters, and a distance into a move, what is the time that the head should be at that distance?

For reference, the current Klipper code (with constant acceleration) uses: 1 - end_velocity = sqrt(start_velocity^2 + 2*accel*move_distance) 2 - accel_time = accel_move_distance / ((start_velocity + cruise_velocity) * 0.5) 3 - time = sqrt(2*distance/accel + (start_velocity/accel)^2) - start_velocity/accel

So, if anyone looking at the S-curve math could condense it to these formulas, then I think that would help quite a bit.

[hg42]

in general it's an optimization problem.

The optimization target is the time used for a print. The main limit (I think) is the acceleration (because torque is imited and mass is constant).

So, I think the shortest time can be reached with maximum acceleration.

On the other hand, vibrations are a problem. Which means frequencies should avoid several fixed values.

Now, does this sound like 6 orders of derivation to you?

I think constant acceleration is the best strategy. You only have to avoid certain resonances. And this is a non-linear problem. Not sure how to resolve this, but I guess 6th order doesn't help.

And take into account, that any change will shift frequencies. So simple AB tests are not real tests.

For a real comparisions, the same model has to be printed in the same time. And there should be several models because each model has it's own resonance frequencies.

[bmc0]

You only have to avoid certain resonances.

With constant acceleration, the jerk is (theoretically) an impulse (or Dirac pulse, if you prefer) when the acceleration changes, so will excite resonances of any frequency.

[hg42]

@bmc0 I don't think a Dirac pulse in the third derivation will excite all frequencies in the original function (distance/time). Instead the distance/time function is a very smooth curve.

IMHO the whole vibration/jerk/whatever thing is not really caused by the acceleration function itself. It's caused by the sequence of moves that depends on the printed part and the slicer. The sequential pattern of the moves excites lower frequencies.

I believe, the limiting of higher order derivations forces the moves to slow down (take longer time), because the limits force a non optimized acceleration function (acceleration is not at the maximum over the whole acceleration phase, because the peak acceleration must not exceed the torque of the stepper motor). If you simply use a lower constant acceleration instead, so that each move takes the same time as for the other case, then you will probably have a similar effect, may be better.

For example, the diagrams above show, that you have to slow down to not exceed the maximum acceleration (which is proportional to the torque of the motor). For the red curves this would be about half of the acceleration. The move would take much longer then (I guess the time would be more than doubled). If you would reduce the constant acceleration instead to achieve the same time for the move, you would probably have even less vibrations.

[bmc0]

There must be a reason why demonstrations like this one show the liquid sloshing around so much more with a trapezoidal velocity profile. In that video, the move completion time is very similar, yet there is clearly less vibration with the s-curve profile.

[hg42]

@richClubb somehow I missed you comment. I wonder why the first (constant acceleration) has a maximum acceleration of 4 and the others have 6. They should have the same maximum, because it's limited by the torque (I think). Or are you going to say that with S-Curve Velocity the acceleration could be higher? I don't think so...

@bmc0 the videos look a bit suspicious to me. But may be I am tricked by some optical illusion. But anyways, we don't have some fluid in a glass. When I look at my corexy printer, I have no noticeable vibrations with a single move. I only get vibrations if I do several moves and they change directions. My gut feeling is that there are some low frequencies that escalate the vibrations. The frequencies are in the range of the moves, not in a range that could be caused by the acceleration curves. That's why I think the acceleration curve isn't our biggest problem, if it is at all.

[richClubb]

@hg42 I had to change the max accel if I wanted to keep the same max speed. Those graphs are more of an example on the different profiles for people who haven't seen them before.

As the acceleration gradually increases and decreases it might be possible to work at higher max accel and decel values, similarly to get the same area under the velocity curve you either have to increase the accel and decel or increase the max velocity. I'm simplifying the problem, as there are other constraints. For example if the movement is small then you'll not be able to reach your velocity peak and therefore any s-curve acceleration will mean the motion will take longer than a trapezoidal profile with the same acceleration.

[KevinOConnor]

On Tue, Apr 03, 2018 at 01:00:12AM +0000, Harald wrote:

Based on my limited physical knowledge and my experiences with 3D-printing, I would say the limiting factor is mainly the acceleration.

Reasoning: The mass to be moved is constant, so force and acceleration are directly proportional (force = mass × acceleration). For a stepper motor the torque is limited. The torque is proportional to the force for a given lever arm (= constant).

In my experience, common 3d printer stepper motors have a massive amount of torque. Way more torque than is necessary to accelerate the print head at any reasonable acceleration rate.

Instead, in my experience acceptable acceleration is primarily limited by other factors - too high of an acceleration causes "ringing" in the prints, excessive vibration of the printer, inability to change extrusion flow rates fast enough, jerking of the print head causing previously extruded filament to be disturbed, etc.

So, I think it may very well be possible that selectively reducing acceleration may allow for a much higher overall acceleration with the same (or better) print quality. This is what S-curves are about - slightly slower acceleration at the start/end of acceleration in return for a higher overall acceleration.

-Kevin

[hg42]

@richClubb from my experiences the velocity can be very high, if you keep the acceleration below the physical limit. So I'm quite sure, the acceleration has to be limited, not the velocity. From a theoretical point of view, the acceleration is directly bound to max torque of the motor. It's because torque = arm_length*force and force = mass * acceleration and arm_length and mass are constant. If you exceed max torque the motor will skip.

S-curve will certainly be better at the same acceleration. But then the time for the move will be 1.5x longer, right? In those videos they certainly didn't limit acceleration, otherwise the move time would not be the same. So it's another use case. It's the purpose of the optimization task to find the best solution inside the limits. So you cannot ignore them.

[hg42]

@KevinOConnor

I think it depends on your use case. Are you printing at the limits? What is limiting the speed? E.g. with a lame extruder you cannot print very fast. Also, dynamic forces can be very high.

When I optimize my printers, I usually increase acceleration until I see skips. I think a stepper motor skips, if the maximum torque is exceeded. right? So at least for me it's the limiting factor. It may also be questioned if the simple holding torque is the limiting value. Especially with microstepping it's much more complicated. Then you have to find a balance for the motor current and cooling considerations.

Depending on the filament paths I sometimes have to reduce acceleration or speed to stay out of resonances. That's why I want to adjust max_accel and max_velocity while printing. For me it's a fact, that vibrations heavily depend on the filament paths. And yes, you can find a configuration, where any part will work. But that's a lot slower.

My former experiences showed that the junction deviation may play a bigger role. The last commit according to this changed some things at least in my test environment. I always thought, the junction deviation algorithm doesn't look like a model for the physical system we have. It might be a kind of workaround for no proper timing of the acceleration curves.

[KevinOConnor]

On Wed, Apr 04, 2018 at 08:27:14PM +0000, Michael Barbour wrote:

There must be a reason why demonstrations like this one show the liquid sloshing around so much more with a trapezoidal velocity profile. In that video, the move completion time is very similar, yet there is clearly less vibration.

I suspect most of these videos are just marketing. :-)

FWIW, here's my interpretation of why S-curves may be helpful:

During acceleration, the stepper exerts a force to move the mass of the print head. It applies this force to a belt. Since every force has a counteracting force, the stepper is also placing a force on the frame of the printer.

The printer frame and the belts are not perfectly rigid - over small time scales they can act like a spring. So, during acceleration, some of the force moves the print head, but some of the force is stored as a potential energy in the frame and belt. When the steppers stop accelerating, the force the steppers are apply is greatly reduced, and the potential energy in the belt and frame is released. This sudden release can result in a "jolt" in the print head.

In contrast, with S-curves, the force that the steppers exert on the belt and frame is gradually released. Thus, the potential energy in the belt and frame would also be gradually released. This might then reduce "ringing" in the print and reduce vibrations in the printer. (To be clear, though, I think it definitely would need testing to see what the real world impact is.)

-Kevin

[hg42]

@KevinOConnor

Well, now you added a very different point of view. And I think, you are right.

So, for this part of the system limiting the change rate of the acceleration might indeed be a huge improvement.

[richClubb]

@hg42 you make a good point and I 100% agree. I'm working on the optimisation problem at the moment. I've got the following constraint set, and the general objective is to minimise [t].

Where [c] rate of change of accel, [a] is acceleration, and [d] is the rate of decrease of acceleration. What do you think?

I'm mostly interested in the math of the problem, and hoping for a better method of movement as a result :) I know a lot of commercial CNC machines use higher order movement control, but they obviously tend to deal with heavier end effectors. One reason people use the trapezoidal movement control is that it is significantly less complex to perform and is "good enough", and generally you're right it is.

[hg42]

@richClubb I think even if CNC machines move more mass, they also move more slowly. So from this point of view it may be a comparable use case. The more important difference might be the force on the end effector which is nearly zero for 3D-printers and high for CNC machines. Errors in the movement may also affect tool wear. From this point of view it seems to be a very different use case especially when looking at the limits this adds to the optimization task.

Klipper is ideal for experimenting with such algorithms, so simply give it a try.

Btw. it would be very nice to have a module for that, which can be swapped with different modules for the same purpose, may be even at run time. Then you could easily compare the effects while printing. I am saying this, because I know it's very difficult to objectively compare this from memory.

[hg42]

@richClubb c and d look very similar. Is c the rate of increase then?

I think the usual way would be to apply an upper limit to each derivation. If you want to separate up and down (this could indeed be usefull), then it would probably make sense to also separate positive acceleration from negative. So it could be: [v <= v_max, a_min <= a <= a_max, c_min <= c <= c_max] with a_min, c_min being negative values. A negative value for v seems to make no sense.

[hg42]

@KevinOConnor @richClubb it may be interesting how Kevin's last revolutionary statement would change the optimization task. Eventually c_min, c_max could depend on the speed and acceleration that are reached? At least the "spring" is loaded proportional to the acceleration (F=m*a). A limit on the acceleration change rate would imply, that the maximum may not be reached for shorter moves (just like it is now for the velocity). So the spring can have different loads when released.

This "spring" view is very interesting, because it could explain why I think a lower acceleration would help more than other means.

[Islandman93]

@ceryen Yeah foot->mouth I had no idea that bezier curves were as general as they are. Course I didn't know much about polynomials 2 days ago either. This problem is a really great way to learn.

@richClubb This process can be done numerically also, since the curves are defined polynomials. Additionally, the problem is further simplified for longer moves that reach the max velocity since the s curve will reach the end velocity in the same amount of time (albeit with higher maximum acceleration).

For those that are working on the math I've updated my ipynb with my attempt at the answer to Kevin's question 1 (and actually all of them rely on the same function). We can get the time from distance of any degree s shaped velocity by integrating and solving for the roots (this took a while to figure out but was surprisingly easy to do with numpy). My brain is fried right now and I can't get the scaling correct (so that it works for velocities larger than 1 and distances greater than 0.5). So the plots in the last cell aren't right. Was trying to scale distance as a function of the maximum distance from linear acceleration (since that and s will have the same max) but it didn't work and I started throwing random operations around...

Checkout the last cell for the function I'm talking about. https://gist.github.com/Islandman93/33f242a2f768452019739b05b50be414#file-smoothstep-ipynb

[Islandman93]

@KevinOConnor I've solved for question 1 and 3 but am unsure if I've understood question 2 correctly.

My understanding is this: Question 1 is a query to find the max velocity and time of a planned move to determine if the acceleration phase will be cut short. And the solution I've written must only be used this way since it does not use any S curve calculations, simply the relationship between a certain degree of smoothstep and the ratio between it's max acceleration compared to a linear acceleration.

Question 2 Is simply how long Question 1 will take which I've written assuming that max velocity is not reached.

Question 3 actually pertains to planning where the head should be at a given time. For this I use the numpy polynomial package to integrate and solve for roots. I haven't done any speed testing on this but it's going to be definitely slower than the linear acceleration calculation.

The code for both questions resides in the last two cells of the ipynb here: https://gist.github.com/Islandman93/33f242a2f768452019739b05b50be414#file-smoothstep-ipynb

Let me know what else I can do to help.

For any that remain unconvinced at the massive effect this could have on printing, here are two simple videos showing how jerk affects the things we try to print. A simple move of 10mm at F4000. Water: https://photos.app.goo.gl/fvf610BPKwiBhfJm1. An unattached print: https://photos.app.goo.gl/fumvrspkT6lWuUva2

[bmc0]

Slightly off-topic, but has anyone considered implementing tool-path smoothing using Bézier curves, b-splines, or an algorithm like this one? Maybe it wouldn't make much of a difference in reality, but tool-path smoothing is required for the motion planning to be "correct" in the strictest sense.

[lenne0815]

Typically thats done in the "slicer" have a look here https://www.youtube.com/watch?v=5PKR5ansIPo theres a modifier "smoothing deviation" There are implementations directy in the machine control software aswell ( Mach3s toolpath deviation modifier f.e. ) but they are difficult to work with as you dont know how parts turn out without actually running them.

[dragonnn]

Hmmm looks like Marlin goes a step forward https://github.com/MarlinFirmware/Marlin/pull/10337

[hg42]

@dragonnn thanks for the pointing to that.

Their implementation seems to work well. The developer reports great improvements, though he did not tell how he tested, e.g. if printing time increased.

Apparently my former skeptical view is proven wrong.

Or may be, the effect is based on the springy behavior mentioned by @KevinOConnor. At least the whole printer construction can be seen as a spring.

[dragonnn]

I think the big question is not if printing time increased but if printing time increased beyond normal printing with lower acceleration and jerk. I think comparing printing time this will be like that: high acl and jerk which lowers quality of you print > printing with some kind jerk free algorithm > printing with lower acl and jerk which gives you the same quality as the jerk free algorithm

[mabl]

The whole charm of that sixth order bezier curve approach seems to be that you can just keep on using the trapezoidal speed profile formulas, but replace the actual speed profile with the bezier curve. There will be no change in printing times then.

Initially, I had thought that this will give you different duration times and distances travelled, but instead everything remains the same, since the curve is symmetric around the "linear line" connecting start and end velocities. (Integral v(t) for t from 0 to 1 gives (v_start+v_end)/2)

Introducing this into klipper should be streight forward in this case. I'll have a look soon.

[hg42]

I still assume a maximum acceleration, that the steppers cannot exceed without skipping. The maximum acceleration limit may be wrong, but it is my personal experience and seems to be logical. Of course this has to be proved, yet.

@KevinOConnor said that the acceleration-based-skipping limit is very high and doesn't matter here (which I doubt).

Assuming an actual acceleration limit, a constant acceleration results in the shortest possible printing time. So, any non-flat curve will increase printing time (see red curve above, just scale everything such that the red curve does not exceed the constant acceleration curve).

If the printing time for the red curve would result in let's say twice the printing time, so to be comparable you could greatly reduce the constant acceleration instead. Then compare the vibrations.

[hg42]

but anyways, there is no reason the algorithm shouldn't be implemented. It will prove itself. And as I said, I totally accept the "spring" theory.

Currently, my only concern is to keep an eye on the real reason (I will probably do some tests). If it really is the "spring" behavior, then some things might have to be considered additionally. E.g. a spring is usually preloaded or it may have some lash and this might result in some offset in the formulas.