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

I'm deciding whether to work on a LinuxCNC feature and would like to know first whether anyone would actually use it.

Today, when a rotary axis moves together with X, Y or Z, F applies to the linear axes only, and a rotary move on its own runs at F in degrees per minute. On a 4th-axis wrap, where the surface of a cylinder is cut with X and A, the surface speed therefore doesn't match F. The usual workaround is inverse time (G93) from the CAM.

The idea is a reference radius for each rotary axis, set in the INI. For example, `[AXIS_A] FEED_RADIUS = 25` puts A in the feed calculation as if it were a length at 25 mm from its centre. A move of A alone at F100 would then run at 100 mm/min on the surface at that radius, and X with A would run at F along the combined path. Siemens (FGREF) and Fanuc (a parameter) do the same.

Questions:
1. Would you use this, or does G93 from your CAM already cover it for you?
2. What machine: 4th-axis wrap, rotary table, something else?
3. The useful radius is usually the stock radius, which changes per job. Is a fixed INI value good enough, or would you need to set it from G-code?

A short "yes, I'd use it", "no" or "G93 is fine" helps. If nobody needs it, I'll leave it.

 

grandixximo wrote:

The idea is a reference radius for each rotary axis, set in the INI. For example, `[AXIS_A] FEED_RADIUS = 25` 

This is a very bad idea, looks like it was captured from Mach3...
This is what LinuxCNC is good at, it doesn't have a thousand buttons that change the way it interprets g-codes.
Sharing settings between the ini file and the ngc file like this is bound to end in an accident at some point.
However, there are no contraindications to adding a new G or M code that will do what you write about. Then everything will be in one file and there will be no risk of running one program with the settings of another...

Yes got some mixed responses, G93 works for some. The ones who'd like to try, seem to want it as a G-code, which makes sense...

A short "yes, I'd use it", "no" or "G93 is fine" helps

G93 is fine for me


 

"G93 is fine for me" means nothing.
It is one thing when someone uses CAM and is not at all interested in how the g-code is created, and it is enough that it works, and it is completely different when someone writes the program themselves using functions, loops and subroutines.

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.