feedrate is still a gotcha for short arc segments on some machine controls. g17 g2 arclength around .005", z change 2" faults the servo system at f20". turns out the feed is also interpolated in one of the three usable control interpolation planes, leaving a coordindated helix out of bounds for the servo system in some cases.
i'm wondering how linuxcnc handles helical feedrates. have not done any experiments, except for a couple of xa feeds that didnt go intuitively. --- On Fri, 4/20/12, Erik Christiansen <dva...@internode.on.net> wrote: > From: Erik Christiansen <dva...@internode.on.net> > Subject: Re: [Emc-users] Trajectory planning and other topics from a > EMC(LinuxCNC) newbie (TheNewbie) > To: emc-users@lists.sourceforge.net > Date: Friday, April 20, 2012, 1:52 AM > On 20.04.12 09:53, Viesturs Lācis > wrote: > > I was thinking about Kenneth's idea: > > > > 2012/4/19 Kenneth Lerman <kenneth.ler...@se-ltd.com>: > > > Is anyone here interested in writing a filter that > takes as input a > > > tolerance (error band) and a sequence of motions > (arcs and line > > > segments) and generates a new sequence of motions > that duplicates the > > > original within the error band? It sounds like > that would be one way to > > > address the problem. > > > > Is there a way to create a filter that would convert > those small, tiny > > G1s into a 3D Nurbs lines? > ... > > > It does not seem to be problem finding formulas on the > web to > > calculate a coordinates of a point on a described line. > But reversing > > that seems difficult. > > Curve fitting to an arbitrary bunch of points is an > approximate art, > AIUI, with tolerance calculation at all points probably > taking a bit of > time. Admittedly, I don't know whether nurbs make that > faster/slower or > easier/harder to achieve algorithmically. But it does look > "non-trivial". > > But isn't the LinuxCNC dictum "Must be able to come to a > dead stop > within the current line segment" unnecessary and unhelpful > when > following a piecewise linear approximation of a smooth > curve? If a curve > of ten thousand linear segments were instead one continuous > nurb (or > whatever), then LinuxCNC would not be expected to stop in a > thousandth > of an inch at any irrelevant point along the single-segment > curve, IIUC. > (That's in fact where the much-desired speed improvement > would come from.) > > If it is impossible to increase LinuxCNC's look-ahead, to > allow it to > see that it need not radically decelerate, then why not put > the > look-ahead in the gcode? Gcode allows Feedrate setting > amongst the > "axes" terms in a G1. Would it not be possible to add a > Gwhiz gcode to > turn off the stopping-within-a-segment hesitancy, and set a > nice fast > initial Feedrate along with the G1. A lower Feedrate setting > would then > be inserted prior to any sharp corner or the end of the > curve. > > Manual insertion of Feedrate tweaks is immediately > available¹. Holding > one's breath waiting for this facility in CAM software is > probably > inadvisable. But it is not a difficult task for a gcode > filter to do > nothing but look for a G1 with a Gwhiz, then calculate the > deceleration > needed to negotiate corners or stop at the end, and bang in > a Feedrate > adjustment. (For the end, just add up micro-segment lengths > until > there's enough decelerating distance, then insert the lower > feedrate. > The gcode filter can look ahead to the end of the longest G1 > list of > points, if system RAM permits, but a few hundred segments > might do.) > > This is engineering, and we're here to make swarf, with > reasonable > accuracy, and optimal speed. I don't think that there's any > extra merit > in a complex mathematical solution. So would something akin > to the above > let us scoot faster over irregularly curvaceous workpieces? > > Erik > > ¹ OK, inserting far enough before the corner to allow > deceleration > distance would entail totting up roughly the length > of the trailing > path segments, or allowing plenty. A gcode filter > would be a boon. > > -- > In all affairs it's a healthy thing now and then to hang a > question > mark on the things you have long taken for granted. > > > > - Bertrand Russell > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it > FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
