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
