On 10/12/2015 12:44 AM, EBo wrote:
I agree with option #3. The question is what g-code whould be
defined/chosen? How about G78.9 (a generalization of G17, G18, and
G19)?
Hello, I use arcs in 3D a lot.
I use Heidenhain controllers.
They have a feature called 'plane.
It is modal, and tilts the executed XYZ coordinate system
UNDERNEATH the G02/G03. (underneath all motion)
It has 3 parameters. angle about Z, Y & X.
( like yaw pitch roll )
This affects the base transform so all subsequent lines and arcs
are performed on the new plane.
When returning to normal Cartesian, simply set the 3 angles to 0.
Hint: you only need 2 angles, 3 is really overconstrained.
It ___really___ makes programming easy.
All programming is just like you had a trunnion table.
code is like this
work in normal cartesian by default
move to a safe position ( the transform itself causes NO motion
becasue the pivot is HERE wherever that is. so its more like move
to a 'known' position )
work in the new plane with programmed Z motion alligned to normal
defined by the yaw pitch roll (ABC what you like to call them )
un-tilt the plane at some safe/known position
work again in normal cartesian
my 2c
TomP
hope the simple png attachment is ok
On Oct 11 2015 9:35 PM, Robert Ellenberg wrote:
Hi Julian,
As you've discovered, the trajectory planner itself can already
create arcs
in an arbitrary plane. However, the interpreter and canon only
support the
subset that Jeff mentioned. Internally, the TP's circular arc segment
is
defined with a start point, end point, center point, and normal
vector.
Depending on the normal vector, the result is either a circular arc
in the
plane perpendicular to the normal, or a helix with the helical axis
along
the normal vector. It would be possible to support arbitrary-plane
arcs in
linuxcnc if we added interpreter / canon / plotting support, but we'd
have
to decide how to support such a thing in G-code. Here are a few
options I
can see:
1. Extend existing G2 / G3 with an additional mode to interpret (X
Y Z)
as the end point, and ( I J K) as the center point of a spherical
arc (with
no helical component). This is nice because it wouldn't require
any
additional parameters. Unfortunately, as Brian pointed out, it
breaks down
for 180 deg arcs.
2. Create a from-scratch G code that accepts 9 parameters (X Y Z
as end
point, I J K as center, and 3 others for a normal). This would
solve the
180 deg problem (as well as the clockwise / counterclockwise
problem), but
will be a pain to get a valid normal direction. This would make
sense only
if there was an existing standard that CAM or other CNC
controllers
supported, and we wanted to emulate it.
3. Add a G code to specify an arbitrary normal vector for all
circular
arcs (i.e. generalize G17-G19). This would be nice because it
preserves the
current G2 / G3 behavior, and having an explicit normal direction
solves
the 180 deg problem. It would involve a bunch of changes (adding
extra
modal state for the normal vector, and re-writing canon's
arc-processing
code to handle an arbitrary normal).
I'd vote for (3) if anything because it doesn't change existing
syntax, and
it would be easier to write G-code by hand to use it. Still, it's not
something that can happen overnight due to the scope of the changes.
Is
anyone else interested in this capability? It will be a few months
before I
can devote serious time to it, but I'd be willing to take a crack at
it
eventually if there's enough demand.
-Rob
On Fri, Oct 9, 2015, 7:10 PM Jullian <[email protected]> wrote:
Thanks for the replies,
Now, it's sure that a generic 3D arc is not supported by g-code。
But in the LinuxCNC'' codes, it has the following code like:
typedef struct {
SphericalArc xyz;
PmCartesian abc;
PmCartesian uvw;
} Arc9;
is not these codes to implement the generic arbitrary arc??
2015-10-09 21:06 GMT+08:00 Jeff Epler <[email protected]>:
On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
Thanks,Jeff,
no bug, it's my comprehension fault,
What i wonder now is that how the LinuxCNC do a spherical 3D arc
by
G_Code
or by other way?
As far as I know, LinuxCNC's gcode dialect does not allow
specification
of fully generic arcs.
You can get arcs with the normal in the Z direction in G17. In
G18 or
G19 you can get arbitrary mixtures of X and Y in the normal by
using
coordinate system rotation (G10's R value). But right now you
can't get
an arc where the normal has a Z component and an XY component.
I'm not aware of any current project to change this, but it would
not be
unwelcome. One challenge is the gcode syntax: how do you specify
the
normal to be used? I think many of the other layers of code are
prepared to accept arbitrary arcs, though the preview plots may
need
additional modification.
Jeff
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
