Thanks, i will do some research on the TP codes.
2015年10月12日星期一，Robert Ellenberg <[email protected]> 写道： > 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
