Add accel and jerk settings for accurate build time calc.

[ominix]

Hi,

Actual Build time is always way off what is estimated, sometimes as much as the double as estimated. The cause is that the calculation is done on linear print speed not counting any acceleration or jerk. For a print where there are many small segments this becomes very off reality.

Could you add 2 fields : Acceleration and Jerk for an accurate calculation of the print time?

Example calculation change (assume length in mm, speed & jerk in mm/s and acceleration in mm/s^2), L = segment length, S = print/movement speed, A = acceleration setting, J = jerk setting (instantaneous speed), T = segment print time

Before:

T = L / S

After:

Time for half segment (as print has to accelerate and deccelerate) acording to jerk (initial speed) and acceleration, lets call it u : u= (- J + SQRT(J^2 + 2 A L)) / 2 A (Edit: Corrected a mistake)

(The above is the valid solution of quadratic equation (A) u^2 + J u - (L/2) = 0 )

if A (J + u) > S (we need to cap the speed) then T = 2 x ( (S-J) / A + (time to print remains of half segment after acceleration) ) (Edit, second part was missing, see my comment on post #4 which explains the detail of this calculation)
else
T = 2 x u

That should give pretty accurate print time... would be great of you could insert these simple formula in the calculation, or make it optional ("accurate build time calculation" option)

I apologize if I made a misake int he above... I'm a bit rusty but the idea is there

[CompoundCarl]

So I'll try to help out a bit with some rusty physics

The simple 1D kinematic equation for distance including jerk is:
s = vi*t + (1/2)*ai*(t^2) + (1/6)*j*(t^3)

where s = distance traveled, vi = initial velocity, ai = initial acceleration, j = jerk (i.e. rate of change of acceleration), and t = time

However, I'm not sure where your quadratic equation came from based on that. Even if I assume vi=0, I still don't come out with the same results.

Can you elaborate on where your quadratic equation came from? Based on the above, I would think the solution would be a cubic equation with no simple solution...

[tenaja]

How much slower will slicing be if they switch from a simple calculation to a complicated one? One of the things I like most about S3d is its slicing speed, and if there was a noticeable difference I'd be unlikely to use the slower calculation.

[ominix]

So I'll try to help out a bit with some rusty physics

The simple 1D kinematic equation for distance including jerk is:
s = vi*t + (1/2)*ai*(t^2) + (1/6)*j*(t^3)

where s = distance traveled, vi = initial velocity, ai = initial acceleration, j = jerk (i.e. rate of change of acceleration), and t = time

However, I'm not sure where your quadratic equation came from based on that. Even if I assume vi=0, I still don't come out with the same results.

Can you elaborate on where your quadratic equation came from? Based on the above, I would think the solution would be a cubic equation with no simple solution...

Well, in 3d printing jerk isn't the derivative of the acceleration as the definition states, but just the initial instantaneous speed, so if jerk is set to 10, it means the stepper will start immediately at 10mm/s and accelerate from there.

The equation is : distance = Vstart x delta-time + (Acceleration^2 x delta-time)/2

We need to find the delta time (for a half segment since the process is Start at jerk speed, accelerates, eventual constant speed, deccelerate and stop from jerk point). So we solve the equation for Vstart = jerk, Acceleration = acceleration setting, and distance = half segment size

Then when we have the delta-time value, we have to see if we are in a case where it's accelerating until the mid point and deccelerating after, or if you reach the print speed, and stay there for a while until you deccelerate (for short segments and high print speed, you never reach the goal speed).

If there is no constant speed, the time to print the segment is 2 x delta-time found above, otherwise we need to do some more calculations (I did make at least one mistake in my original post):

First let's see how much distance we have travelled until reaching the wanted speed, for that we need to know the time until reaching the goal speed, this is simple time-to-goal-speed: =(Vgoal - Vstart) / acceleration. With that we use the same equation as above: distance-until-reach-goal-speed = Jerk x time-to-goal-speed + (Acceleration^2 x time-to-goal-speed) /2

Now the part I forgot in my original post: the remaining distance at constant speed is : dist-const-speed = half-segment-size - distance-until-reach-goal-speed

time-at-constant-speed = dist-const-speed / Vgoal

time for half segment = time-to-goal-speed + time-at-constrabt-speed

=> time for segment = 2x the above.

This time it should be correct.

To answer the other comment, the difference is very significant depending on what you print and your print speed, the faster you print, the most off is the current build time estimation, and the most small segment you have as well

For example, for my settings (Jerk = 8, Acceleration = 800) and a print speed (goal) of 50mm/s (3000mm/min), the time given by the build estimate in S3D is :

0.02 second for 1mm segment
0.04 second for 2mm segment
0.1 second for 5mm segment
0.4 second for 20mm segment

Now the real time according to the calculation described (if I made a mistake again I'm sorry, but I have it in an excel sheet and the values below are correct):

0.053 second for 1mm segment (+167%)
0.082 second for 2mm segment (+105%)
0.14 second for 5mm segment (+44%)
0.44 second for 20mm segment (+11%)

I did a print last night which was estimated at 2h30 and it actually took a little over 4hours... so the difference is very significant. Now if you print slower or equal to the jerk value, you should have an actual print speed the same as the current build estimate (beside some minor difference, such as firmware approximation, delay in serial communication, ...)

This calculation can be done while slicing, but can also be done post process on the gcode file... I was suggesting it to be optional in case someone worries about slowing down the process, but it could also be done in background after the slicing, you could start your printing while it's still estimating the time, but I very doubt it would take long, unless you have an insane number of segment. These calculations are trivial compared to the slicing algorithm

I hope I make sense

[CompoundCarl]

Thanks for the extra detail. I checked on a few of my printers, and most of them use a jerk settings of around 30 with XY accelerations around 4000 mm/s. So pretty much all my printers seem to have jerk/accel settings that are 4-5x faster than the ones you mentioned. Seems like stock Marlin firmware also has much higher default values. You must have a very heavy toolhead or something! When I use my values, the time difference is much smaller.

Another thing I noticed is that these calculations assume the movement always starts and stops at the jerk speed. That's going to over-estimate the printing time quite a bit. For example, think about printing a circle. The firmware is smart enough to know that the next move segment on the circle is close to the same direction that it is currently moving in, so it doesn't need to completely stop between those moves. It can keep moving at nearly the same speed with very little slowdown. This is the "look ahead" motion planning that is mentioned in many firmwares.

I would think that you would want to account for this. Otherwise, the time estimate from the software would have a tendency to over-estimate instead of under-estimate.

[ominix]

Thanks for the extra detail. I checked on a few of my printers, and most of them use a jerk settings of around 30 with XY accelerations around 4000 mm/s. So pretty much all my printers seem to have jerk/accel settings that are 4-5x faster than the ones you mentioned. Seems like stock Marlin firmware also has much higher default values. You must have a very heavy toolhead or something! When I use my values, the time difference is much smaller.

Another thing I noticed is that these calculations assume the movement always starts and stops at the jerk speed. That's going to over-estimate the printing time quite a bit. For example, think about printing a circle. The firmware is smart enough to know that the next move segment on the circle is close to the same direction that it is currently moving in, so it doesn't need to completely stop between those moves. It can keep moving at nearly the same speed with very little slowdown. This is the "look ahead" motion planning that is mentioned in many firmwares.

I would think that you would want to account for this. Otherwise, the time estimate from the software would have a tendency to over-estimate instead of under-estimate.

Good point, I willok at this look ahead settings. a Jerk of 40-50 seems very high to me and the acceleration as well, what is your printer? It must have a very strong structure and reduce vibrations a lot to be able to print with such settings. I could print whith higher jerk but I get lower qualiy, of course it depends what I print, I I print a mechanical pieces which is amade fo mutipe straight segment, I can bosst the jert to 20-25 and the acceleration to 2000 it all depends whatI need to print.

Once I know more about look ahead and what it changes, I'll give my results here.

[CompoundCarl]

I was using a jerk of 30 on my printers.

For reference, Marlin defaults to jerk 20 and XY accel 3000
https://github.com/MarlinFirmware/Marli ... ion.h#L592

Repetier also uses jerk 20 and XY accel 3000 by default
https://github.com/repetier/Repetier-Fi ... on.h#L1083

So it seems like these values would be a good starting point for any analysis. A lot of my printers are bowden machines or are rigid enough to handle the higher speeds, so I usually increase these values even more.

[ominix]

I was using a jerk of 30 on my printers.

For reference, Marlin defaults to jerk 20 and XY accel 3000
https://github.com/MarlinFirmware/Marli ... ion.h#L592

Repetier also uses jerk 20 and XY accel 3000 by default
https://github.com/repetier/Repetier-Fi ... on.h#L1083

So it seems like these values would be a good starting point for any analysis. A lot of my printers are bowden machines or are rigid enough to handle the higher speeds, so I usually increase these values even more.

My printer had a default jerk of 20 and acceleration of 1500 (Marlin firmware), but I did notice a big improvement in print quality for display pieces by reducing it to <= 10. In face I changed the X carriage not so long ago, and I went from about 500g to about 150g... I should make acc/jerk/quality tests again.

I haven't had the time to look yet how the look-ahead feature works in Marlin firmware, will keep you posted when I find some time

[pjones]

+1 for increasing accuracy of the print times this way

[dorsai3d]

This does seem like it would take a bit of time to calculate accurately. Maybe they could start with the rough estimate and add in a postprocess button (or automatic background process) that would refine the estimate? I use repetier-server (which does calculate time very accurately using jerk & accel settings) for my printer and it can process this in a reasonable time on a Raspberry Pi, so it shouldn't be too terrible timewise.