You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is necessary to check the consistency of the feed rate on the 3,4,5,6 axis.
It is necessary to understand how the speed should be calculated on more than 3 axes. And check how it is calculated on 3 axes.
The text was updated successfully, but these errors were encountered:
For 3 axes this is quite straightforward - speed is calculated as length of
speed vector in 3D space, i.e. square root of sum of squares of speeds by
each axis. For remaining axes situation is much more complicated, usually
for 4th and 5th axes some base coordinate system is chosen, for example
tied to workpiece. Then it's transformed back to machine coordinates
to obtain resulting speeds for each axe. I never saw mention of 6-axis, so
I can only guess that it can be calculated in similar way.
In fact, I think that there are no big sense to worry about speed
calculation for remaining axes in case of GRBL. By design 4+ axes are
synchronized with 3 main axes. The only issue is that commanded movement
may exceed physical limits of the machine. But this can be handled by
trial-and-error for particular machine and case. After all, we're talking
about GRBL which is not designed to handle complex setups like machines
with 4+ axes and uses some specific optimizations for 3 axes.
If you really interested in proper handling of such hardware, I may share
some (well, a lot) research papers dedicated to this problem, but you
should be prepared to write firmware from scratch, GRBL for several reasons
is not suitable as a base for such project.
It is necessary to check the consistency of the feed rate on the 3,4,5,6 axis.
It is necessary to understand how the speed should be calculated on more than 3 axes. And check how it is calculated on 3 axes.
The text was updated successfully, but these errors were encountered: