-
Notifications
You must be signed in to change notification settings - Fork 91
Jerk acceleration
grblHAL translates g-code into motion using a multi buffer system.
The first buffer is the characterbuffer, that stores the plain text g-code commands received from the sender. After that the code is translated into movement blocks. Each line results in one block and is considered to be a trapezoidal movement, which means it generally consists of acceleration, cruise and deceleration.
[graph of movement]
These blocks then get divided into smaller segments that the stepper interrupt loop can check out to convert into physical steps.
[picture of segments]
The problem with trapezoidal movement is, that physics doesnt like sudden jumps to full acceleration values. Mass and with that inertia are resisting the movement at first. This generates are "torque wall" at the start of every movement that has a direction or speed change. Jerk acceleration smoothes out that wall so the machine starts with low values of acceleration to get things moving before starting to ramp up to the max acceleration value.
To implement this easing into the movements into grblHAL the current implementation does a few things.
[picture of same graph as above with jerk smoothing]
First: The acceleration value that the movement segments use is dependent on the segment that came before it.
Second: A proper jerk acceleration also demands that we not only ease into the acceleration ramp but also out of it. Ideally acceleration should be zero or very close to zero when reaching the end of the acceleration / decelration part of a movement block. To achive this the segments now also calcualte the remaining distance to the end of the acceleration ramp and start decreasing the aceeleration when the distance to the end of ramp is less than the distance neede to get to zero acceleration.
Third: Since jerk acceleration takes longer to execute due to ramp up and ramp down of the acceleration at the start and end of a ramp we need to adjust the acceleration value the planner uses so it still calculates reasonable entry speeds, exit speeds and time's to decelerate/accelerate. There are two general cases which we'll call the slow speed regime and the high speed regime:
-
slow speed regime: incomplete jerk ramp (max acceleration is not reached)
-
high speed regime: complete jerk ramp + time at max acceleration to reach programmed movement rates
[picture comparing time needed of trapezoidal and jerk, showing the "effective" acceleration]
If jerk acceleration is enabled, each individual machine will need to be tuned for all three of the max speed, max acceleration and jerk values. Max speed and max acceleration will still work as with the traditional trapezoidal motion planner in giving quicker movements. Adjusting jerk for higher values will give a more aggresive acceleration, lower values with give a more smooth movement. The general recommendation is to start with a jerk setting of 10 times the acceleration and tune from there for the specific machine until you have found a desireable motion profile.
Note: Due to the segment implementation we're not doing a smooth ramp up or down. The profile generated is quantized and most accruately described as stairsteps up to the maximumg acceleration value. For our usecase this is usually more than accurate enough.
[picture showing the quantized acceleration steps]
grblHAL has an additional compiletime option that influences jerk acceleration more severly than the original trapezoidal movement planner: ACCELERATION_TICKS_PER_SECOND.
As the name suggest this setting governs how long the individual segments that the movement blocks are broken down to are.
With the default value of 100 ACCELERATION_TICKS_PER_SECOND the segments are 10ms long. Higher values will have dramatic effect on the jerk calculations giving more fine control over the ramp and enabling higher working jerk settings.
Since the jerk steps over the segments are quantized it is possible to set the jerk value so high that you basically end back up at a trapezoidal movement since it only takes one segment to reach the max value of acceleration. This should be avoided.
[picture of same acceleration ramp with 100 ticks, 200 ticks and 500 ticks]
Note: If you change the ACCELERATION_TICKS_PER_SECOND setting you will also want to adjust the SEGMENT_BUFFER value to a higher value so the segment generation code doesnt have to come back to it all the time. 40-50ms of segment buffer time should be considered the minimum to give the other parts of grblHAL time to complete their tasks.
These settings can be found in the config.h file of grblHAL.