S-Curve/ sinusoidal , Jerk +acceleration

dc42

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

gnydick

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

Twigz

Good morning

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

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

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

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

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

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

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

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

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

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

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

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

Ramping up to 5000mm/s2 in 3 seconds:

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

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

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

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

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

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

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

Jeff

Twigz

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

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

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

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

jeff

dc42

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

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

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

Edgars Batna

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

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

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

Sphyloid

@dc42 I know this is an old topic but your post here is 100% wrong, it is not entirely about ringing. It is instead about how stepper motors work. As you get higher RPM the motor loses torque exponentially. With a proper S curve and a rigid machine it may be possible to cut print time in half without losing steps or quality as you can use every bit of available torque at any given RPM with no fear of step-loss. Gone is the need for max speeds and conservative accelerations as you are only limited by the motor. Instead of the motor at the highest RPM in your desired speed range. There is no fear of going "too fast", setting a max speed is not necessary beyond a software limitation to catch errors in calculation.

Personally I am searching for a feature that dynamically allows the user to define their own curve biased on the torque curve of the steppers. Marlin has already done this, it is not impossible. Though I do not believe they allow this to be user customizable.

Not sure how this slipped past you guys.

deckingman

@Sphyloid Whilst I accept what you say may be true as a general statement, it only applies to situations where motor torque is a limiting factor, and with the light weight tool heads that 3D printers use, achieving the desired torque is easily done by selecting an appropriate motor. For 3D printers the overal print speed is limited by how fast you can melt and extrude filament, not by how fast you can move the hot end in X or Y directions. So I have to disagree that any form of fancy acceleration control is going to reduce print time at all, let alone cut it in half.

Whilst I accept that there may be some benefit in using S curve acceleration with CNC tool heads that have mechanical cutters, I fail to see how one could coax the filament being forced through a tiny hole to faithfully follow an S curve acceleration profile in the same way that the hot end carriage might. Smooth linear acceleration of molten filament is difficult enough to achieve, due to the severe damping effects and time lags involved with melting filament and forcing that viscous fluid through a tiny hole.

Sphyloid

Did the math out and found something very intriguing.

Say your moving mass is 200 grams. With the pitch diameter we can find the force exerted by the motor on the print head, lets say a GT2 12 groove has a pitch diameter of 7.65mm. With a circumference of ~24mm you would get 0.06mm steps out of a 0.9* stepper. Also lets get some RPM numbers at 20mm/s it would be turning 50rpm, 60mm/s would be 150rpm, and 150mm/s 375rpm.

Now that we have our numbers, lets use MS17HA6P4150 running at 24V 1.5A which would make a minimum of 0.385nm from 0-20mm/s, 0.3105nm from 20-60mm/s, 0.16nm from 60-150mm/s. Bear in mind that is only if the driver is outputting 24V 1.5A, at lower supplied voltages the drop is far more aggressive. 12v for example the 60mm/s number being ~30% lower and the 150mm/s number being ~50% lower.

In this config the motor would be able to exert ~100N at 20mm/s, ~80N at 60mm/s, ~40N at 150mm/s. From F=MA we know that the maximum acceleration at 20mm/s is ~500m/s^2, 60mm/s is ~500m/s^2, 150mm/s is 200m/s^2. Then why are numbers for real 3D printers so low? There are several possibilities

-The bottleneck is the extruder
-The weight is higher in real life
-The achievable torque is much lower

We already know that in i3 style printers using current firmware all three are true. Having movements made of many straight lines instead of curves makes mathematically calculating accelerations very difficult. The stress we are putting on the motors is not immediately obvious. Also lets face it, 3D printers supply their motors with much lower voltages and use far weaker motors. Though I am not familiar with the output voltages of the duet 2, I doubt you can output 12V let alone 24V from that driver chip. Perhaps what is left on the table is more on the hardware side than the software side. With this information I would change my argument to an increase of driver output voltage is better than anything possible on the software side, which is what I believe you have done with duet 3. At which point the increase in vibrations/ringing from an extruder that can keep up may have a greater impact. Increasing printer quality is more complicated than I may have given it credit. Similar to how people think having steel bones would make them much stronger when pound per pound having bigger bones would be stronger.

Perhaps using step files in place of STL would yield better quality and less stress on the motors but would it be an appreciable difference? My opinion has shifted. I now think a duet and an e3d hemera are the best upgrades you can make to any 3d printer. Except on the machine I am engineering. Net moving mass is about 5kg, Hbot linear motion, internal volume is 0.36 cubic meters up to 200C heated enclosure, 220C heated bed, 500C hotend. At this scale, there is appreciable acceleration left on the table. The motion system is very interesting. While the way I designed it for my application is quite overkill, I believe it will yield the cheapest printers for a given stiffness. The designs will be released early 2021 and you will see me at 3d printing events later this year.

dc42

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

I know this is an old topic but your post here is 100% wrong, it is not entirely about ringing. It is instead about how stepper motors work. As you get higher RPM the motor loses torque exponentially.

I'm sorry, that's just not true. With constant-current drivers, torque is essentially flat until the supply voltage is insufficient for the required speed. See.g. https://www.omc-stepperonline.com/download/17HS16-2004S1_Torque_Curve.pdf. When the supply voltage is no longer sufficient, the torque drops off approximately in inverse proportion to the speed.

It's a bad idea to run stepper motors at speeds for which insufficient supply voltage is available. The current control won't be accurate, so microstepping won't work any more, precision will suffer and the motor will be noisy; and in the event that the print head hits a blob or curl-up, the motor is likely to lose steps because of insufficient torque to clear the obstruction (which also happens when using stealthChop mode at high speeds). If you ignored all of this and you did want to run the motor in that region, then I concede that reducing acceleration at high speeds would help - which isn't the same thing as using S-curve acceleration.

S-curve acceleration is on our list of features to implement, but only when we can also sort out the far worse issue of jerk.

DocTrucker

Accelerations and instant speed are generally set low to maintain print quality. 3D Printers on the whole aren't rigid enough run at max motor accelerations and get good part quality.

deckingman

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

-The bottleneck is the extruder

Exactly so!

scurve is super cool on miling machine, there can be serious difference in quality if yourun scurve capable machine vs trapesiod .. no clue if it would help on 3d printers but.. read the whole topic and one thing is unclear to me .. the major 2 alghoritms to handle speed change between two lines are "jerk" and "junction deviation" .. grbl started with jerk and moved at some point to junction deviation ... most firmwares that used grbl as a base used old version of grbl and are using jerk (e.g. marlin) while others that started from scratch or used newer version of grbl went with junction deviation (e.g. smoothieware) ..

