S-Curve/ sinusoidal , Jerk +acceleration

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

dc42

I think the main reason we wanted to do that was because when some users had a problem, they would resurrect an ancient thread that appeared to be related instead of starting a new thread.

NitroFreak

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

I think the main reason we wanted to do that was because when some users had a problem, they would resurrect an ancient thread that appeared to be related instead of starting a new thread.

What is so wrong about that? The information posed in those threads is not wrong just because it´s old.
It also makes it easier for future searches if tangent problems are all in a single thread rather than 50 separate ones.

bot

@NitroFreak the firmware was developing at a very rapid pace when that decision was made. Often, those ancient threads were no longer current. They had info which was outdated and applied in no way to current scenarios.

Now, we face that same rate of change so locking threads may become prudent (when they have outdated info).

Phaedrux

Since that locking old threads decision we have also added a notice that shows the time elapsed since the last post to indicate more clearly when a thread has been resurrected.

Sometimes it's useful to be able to add information to old threads, and sometimes it would be better to just start a new thread. If you want to you can still link to the locked thread.

There's no solution that will solve everything and make everyone happy. It is what it is. If there is a thread you find that you want unlocked, message a moderator.

Anyway, none of this conversation has anything to do with S curve acceleration.