ok 1.4 is correct I was approximating
it will be sqrt(100² + 100²) / 100 mins
+Peter van der Walt link is here http://blog.wolfman.com/files/firmware-4axis.bin and notes are here… https://github.com/Smoothieware/Smoothieware/pull/1055
The notes must be read.
My guess: may need junction deviation on A to prevent slowdowns
junction deviation is only applied to XYZ I am afraid
also I may be incorrect above I also think only cartesian speed is calculated for XYZ not ABC ABC are auxiliary moves and follow the primary axis XYZ so my first post was correct, A is not part of the cartesian movement. Thi smay be incorrect and may need to change but that would break a lot of other things especially 3d printing.
Could we have a config file setting that makes A cartesian?
it would be a lot of work I am afraid. It will
break a lot of other stuff. You will need to convince me and arthur that it is actually an issue. I don’t think it is actually, but am willing to be proven wrong. I have in the past wanted a way to designate which axis are primary and which are not and I did that in another firmware I wrote which was inherently n-axis. However smoothie is not well designed to be true n-axis. The ABC PR is about 90% of the way there.
OK, I’ll compensate F and S in CAM for every move. What do I do to set speed when only A moves? Will the laser adjust during A’s acceleration when XYZ are still?