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)?
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
