Would you use a feed rate for rotary axes in mm/min (surface speed)?

Hello,

In my view, the decisive factor is whether or not kinematics are taken into account:
without kinematics, values ​​are specified in angular units; with kinematics, they are specified in linear units, as the lever arms are factored in.

Having had my machine slow to a crawl because it applied "in/min" to "degrees" (usually by accident, I use G93 most of the time), I would like an option to "do better".  Some ideas:
* Use radians instead of degrees if you have to use them at all, since those are much closer to linear distance.
* Scale by the WCS Z coordinate to figure out "actual" circumference/distance
* Specify the machine location of the rotary in the config, like Y=10 Z=-3 (which implies it points along X) and calculate circumference based on that
* manually specify some scaling factor

djdelorie wrote:

Having had my machine slow to a crawl because it applied "in/min" to "degrees" (usually by accident, I use G93 most of the time), I would like an option to "do better".  Some ideas:
* Use radians instead of degrees if you have to use them at all, since those are much closer to linear distance.
* Scale by the WCS Z coordinate to figure out "actual" circumference/distance
* Specify the machine location of the rotary in the config, like Y=10 Z=-3 (which implies it points along X) and calculate circumference based on that
* manually specify some scaling factor
 

These are mathematical heresies.
The whole problem is that it is in no way possible to convert an angle into a length.
They are simply concepts from different categories.
However, you can convert an angle into an arc length if you know the radius.
Since the radius is not listed anywhere in the g-code, it would have to be cleverly specified there.
In my opinion, a new G or M code would be best for this for three reasons:
1. As I wrote earlier, everything would be inside one file, which would eliminate the possibility of a nasty mistake.
2. The G or M code could be used many times in one file, because many diameters can be machined in one piece of material.
3. If someone didn't need it, they wouldn't use it and wouldn't have to be surprised that something was done differently than expected.

G93 works for me, but I just wanted to say a huge thanks for all your work.  I've been trying to keep up with what you're doing with the s curve stuff and the 5 axis tp work.  It's well beyond the level I could contribute anything, but I'm excited to see all the progress.  

tuxcnc wrote:

"G93 is fine for me" means nothing.

 

"G93 is fine for me" means

Inverse-time feedrate generated by CAM is sufficient for my needs.

The OP indicated a simple response would be sufficient.  I gave one of the requested responses.

If your provocative post was not directed at me, disregard.

And, as usual, thank you grandixximo for all the work on LCNC.

These are mathematical heresies

Sure, but as I noted, sometimes I forget to use G93 and happen to include an A move in something innocuous, and it would be nice if the resulting motion was at least within an order of magnitude of correct instead of the default of stupidly slow.
Also, my third option gave the machine the math it needed to calculate the correct speeds.