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.

[dmbutyugin]

Hmm, if max_jerk is truly 1500000, it as the higher end of its values. I would suggest to try the following: completely comment out [scurve] section and try printing with just [smooth_axis] enabled. And another thing - re-enable [scurve] section, but put a smaller max_jerk value, for instance 300000. The thing is, your problem appears to be pretty rare (not sure if anybody else ran into this issue), but given that the master branch prints fine with the same settings, it is certainly related to [smooth_axis] or [scurve] kinematics. So I am trying to help debugging the problem by trying different combinations that hopefully will allow us to identify what is causing it.

Edit: you can also double-check your other printing parameters: that the printing temperature you are using is what is suggested for your filament, that you are not exceeding volumetric printing speed of your hotend (I wouldn't exceed 8-10 mm^3/sec on v6 and alike; BTW, which hotend do you use?), and that the thermistor didn't get loose or broken off. Honestly, it's not very likely, but if something like that happens, it can produce strange and surprising effects.

[tgmorris99]

After much more testing and totally reverting back to a clean install it turns out the issue was related to the temperature being too high. Doesn't really explain why it was working on larger, longer, runs though. I'm doing some more test prints and will likely redo the calibration but using the original numbers with acceleration of 5K looks promising. I tried 7K acceleration but it resulted in visible ringing.

The other thing I notice is that both 3K & 5K acceleration have what looks like salmon skin or wood grain pattern but this is on a corexy so I'll need to figure out what's going on there.

[BlackStump]

@tgmorris99 I see in your config you are using TMC2208 but you mention you are using TMC2225, I do not know if they are configured the same. btw TMC,s website makes no mention of TMC2225
You would need to check the TMC datasheet to check if the parameters are the same. I suspect that is where your problem lies as I use a SKR Pro V1.1 with TMC2208's without issue and I have done multiple test prints with most of @dmbutyugin branches

[tgmorris99]

The TMC2225 is a direct replacement for the TMC2208 according to the BigTreeTech TMC2225 User Manual

Firmware with TMC2208 settings
The TMC2225 UART mode can be used by directly replacing
TMC2225 on the motherboard using TMC2208 UART mode.

I've got some more testing to do but it appears that the problem was related to extrusion temperature - though I don't understand the mechanism where it only seemed to impact smaller prints.

[slavedas]

The TMC2225 is a direct replacement for the TMC2208 according to the BigTreeTech TMC2225 User Manual

Firmware with TMC2208 settings
The TMC2225 UART mode can be used by directly replacing
TMC2225 on the motherboard using TMC2208 UART mode.

I've got some more testing to do but it appears that the problem was related to extrusion temperature - though I don't understand the mechanism where it only seemed to impact smaller prints.

@tgmorris99 I've seen this before. More rapid retractions pulls molten filament up into the heatbreak because it's retracting more often with less of the molten filament being pushed out the hot end before it needs to retract again.

[dmbutyugin]

The TMC2225 is a direct replacement for the TMC2208 according to the BigTreeTech TMC2225 User Manual

Firmware with TMC2208 settings
The TMC2225 UART mode can be used by directly replacing
TMC2225 on the motherboard using TMC2208 UART mode.

I've got some more testing to do but it appears that the problem was related to extrusion temperature - though I don't understand the mechanism where it only seemed to impact smaller prints.

I think @BlackStump meant the salmon skin problem; you should indeed double-check that. Note that Klipper may, modify more internal Trinamic registers than Marlin does (or modify them differently) - so even if TMC2225 works as a direct replacement of TMC2208 in Marlin, it may not be the case with Klipper.

The underextrusion problem could be related to what @slavedas said; and in general, short moves are slower because the toolhead has less space to accelerate and decelerate - so the filament has more time to "bake" in the too hot hotend, which may damage the filament's polymer structure after some amount of time.

[KevinOConnor]

There's been a lot of great progress on this topic over the last 2.5 years. However, I think this github issue has become too unwieldy. I'm thinking of closing it in favor of opening new issues with updated topics.

@dmbutyugin - what would you think about opening up tickets for "input shaping", "input smoothing", "adaptive acceleration", along with tickets for any other development you feel is currently interesting?

At this point, I feel pretty confident that the initial software associated with this issue (simple "bezier s-curve" on unmodified trapezoid generator) does not provide a good solution. Similarly, I feel pretty confident that my early attempts at smoothing in PR #2030 is also not a good solution. So, I think it may be beneficial to close these github issues to better focus the conversation on the newer solutions.

-Kevin

[dmbutyugin]

@KevinOConnor I do not really mind, if you prefer it that way

However, I think this github issue has become too unwieldy.

I guess that's largely true.

I think the only benefit of the current #57 issue is that it is a single place, and in the new setup people may get confused as to where to report problems. To be fair, right now there may be some confusion too.

@dmbutyugin - what would you think about opening up tickets for "input shaping", "input smoothing", "adaptive acceleration", along with tickets for any other development you feel is currently interesting?

I can do that. Ironically, it is likely that one of the new tickets will be about S-Curve acceleration :) But we'd need some comparative assessment whether it improves anything over, say, simpler input shaping or not - even if under certain conditions. Hopefully, if the latter gets integrated into the mainline, it will be easier to do that.

