Firmware and acceleration

How does the firmware used for delta robots work? Do they calculate accelaration etc. correct? Or do they just calculate the moves/acceleration for an ordinary xy printer and "convert" them to delta geometry?

Marlin:
Cartesian system is converted to delta system and the dynamic limits of movement are used on delta coordinates. That means speed, acceleration, and jerk limits are obeyed for carriage movements. The limits are not considered for the effector movements.

Repetier:
I do not know.

How much would it help to have firmware that actively handled both Cartesian and non-Cartesian limits? I know this requires much more processing power. The controller I have in mind has plenty.

I guess it would not be very usefull. I mean the tranformation between delta and cartesian is pretty smooth (you can differentiate it, more than once ). So smooth movement on towers will lead to smooth movement on the effector. Well, except that pesky locations where the speed limiting tower is switched. Speed transformation will not be smooth there, but at least it will be continuous. And this switching has a nice conseqence of avoiding those parts of the cartesian<->delta transformation which would lead to too high speed effector movements.

But I would like to see arguments for handling both carriage and effector limits

I think handling both would be nice for bots with strange geometries. However, to do it right I would want the acceleration to remain continuous as you transition from one limit to the other. (On the surface, this doesn't sound trivial.)

In reality, I like to design so that the limits on the effector coordinate system doesn't cause the steppers to exceed their limits in the usable print volume. However, as geometries get stranger and stranger it might become important to not impose this artificial restriction.

nicholas.seward Wrote:
-------------------------------------------------------
> I think handling both would be nice for bots with
> strange geometries. However, to do it right I
> would want the acceleration to remain continuous
> as you transition from one limit to the other.
> (On the surface, this doesn't sound trivial.)

It is probably not such a big deal (at least for delta). We should just use some nicer function for limiting the maximum speed. Currently, the function is max(towerAspeed, towerBspeed, towerCspeed). It could be changed to something else, e.g. towerAspeed+towerBspeed+towerCspeed. And we would get rid of the non-continuous acceleration of the effector at those "pesky locations".

But what we get with this? Just a continuous acceleration over the build volume, but only form the point of view of the delta transformation. To have it realy continuous everywhere we would need to get rid of how the planer uses acceleration at the lower level (when planning speed for one tower). Currently it goes either at the maximum constant speed or it is mamximally accelerating/decelerating. This is to have it as quick as posible and still obey limits on maximum acceleration of carriages. For cartesian, this would directly relate to maximum moments the motors can generate. For delta, it is not that easy but carriages and effector are much lighter there.

So we already have non-continuous acceleration there at the lower level. Why bother with non-continous acceleration at the pesky locations where the maximum effector speed controling tower switches? If we want to get rid of non-continuous accelration it should be done everywhere or we should not bother.

Moreover, to speed printing up almost everybody uses a non-zero jerk. So we not only have non-continuous acceleration. We have also non-continuous speed! (Well, from the point of view of controling firmware.)

But why bother with achieving continuous accelration? The only consequence I can think of would be ellimination of higher harmonics in the pritner structure vibrations. But who cares about them? The structure is probably much more silent than steppers themselves. Mounting steppers on some stiff rubber pads should help more. Hmmm, even belt elasticity should eliminate that higher frequences. So as for as the structure vibrations, we are bothered with the lowest frequences most. These will be nearer to the printer frame resonant frequency (since we have rather weak (non-stif) frames) and these may lead to errors in the printed parts. But we will not eliminate low frequences by making acceleration continuous.


> In reality, I like to design so that the limits on
> the effector coordinate system doesn't cause the
> steppers to exceed their limits in the usable
> print volume.

I agree but just to be sure. I was talking about "avoiding parts of the cartesian<->delta transformation" only form the point of view of maximum speed limitation. It does not limit the reachable print area in the current deltas.

@hercek: I hear what you are saying. Delta's are pretty much covered. Simpson and Rostock style printers have pretty well behaved print envelopes. There are no singularities, etc. We can get them to print very smoothly without much problem as is. I am really talking about printers such as Polar3D that have some singularities.

First, as someone with a physics background it bugs me that jerk has units of mm/s here. So instead of the mm/s^3 that we learn about in school that would guarantee that the acceleration would be continuous it is the value of acceptable discontinuities in velocity. (There has to be at least a few people out there that are twitching at this definition of jerk.)

So why is jerk done this way? Simple. If we are to move along lines and we didn't allow discontinuities in velocity then we would have some very long prints. That is not to mention the ooze effect we would see on corners. For me the problem goes very deep. I model with NURBS. NURBS are super faithful to cylindrical, conical, toroidal, etc geometries. In order to print, I have to destroy these beautiful surfaces and replace them with triangles. The problem is compounded further when we slice with only straight-line moves. For me, the whole stack needs to be redone. We need to model with NURBS or some other way that doesn't approximate the geometry. We need to make a slicing program that can handle true geometry. The program needs to be able to use something like a 5D spline (x,y,z,e,t) to specify moves. This would drastically reduce the size of the "gcode". (It is in quotes because gcode is not up for the job but you know what I mean.) This would also allow acceleration to be handled by the slicing program without having to break up each line into a bunch of tiny pieces. This may not remove the need for discontinuous velocities but it would reduce the need.

I am personally investing time into NURBS modeling and slicing with NURBS input. Luckily, there is a newly open sourced project SolveSpace that is very promising on the modeling front. I assume that if I can actually pull off a slicer with NURBS input that it wouldn't be too crazy to jump to spline output. Of course, that means I would have to write new firmware.

Side note: In some ways I like that the printer makes adjustments so a print comes out better. However, I would prefer to tell the bot exactly what to do and it would faithfully do it. Current gcode is not even close to being up for that job. However, however, this is all in reference to open loop systems. Closed loop systems will be a whole new beast.

Edited 1 time(s). Last edit at 10/31/2013 10:43AM by nicholas.seward.

Ok, I did not realize that redoing the whole toolchain is an option.

In such a case, I agree that the open loop part of a 3d printer (probably stepper control only) should be "stupid" and do just what it is told. So what we would need is to provide only the information when to increment/decrement rotor position for each stepper. These are the data which need to be communicated from PC to the printer. The amount is huge. So we have a compression problem. NURBS seems like a nice way to compress the data.

I still do not see much reason to avoid non-continuous accelerations. But if we would have an almost complete model of a printer and would take into account all the major forces (accelrations, weights, elasticity specifications of printer parts) then we might be able to create an optimal slicing which would lead to quickest print for given quality level stepper srength and noise limits. In such a case there would not be any non-continous accelerations. Probably we would even need smooth accelerations (to control vibrations better). I doubt it is worth is. We also do not want slicing which requires a supercomputer. Much simpler models should work well enough at least till 3dPrinter market is not really huge to justify the detailed modeling.

hercek Wrote:
-------------------------------------------------------
> Ok, I did not realize that redoing the whole
> toolchain is an option.

It is a long term goal of mine. The tool chain we currently have is very good. I am currently working my way from the modeling side to the firmware side. Making a slicing engine for NURBS would drastically reduce processing time and it would also be a perfect opportunity to play with non-planar slicing. I could even have the slicing engine output spline data that could easily be post-processed into standard gcode until we get a chance to work on the firmware side.

> In such a case, I agree that the open loop part of
> a 3d printer (probably stepper control only)
> should be "stupid" and do just what it is told. So
> what we would need is to provide only the
> information when to increment/decrement rotor
> position for each stepper. These are the data
> which need to be communicated from PC to the
> printer. The amount is huge. So we have a
> compression problem. NURBS seems like a nice way
> to compress the data.
>
> I still do not see much reason to avoid
> non-continuous accelerations. But if we would have
> an almost complete model of a printer and would
> take into account all the major forces
> (accelrations, weights, elasticity specifications
> of printer parts) then we might be able to create
> an optimal slicing which would lead to quickest
> print for given quality level stepper srength and
> noise limits. In such a case there would not be
> any non-continous accelerations. Probably we would
> even need smooth accelerations (to control
> vibrations better). I doubt it is worth is. We
> also do not want slicing which requires a
> supercomputer. Much simpler models should work
> well enough at least till 3dPrinter market is not
> really huge to justify the detailed modeling.

Continuous acceleration is one of those thing that would be nice to have but real world parts won't allow it. The same goes for continuous velocity. I can only strive to minimize the number of discontinuities. (I really like the idea of doing a complete model in software. I agree that it would be overkill but I don't think we should completely discard the idea.)

Reading this made me think that if simultaneously the hot end could move in X, Y independently of the table X, Y,
could you get closer to a constant velocity, or could it help in some other way?

This is not my field of expertise, far from it, but it sounds interesting!


By the way, anytime you are using
both X and Y motions, it pays to split
up the problem. Move your tool in
the X direction and your workpiece in
the Y direction. This can convert a
thorny two-dimensional problem into
simpler one-dimensional ones.
And greatly simplify things.
[www.tinaja.com]

A2 Wrote:
-------------------------------------------------------
> Reading this made me think that if simultaneously
> the hot end could move in X, Y independently of
> the table X, Y,
> could you get closer to a constant velocity, or
> could it help in some other way?

Looks too complicated and expensive to move both effector and bed. If you mind non-constant velocity of effector because of delta kinematics then there are two easier solutions:
1) Modify firmware so that it plans speed/acceleration based on effector movement instead of carriage movement.
2) Do not use part of built area which is far from center (build the printer bigger and use the center part only). This will not eliminate the speed variations but makes them smaller.

