TinyG
TinyG copied to clipboard
synthetos
Direction dependant acceleration settings
From what I've read about grbl and TinyG, they now both have independent acceleration limits. However, all acellerations are the same in both directions. This may not be physically optimal.
Even on a non-cutting move there is friction that fights acceleration and aids deceleration and motors probably don't have the same breaking and accelerating torques.
When cutting it is even more asymmetric.
Plus Z, in the traditional XYZ set-up has a heavy bias downwards and the motor has to work a lot harder to raise than lower.
This all means that each axis has to be set up for worst case conditions, which is less than optimal performance. I would imagine that this degrades Z performance , which is typically rather slow anyway.
Are there any thoughts on having difference acceleration configs for each direction?
I think the far term goal is to have programable profile curves, for reasons you outlined here.
jogging is another example where you want asymmetric acceleration. right now it's largely a hack.
--mikest
Sent from my iPhone
On Nov 26, 2014, at 3:55 PM, J-Dunn [email protected] wrote:
From what I've read about grbl and TinyG, they now both have independent acceleration limits. However, all acellerations are the same in both directions. This may not be physically optimal.
Even on a non-cutting move there is friction that fights acceleration and aids deceleration and motors probably don't have the same breaking and accelerating torques.
When cutting it is even more asymmetric.
Plus Z, in the traditional XYZ set-up has a heavy bias downwards and the motor has to work a lot harder to raise than lower.
This all means that each axis has to be set up for worst case conditions, which is less than optimal performance. I would imagine that this degrades Z performance , which is typically rather slow anyway.
Are there any thoughts on having difference acceleration configs for each direction?
— Reply to this email directly or view it on GitHub.
The z-axis would seem to be the most affected and luckily to easiest to problem to address.
Since, without knowing the weight of the mechanical elements, we still know that bias is the acceleration, it would seem near trivial to add a fixed offset of 9.81 m/s^2 to the Z axis calculations.
Since it is the upward motion that the user will find starts skipping first, this will be what determines the configeration settings. However this will unnecessarily slow down the downward, non-cutting z movements.
This may help sharpen up performance on some operations.
For x and y, I would not expect the carriage bearing friction to be significant but a lead screw with anti backlash nut may well be, especially at high displacement speeds. Unfortunately this is not a fixed acceleration but is reasonably easy to calculate from a fixed configuration value for friction.
User could configure the axis so that the acceleratoin and deceleration motions start skipping at about the same settings.
As TinyG moves to M3 Cortex hardware, these more complex calculations would not have a significant hit.