[Fenixin]

@dmbutyugin, Hello again!

I don't really know the reason for the change but I measured the new resonance frequencies in my printer and they have changed. The new frequencies are:

X axis: 27,3986244182194
Y axis: 31,1828690076847

Old frequencies:

X axis: 24
Y axis: 21

In the attached pdf you can see the results of the test scurve-shaping-medidas-nuevas.pdf. I have included pictures of the measurement of the frequencies, the test didn't end because the Y axis started to skip steps.

Some observations:

• The ~100hz frequency in the Y axis is there from the start. So is not a problem with any of the branches. This brings a question, can these branches compensate two resonance frequencies in the same axis?
• Without doubt, the best branch reducing ringing is scurve-shaping with shaper: ie, at least from tested ones. The corners are rounder at very high accelerations but if you stay in the safe side the results are stunning.
• All these test were made with this config file changing needed parameters when changing branch:
  printer.cfg.txt
• Without pressure advance (the first test I did and reported here was with pressure advance on) there is something funny going on in scurve-smoothing, everytime there is a change in layer (a change in z coordinate) a small blob generates when the acceleration is high enough. There is a picture of this in the pdf file. It could be the object moving by itself from the high accelerations and the fact that is one shell thick. I could test and watch this next week.

I hope this helps. From now on I'm going to use scurve-shaping with shaper: ie with accelerations of 3000~4000. If you have any questions just ask.

[dmbutyugin]

* The ~100hz frequency in the Y axis is there from the start. So is not a problem with any of the branches. This brings a question, can these branches compensate two resonance frequencies in the same axis?

Incidentally, yes. You can use 'EI' shaper tuned for 33 Hz for Y axis (note that it reduces vibrations in the wider range of frequencies; at shaper_freq_y = 33 it reduces vibrations from ~27 Hz to ~40 Hz and then around 100 Hz; different lines in the plot are for different damping ratios of the printer):

* Without doubt, the best branch reducing ringing is `scurve-shaping` with `shaper: ie`, at least from tested ones. The corners are rounder at very high accelerations but if you stay in the safe side the results are stunning.

With 31 Hz you were already close, so it makes sense. BTW, X axis seems to have some remaining vibrations at high accel even with EI shaper. You can try to measure the frequency of those using an existing print. If their frequency is the same ~27-28 Hz, there's nothing else you need to do.

* Without pressure advance (the first test I did and reported here was with pressure advance on)  there is something funny going on in `scurve-smoothing`, everytime there is a change in layer (a change in z coordinate) a small blob generates when the acceleration is high enough. There is a picture of this in the pdf file. It could be the object moving by itself from the high accelerations and the fact that is one shell thick. I could test and watch this next week.

This is why it is recommended to print the test using smooth vase mode. Generally, I guess it's fine.

From now on I'm going to use scurve-shaping with shaper: ie with accelerations of 3000~4000.

It makes sense. The general direction where this is going is to recommend and use scurve-shaping branch. I just need to write some tuning docs. But you have already tuned it.

[Fenixin]

With 31 Hz you were already close, so it makes sense. BTW, X axis seems to have some remaining vibrations at high accel even with EI shaper. You can try to measure the frequency of those using an existing print. If their frequency is the same ~27-28 Hz, there's nothing else you need to do.

My X axis is in pretty bad shape, it vibrates A LOT. AFAIK the problem is the belt tensioner, it's really springy and makes the whole axis act like spring. I want to change X belt tensioner for something that is more stable but, funny thing, if I change it the printer won't fit inside the current enclusure and right now there is no other place for it, so it's going to stay like that for some time until I find a new place for the printer or I build a new enclosure.

The frequency is more or less the same, around 27Hz, the fix has to come from hardware, there is no more to do in software.

Again, thanks for your work, I will follow this or any issue that you open to be up to date.

[dmbutyugin]

@Fenixin

The frequency is more or less the same, around 27Hz, the fix has to come from hardware, there is no more to do in software.

OK, then it makes sense only to adjust the Y axis frequency to 33 Hz with EI shaper. Let me know if that reduces high-frequency vibrations (though AFAICT, high-frequency vibrations are already smaller with EI shaper at 31 Hz).

[Fenixin]

