Trajectory smoothing and acceleration

Hi!
I wrote up an idea for implementing trajectory smoothing:


Maybe it can serve as a discussion starter on implementing some path smoothing.

I'll have to try it out next time I'm firmware hacking, this page seems to hold the implementation details. I'm interested to see how this would go with maintaining geometry across long move sequences.

We've been looking for a move blending algorithm for a little while, looks like we missed that page in our searching, thanks!

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I think Trajectory smoothing would be essential for greater printing speeds. The stride(the derivate of the acceleration) should be avoided... You probably know that better than me, my field is Computer Science not Mechanic Engineer.

Just keeping this important post alive!

I dont know much about the subject so this is mostly a question. Mostly about current SF Z issues and sort, but also the principle.

In the acceleration computing, why does the Z speed get mixed with X/ Y ones. Why not just buffer 3 different values for each axis for last speed, so (for example) when the Z starts move will just accelerate from the last Z speed recorded instead of last X or Y speed.

Basically, why not keep last speed of each axis individually recorded, and a new acceleration starts from that.
Even, if the starting value is too high (and would loose steps), then start from a defined value that doesnt loose steps.

Also i am not sure i quite get what deceleration is meant for. As i see it, each move is basically individual and starts from zero untill the move is finished, and when the move is finished the speed is zero (right?). So i dont see where deceleration comes into play unless stopping from a certain speed gives lost steps, but then again dont go over that speed with setting or even gcode, so that part its sorted.

If we would have 3 step pins for 2 motors (X-Y), we could have a step for each motor separated, then a common step, so this way the moves wouldnt be pure "individually", but would have a common part. But like its used, this is not the case, so each moves starts from zero and ends to zero (speeds), and each move is individual to each motor - at least as long as the stepper motors are concerned.

Bottom line, why g-code parsers do mix speeds from one axis to another?

NoobMan Wrote:
-------------------------------------------------------
> In the acceleration computing, why does the Z
> speed get mixed with X/ Y ones. Why not just
> buffer 3 different values for each axis for last
> speed, so (for example) when the Z starts move
> will just accelerate from the last Z speed
> recorded instead of last X or Y speed.

all axes start at zero. they all finish at zero. last recorded speed would be zero. how is this different from what we're doing now, or am I not understanding your question?

> Basically, why not keep last speed of each axis
> individually recorded, and a new acceleration
> starts from that.
> Even, if the starting value is too high (and would
> loose steps), then start from a defined value that
> doesnt loose steps.

yes, start/end speed is on the todo list, probably in the form of a 'jerk' setting in a move combining algorithm

> Also i am not sure i quite get what deceleration
> is meant for. As i see it, each move is basically
> individual and starts from zero untill the move is
> finished, and when the move is finished the speed
> is zero (right?). So i dont see where deceleration
> comes into play unless stopping from a certain
> speed gives lost steps,

well of course it does.

> but then again dont go
> over that speed with setting or even gcode, so
> that part its sorted.

if you want to stay at a speed you can dead-stop at without losing steps, limit all your prints to about 20mm/s

> If we would have 3 step pins for 2 motors (X-Y),
> we could have a step for each motor separated,
> then a common step, so this way the moves wouldnt
> be pure "individually", but would have a common
> part. But like its used, this is not the case, so
> each moves starts from zero and ends to zero
> (speeds), and each move is individual to each
> motor - at least as long as the stepper motors are
> concerned.

the only time you'd ever use a combined step pin is when a move is exactly 45 degrees, and the computational time it takes to choose to use it is longer than it takes to simply use two step pins and pulse them whenever appropriate.

There's zero benefit from this, and a lot of added complexity both in software and in discrete logic on the board.

> Bottom line, why g-code parsers do mix speeds from
> one axis to another?

The feedrate specifies the speed of the nozzle in 3D space. pythagoras says nozzle speed ^ 2 = x speed^2 + y speed^2 + z speed^2 so of course we have to combine all the axes to get the speed correct.

otherwise you can't draw circles at a particular speed- the diagonals would go 1.4x the speed of the edges parallel to axes!

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
> The feedrate specifies the speed of the nozzle in
> 3D space. pythagoras says nozzle speed ^ 2 = x
> speed^2 + y speed^2 + z speed^2 so of course we
> have to combine all the axes to get the speed
> correct.
>

I start to understand, but i believe the last part is incorrect if we talk about Z, but just correct if instead we put E in the context.

The point which i still dont understand, is why with acceleration, sometimes it tries to move Z at the speed of XY. I dont see the point of Z being part of anything, since Z is simply independent. There is no Z move combined with anything else, so acceleration should be limited to X+Y+E while at the same time Z probably can use a single constant speed all the way.

I meant same thing as here [forums.reprap.org]

At least i would like to have a "Z_acceleration OFF" setting somewhere so i dont have to disable all acceleration just because Z bugs me in the context. I believe the place to do this would be in firmware rather than SF.

Why i still dont understand is why it was made like that in the first place? Am i missing some gcode generator anywhere that can make a diagonal move in height - involving Z?

NoobMan Wrote:
-------------------------------------------------------
> The point which i still dont understand, is why
> with acceleration, sometimes it tries to move Z at
> the speed of XY. I dont see the point of Z being
> part of anything, since Z is simply independent.
> There is no Z move combined with anything else, so
> acceleration should be limited to X+Y+E while at
> the same time Z probably can use a single constant
> speed all the way.

are you still using some acceleration other than ramping?

> I meant same thing as here
> [forums.reprap.org]#
> msg-56249

That's from over a year ago. May as well be ancient history with the way firmwares are going these days.

> At least i would like to have a "Z_acceleration
> OFF" setting somewhere so i dont have to disable
> all acceleration just because Z bugs me in the
> context. I believe the place to do this would be
> in firmware rather than SF.

A start/stop speed will sort you out, or a really steep acceleration on Z.

> Why i still dont understand is why it was made
> like that in the first place? Am i missing some
> gcode generator anywhere that can make a diagonal
> move in height - involving Z?

nophead's setup find the bed's normal vector and reorients all moves around it, so most of his moves involve X, Y and Z components.

mrkim must have one too, since he's printing super long things with his conveyor belt Y axis by extruding diagonally

I'd prefer to do the correct thing assuming we do receive a move that has X, Y and Z components...

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
> are you still using some acceleration other than
> ramping?

Yup i believe i use "reprap" style, as i am using an modified version of "official" FiveD since before it got broken for Gen3 setup.

I wanted to try Teacup but i found it harder to understand, config and fix, related to gen3 at least. I should try getting my head around it though so i could use it as it would be much better than official one for sure.

Quote

There is no Z move combined with anything else

Sure there is. Doing something layer by layer isn't the only way you can move a Mendel. Some use it for milling.

The point you're right is, Z currently calculates too few steps for acceleration in Z (or any other axis having more STEPS_PER_MM than X). Thus, target speed isn't reached for Z moves. Calculating the number of acceleration steps for each axis individually would be the next step.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY