S-Curve/ sinusoidal , Jerk +acceleration

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