OK, then it makes sense only to adjust the Y axis frequency to 33 Hz with EI shaper. Let me know if that reduces high-frequency vibrations (though AFAICT, high-frequency vibrations are already smaller with EI shaper at 31 Hz).

Just printed the test again with the Y axis to 33Hz. There seems to be a very subtle improvement in one of the ripples but is something so faint that I'm not sure it's really something or just my imagination.

This is going to be my default branch/config. Thanks again for your work

[ehtnevets]

@dmbutyugin is manual_stepper using scurve step generation. I seem to be getting timeout on slow manual_stepper moves.

[ehtnevets]

Small bug on @dmbutyugin s-curve fork manual_stepper.py,

self.trapq_append(self.trapq, self.next_cmd_time, 2,
accel_t, 0., accel_t, 0., accel_t, 0., accel_t,
cp, 0., 0., axis_r, 0., 0.,
0., cruise_v, accel, accel)
should be

self.trapq_append(self.trapq, self.next_cmd_time, 2,
accel_t, 0., accel_t,
cruise_t, # was 0
accel_t, 0., accel_t,
cp, 0., 0.,
axis_r, 0., 0.,
0., cruise_v,
accel, accel)

[mwr666]

Small bug on @dmbutyugin s-curve fork manual_stepper.py,

self.trapq_append(self.trapq, self.next_cmd_time, 2,

accel_t, 0., accel_t, 0., accel_t, 0., accel_t,

cp, 0., 0., axis_r, 0., 0.,

0., cruise_v, accel, accel)

should be

self.trapq_append(self.trapq, self.next_cmd_time, 2,

accel_t, 0., accel_t,

cruise_t, # was 0

accel_t, 0., accel_t,

cp, 0., 0.,

axis_r, 0., 0.,

0., cruise_v,

accel, accel)

I need to check this because i had some issues with manual stepper also with this branch

[dmbutyugin]

@ehtnevets It uses some common parts, but sticks with AO=2. But yes, you are right, this seems indeed like a root cause of the bug. I pushed a fix to scurve-smoothing, could you check that it's working now?

[dmbutyugin]

Separately, I have updated the tuning instructions in scurve-shaping branch, which is now a suggested branch for use. If you are using a different branch, please switch to this one. If you have been using scurve-smoothing branch, the transition can be as simple as switching the branch in git and converting the config

[smooth_axis]
shaper_freq_x: ...
shaper_freq_y: ...

instead to

[input_shaper]
shaper_freq_x: ...
shaper_freq_y: ...

which should give you similar results.

You can also try to follow the tuning guide at your convenience.

If you have issues with input shapers specifically, you can use #3025 ticket to report them.

[Nandox7]

This comment/conversation came up regarding the tuning process for pressure advance but is wroth to ask here as well.

Does using the bed mesh after setting the tuning params will disable them? That seems to be the case for pressure advance and as the commands are the same I'm checking it here. Thanks

[dmbutyugin]

@Nandox7, I guess it depends on how you try to enable the bed mesh. Could you post the entire list of commands that you are trying to execute? And the config you start with?

[Nandox7]

So in the gcode that is generated for the tower from the slicer it will have

G28 W ; home all without mesh bed level
G80 ; mesh bed leveling

And this is what is defined in klipper for G80

[gcode_macro G80]
gcode:
 BED_MESH_CALIBRATE
 G1 X0 Y0 Z10 F3000

In terms of commands I simply use the ones mentioned in the tuning guide.

[dmbutyugin]

@Nandox7 Generally speaking, no, AFAIK BED_MESH_CALIBRATE should not affect it, unless, of course, SAVE_CONFIG or RESTART is issued afterwards. What I'm not 100% sure about is how it will interact with TUNING_TOWER - but you can monitor the messages at the start of and throughout the print. Also for many commands you can run them without parameters and they will simply print the current state. So you can add them to your gcode after G80 (or as a part of that macro), e.g.:

G80
G28
SET_PRESSURE_ADVANCE
SET_INPUT_SHAPER
SET_SCURVE
....

and check their output in the Octoprint console.

[KevinOConnor]

Thanks everyone! The input_shaper module has been merged, and I think we've made a lot of great progress since this issue was originally created. I'm going to close this issue in order to focus the conversation on the newer issues #3025, #3026, and #3027.

-Kevin

[ryannining]

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

Hi i see that problem too, and right now working on that, still just simulation on javascript. But currently it handle the many segment path. so first it split path from first trapezoid planner, which may contain 3 part (accel, cruise , decel) then store it on next level 2 buffer.

in this level 2 buffer, we plan the same type motion (same accel in many paths) as 1 problem. So it will total the distance, calculate the total time (depend on the max accel , constatn jerk) and run iteration based on time (using time step).

Test S curve path planner

But now i am interesting in input shaper, i have read but still not fully understand how it work internally... i really want to know how it work, and make implementation too...