You cannot eliminate speed variations completely anyway since acceleration and jerk are finite.

Quote
nicholas.seward
it bugs me that jerk has units of mm/s here.

Jerk isn't a continuous movement, it's a bump in speed which is physically not possible. In practice it works, because typical 3D printer frames and belt drives are pretty flexible. Threaded rod drives (stiff connection between motor and rod and high inertia of the rod) can do only some 0.5 mm/s or 30 mm/min jerk.

Quote

I am personally investing time into NURBS modeling and slicing with NURBS input.

IMHO, teaching firmwares to do true NURBS curves would be the more important part. Given the Bresenham algorithm and the need for a constant speed (which Bresenham doesn't give for curved movements), that's not exactly trivial, but would allow to insert small splines between straight movements to have jerk-free, still continuous speed movements. Oh, and expect an uproar if you try to tell people curves are a physical neccessity for constant speed movements, many simply don't believe this and think the jerk-approach is physically sane.

Teacup firmware does movement calculations now on a time based manner, every 2 milliseconds. This gives you about 20.000 CPU ticks for such calculations, almost independent from current print head moving speed.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Interesting thread. A vectorial slicer/firmware would be great.

But in physics, Jerk is the rate of change of Acceleration, like Acceleration is the rate of change of Velocity and Velocity is the rate of change of Position.

For example, if you're standing in a street car and there's constant acceleration, you can lean into it and feel comfortable. But if the acceleration changes, you have to lean differently. That's a jerk.

So I would expect jerk to have units of mm/s /s /s, or mm/s^3, not mm/s (a velocity). Something seems confused.

Quote
DaveGadgeteer
But in physics, Jerk is the rate of change of Acceleration, like Acceleration is the rate of change of Velocity and Velocity is the rate of change of Position.

For example, if you're standing in a street car and there's constant acceleration, you can lean into it and feel comfortable. But if the acceleration changes, you have to lean differently. That's a jerk.

So I would expect jerk to have units of mm/s /s /s, or mm/s^3, not mm/s (a velocity). Something seems confused.

So what we have here is two definitions for the same word. I am not sure what the history is but someone wanted a parameter that would represent the allowable discontinuity that you can have in velocity. In a way it makes sense, a machine with discontinuous velocity is in fact jerky. (I cringe at the this use of the word jerk but it is what we are stuck with.)

How typical firmware works:
*If the magnitude of the vector difference between the next velocity and the current velocity (dv) is less than the "jerk" then the velocity is allowed to instantaneously change.
*If dv is greater than the "jerk" then the path planning uses the acceleration values.

This "jerk" is a necessity when the path is nothing but segmented line segments. (I would like to trade in the line segments for splines.)

Also noteworthy, I am unaware of any firmware that tries to keep discontinuities out of the acceleration graph. In fact, the graph would usually be a bunch of discontinuous horizontal lines. I wonder how useful it would be to smooth this out. It is worth an experiment.

Use of the term "jerk" was discussed in this thread a while ago. Here's the exchange:

Quote
nophead
I think jerk is the speed below which it doesn't use any acceleration.

Quote
Quentin T.
I've heard of the jerk in calculus, which is the derivative of the acceleration. If thats what it is then the jerk would be the rate that the acceleration increases, but that just didnt make any sense to me, and I also didnt know a reasonable value for it. Is 20 a good value?

Quote
nophead
That is what jerk should be mathematically but I think Reprap firmware uses the name inappropriately. If your machine can move at 20mm/s with no acceleration without losing steps then 20 would be a good value.

Quote
nicholas.seward
Also noteworthy, I am unaware of any firmware that tries to keep discontinuities out of the acceleration graph. In fact, the graph would usually be a bunch of discontinuous horizontal lines. I wonder how useful it would be to smooth this out. It is worth an experiment.

I have been experimenting with this recently based on this paper I ran across:
Exponential Trajectory Generation for Point to Point Motions

It presents a velocity planning formula which is designed to offer continuous jerk as well as acceleration. I've done quite a few mathematical models with it now, and it looks quite promising. I'm getting closer to implementing it in firmware using a simple linear approximation of the normalized velocity curve. I don't have any real-world results with it yet, but I'm happy to share when I do.