S-Curve/ sinusoidal , Jerk +acceleration

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).

dc42

Here is a chart showing the differences between jerk and junction deviation at various cornering angles. The two jerk values were for entry angles of 0 degrees and 44.9 degrees. Jerk was set to 10mm/swc for both X and Y, acceleration to 1000mm/sec^2, and JD was set to 0.013 so as to match the 0 degree jerk values at low angles.

bot

First: I appreciate all the effort, work and thought that is put into RRF by everyone, but especially dc42.

Second: RRF 2.0x IMO has a GREAT and 100% adequate motion model. I am able to PRINT at 100 mm/s, with jerk and acceleration set appropriately, and have ZERO ringing on very sharp angled corners. [Edit: this turned out to be slightly incorrect. At the time I made this comment, I was doing certain prints at 100 mm/s that did not show the low-frequency oscillation that was occuring. I can NOT print at 100 mm/s -- I get an ultra low frequency oscillation above about 40 mm/s, increasing in amplitude as speed increases] There is also minimal bulging/under-or-over extrusion on the corners, thanks to pressure advance.

Third: I could see areas where we could push the limits and decrease print time slightly while maintaining PERFECT print quality.

This third point is the key. Let's not go ruining something that is nearly perfect for something that is not even close to perfect but a bit faster. Mechanical hardware plays a large role in this. I hope we don't target faulty mechanical setups with the motion algorithms.

One simple idea I had was to be able to scale the jerk and accel (or only one or the other) based on requested move speed.

EG: user sets max accel and jerk values, which will be used on moves which execute at the axes' maximum feedrates. If a feedrate is set lower than the maximum, the jerk and/or accel values are scaled proportionally to the feedrate reduction.

dc42

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

EG: user sets max accel and jerk values, which will be used on moves which execute at the axes' maximum feedrates. If a feedrate is set lower than the maximum, the jerk and/or accel values are scaled proportionally to the feedrate reduction.

Scaling jerk in this way might be good. Scaling acceleration may increase ringing. One of the reasons that DAA doesn't work for some users is that they have acceleration set too low.

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

Except that any print move, will take place at the lowest speed of X, Y and E.

I think I read this already somewhere but I understand it differently ... e.g. if there's no ZE move but only XY then ZE will not be looked at right... now.. the way I imagine XY move (and then easily interpolated further) ..

let's imagine a junction where direction change in X is 10 degree and direction change in Y is 1 degree so if the deviation/jerk/whatever is same for X and Y the drop in X speed should be f(10) and drop in Y speed should be f(1), real speed should be the max speed where X does not go over f(10) nor Y go over f(1)...

but I fear it's not how it works

dc42

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

let's imagine a junction where direction change in X is 10 degree and direction change in Y is 1 degree so if the deviation/jerk/whatever is same for X and Y the drop in X speed should be f(10) and drop in Y speed should be f(1), real speed should be the max speed where X does not go over f(10) nor Y go over f(1)...
but I fear it's not how it works

That's exactly how it works.

@dc42 hah, that's not how I read the code need to do it rested obviously

thanks a ton for that graph, explains everything :D, now I understand better the difference in curve shape

btw the "smoothing" I mentioned from klipper, RRF don't do that? you think that's a good feature? to me it looks like a good middle ground between trapesoid and s-curve and good for both corexy and cartesian

CCS86

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

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.

Hey @dc42 , any progress on these plans? I am excited by this prospect.

I agree that a planned junction deviation would be a huge step forward, not requiring so much jerk to get around corners. Instead seeing them for what they are. Getting to a place where acceleration is a more important factor in driving around an arc, would minimize the use of jerk and maybe open up the usefulness of actual jerk.

Reacting to that sudden change in direction due to shallow angles just seems archaic compared to looking ahead and realizing that you can preemptively accelerate that axis to make the change, within the allowed path deviation.

CCS86

So much good discussion here: https://forum.duet3d.com/topic/4802/6th-order-jerk-controlled-motion-planning?_=1585069930938

I'm not sure why that thread was locked.

Phaedrux

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

I'm not sure why that thread was locked.

I think it just aged out. I can unlock it.

DocTrucker

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

I think it just aged out. I can unlock it.

Why does that happen? Surely we should be encouraging users to search the forum for answers? If they find their issue is unresolved and they have more information to add why does it make sense default to fragmenting the conversation?

deckingman

@DocTrucker in answer to your question about why old posts get locked, it's because Tony did a poll asking what user's thoughts on it were, and the concesus was yes, (
after 45 days IIRC). I'm not saying that's the right decision or otherwise - just explaining the process behind how it came about.

DocTrucker

@deckingman thanks. Missed that completely. Odd decision but fair enough...

deckingman

@DocTrucker Yes I just found the poll - the result was a bit like Brexit - 53% for, 47% against. So not quite half are unhappy and slightly more than half are happy.
https://forum.duet3d.com/topic/7199/locking-old-posts-poll