Overriding feed rate in a subroutine

andypugh wrote:

This just popped up on the mailing list.
The P-number does have to be an integer, but you can program a partial or non-integer number of turns.
If you program a half-turn with P = 1 you get a half turn. If you program a half-turn with P = 2 you get 1.5 turns.

Sound like it is a feature that came for free with the code that executes the G2/G3

So, you need to specify start-point, end-point, and the rounded-up number of turns.

Yes, and it is the 'specific-endpoint' part which I consider 'too strict'. Or more precisely: not the 'specific endpoint' perse, but the methods available to program it. One can do Cartesian coordinates or use polar coordinates with origin at 0,0. That is only easy to wrap your head around in specific cases.
A given radius and angle of rotation also defines the end point. Same is valid for programming the circle center of rotation and angle of rotation.

An example: let's say I want to program a hexagon with rounded corners centered around X=10, Y=15. I can do this in LinuxCNC, no problem. But I need 'workarounds' to do so; calculate Cartesian coordinates and enter them, translate the origin and use polar coordinates, use G10 L2 to rotate the XY plane around Z, etcetera. And it could have been so simple...

On a more abstract level: as a newcomer to the CNC world I find it surprisingly 'hard' to program 'curvy things' in G-code, which is strange because 'curvy' is nature's most preferred form. Even 'blocky' things are given a radius. Look around you; it is hard to find a single object which is made without curves. CAM software seems to face the same problem since 'everything curvy' is approximated using a gazillion tiny G1 segments and an occasional G2/G3. Not that LinuxCNC can change the way the world turns and noboby wants a revolution, but little things such as non-constant-radius arcs might help the evolution.

Offtopic: nice knee-sliding picture