Overriding feed rate in a subroutine
21 Aug 2013 16:11 #37914
by andypugh
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.
So, you need to specify start-point, end-point, and the rounded-up number of turns.
I think the reason it is like this is that it ensures that the tool always finishes in an explicitly-programmed position.
Replied by andypugh on topic Overriding feed rate in a subroutine
Floating point P parameter. It would be nice to be able to easily program a partial circle (arc) starting from the current position, rotating with IJK coordinates as center. Currently P must be at least 1.0 (and probably an integer; didn't check that yet).
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.
So, you need to specify start-point, end-point, and the rounded-up number of turns.
I think the reason it is like this is that it ensures that the tool always finishes in an explicitly-programmed position.
Please Log in or Create an account to join the conversation.
21 Aug 2013 19:09 #37924
by DaBit
Sound like it is a feature that came for free with the code that executes the G2/G3
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
Replied by DaBit on topic Overriding feed rate in a subroutine
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
Please Log in or Create an account to join the conversation.
Time to create page: 0.279 seconds