what I read so far junction deviation gives better quality both for milling and for 3d printing and hear marlin will be moving to it too (first implementation available in mid 2018 iirc, no clue where they are now with it I don't use marlin)

So, what is RRF using ?

dc42

RRF uses jerk. I am quite prepared to add junction deviation as an alternative. However, junction deviation has IMO no sound theoretical basis whatever. The "deviation" figure is purely an artefact.

The practical differences between the two are:

As the angle between entry and exit segments increases, the allowable cornering speed falls off more quickly with JD than with jerk. For example, with acceleration 1000 and jerk 600, if I set JD to 0.013 then at 5 degrees the cornering speed for both JD and jerk is about 115mm/sec. At 90 degrees it is 5.6mm/sec for JD and 10mm/sec for jerk.
Jerk gives different values depending on the angle of entry. For example, in the above calculation the angle of entry was zero (i.e. aligned with X). If I change it to 45 degrees then using jerk the allowable cornering speed for a 5 degree change in angles jumps from 115 to 155mm/sec. The allowable cornering speed using JD does not change. This makes sense for a Cartesian printer. It doesn't make sense for a delta, and perhaps not for a CoreXY either (depending on the relative sizes of the moving X and Y masses and the reflected rotor inertia).

A true junction deviation system, where the deviation is planned not imaginary, would make far more sense because it would allow instantaneous speed changes to be eliminated. But JD as implemented explicitly doesn't do that.

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

RRF uses jerk.

Thanks for the info

junction deviation has IMO no sound theoretical basis whatever.

I can't really compare JERK vs JD as I don't have a firmware that support both so I can try one or another, I can compare 2 different firmwares where one is using jerk and other jd but that's not fair comparison as if I for e.g. compare smoothieware with marlin the prints are ton better on smoothieware but I guess it has more to do with 32bit arm vs 8bit atmega than with jerk vs jd ... on the other hand if I add stuff like pressure advance on marlin that smoothieware don't have then I can get better result from marlin again irrelevant with jd/jerk... so maybe the reason I think JD is better is just

I see firmwares moving from jerk to jd, never seen one move from jd to jerk
the professional big cnc controllers use jd
new grbl moved to jd too (from jerk)

so it's all 2nd or 3rd leve data, I have no way to test any of that myself other than implementing the move myself... time, for sure, and possibly lack of knowledge prevents me from doing that

A true junction deviation system, where the deviation is planned not imaginary, would make far more sense because it would allow instantaneous speed changes to be eliminated. But JD as implemented explicitly doesn't do that.

"as implemented" where? open source implementation I know are grbl and smoothieware (not same). klipper use junstion deviation and but according to https://github.com/KevinOConnor/klipper/issues/468 https://github.com/KevinOConnor/klipper/blob/master/docs/Kinematics.md define it trough square_corner_velocity. I like the smoothing klipper does (looks much close to S-Curve) but all three seems to be using different junction deviation algo

Why not implement "true" jd system with smoothing ? From untrained/uneducated eye it looks like a winwin (except for the one that need to write the code but..)

KevinOConnor created this issue in KevinOConnor/klipper

closed Upcoming change: junction_deviation to be replaced with square_corner_velocity #468

dc42

I suspect that the move from jerk to JD is more to do with fashion than anything else. Still, it doesn't make sense to treat X and Y jerk separately on delta printers and some other architectures.

When cornering at shallow angles, it isn't going to make much difference whether jerk or JD is used. The difference will come when doing sharp corners, where JD will slow the print head down more. Alternatively, if you set the JD to give equivalent jerk at 90 degrees to the jerk values you would have used (e.g. using the formula at http://blog.kyneticcnc.com/2018/10/computing-junction-deviation-for-marlin.html), then JD will allow faster cornering at shallow angles.

Another effect is that when using JD, if you reduce acceleration then the maximum cornering speeds will be reduced in line. This may not be desirable. For example, if you decide to reduce acceleration in an attempt to improve print quality, then curves may be printed jerkily instead of smoothly, because the print speed is greater than the (reduced) allowed cornering speed. So you may have to increase JD to compensate. If you then restore acceleration back to its former value, you may get skipped steps because you are now asking the motors to change their speed instantaneously by too great an amount.

Perhaps a better approach would be to configure a "maximum speed to do a 90 degree corner" instead of a mythical deviation value, and then to calculate the maximum speed for a given angle using the same (complicated) speed vs. angle relationship that JD uses. Or perhaps there is a better relationship to use.

Even if using this approach or native JD, we'll still need to configure Z jerk (to handle instantaneous speed changes when doing bed compensation) and extruder jerk (to handle buggy slicers and pressure advance).

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

I suspect that the move from jerk to JD is more to do with fashion than anything else.

always a possibility
I hate changes that are fashion only

Still, it doesn't make sense to treat X and Y jerk separately on delta printers and some other architectures.

IMO it should be separate for all axes, the gro of these el-cheapo PRC printers have a moving bed, you can't have same jerk settings for Y where you move 5kg bed and X where you move 100g head.. just like you cannot have same acceleration nor same max speed...

no clue about delta, corexy or some of those exotic architectures ... I assume corexy will have same X and Y settings but not sure what I base that assumption on

Another effect is that when using JD, if you reduce acceleration then the maximum cornering speeds will be reduced in line. This may not be desirable. For example, if you decide to reduce acceleration in an attempt to improve print quality, then curves may be printed jerkily instead of smoothly, because the

Yes, I know this (dunno much but this I experienced on my skin so I know), you have to change JD and acceleration at the same time, they are dependant on each other (I assumed it's the same with jerk?)

Perhaps a better approach would be to configure a "maximum speed to do a 90 degree corner" instead of a mythical deviation value, and then to calculate the maximum speed for a given angle using the same (complicated) speed vs. angle relationship that JD uses. Or perhaps there is a better relationship to use.

It's easier to explain for sure and easier to visualize. Maybe that's why klipper is doing it.

Even if using this approach or native JD, we'll still need to configure Z jerk (to handle instantaneous speed changes when doing bed compensation) and extruder jerk (to handle buggy slicers and pressure advance).

Z does introduce complication here for sure, but if implementation allow for separate JD setup (trough 90º or whatever settings) for each axis then the Z, E, A would just be another axis?

That "smoothing" klipper does, that looks like S-Curve, sounds great on paper, I assume it is unrelated to JD/JERK, is RRF doing that? Do you think that has merits? It looks to me that it would reduce shaking immensely and lot of slicers still generate those "shaky" codes filling in gaps.

Don't get me wrong I'm talking out of my %#$^^@$ here, trying to learn as much as I can from this conversation. I'm hardly an expert in these matters

deckingman

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

IMO it should be separate for all axes, the gro of these el-cheapo PRC printers have a moving bed, you can't have same jerk settings for Y where you move 5kg bed and X where you move 100g head.. just like you cannot have same acceleration nor same max speed...

Except that any print move, will take place at the lowest speed of X, Y and E. If you have different instantaneous speed thresholds (jerk) for X and Y, for anything other than pure X or pure Y, then one or other will have to be ignored otherwise the axes movements will get out of sync.

dc42

I think the last 2 comments in this thread are quite a good summary: https://www.reddit.com/r/3Dprinting/comments/ccvn0z/is_junction_deviation_better_than_using_normal/

dc42

An incidental possible advantage of reducing the cornering speed more as the cornering angle increases is that the reduction in the jerk used when you do 90 degree corners would make dynamic acceleration adjustment more effective.

Perhaps we should provide the following factors:

An effective maximum XY jerk value, used when cornering at shallow angles. When cornering, the speed times the sine of this angle must not exceed that jerk value.
A factor that says how much to reduce the jerk by when cornering at 90 degrees. This would be zero to emulate the existing jerk algorithm, and about 0.4 to emulate junction deviation. A value of 1.0 would require coming to standstill when doing a 90 degree corner.

We could go further and add a third point, which is the factor to reduce jerk by when reversing direction (cornering at 180 degrees).