#3 <- facebook style "like" --- On Fri, 4/20/12, Kenneth Lerman <kenneth.ler...@se-ltd.com> wrote:
> From: Kenneth Lerman <kenneth.ler...@se-ltd.com> > 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, 6:06 AM > On 4/20/2012 4:52 AM, Erik > Christiansen wrote: > > 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.) > The job of the system is to follow a path *exactly* or > within specified > limits. In the usual case, the limits are zero. That means > if there are > two non-colinear line segments, a machine with finite > acceleration > machine *must* stop at the end of the first. This causes two > types of > problems: > 1 -- The system is slower than it could be > 2 -- Uneven speed causes undesirable artifacts > > Let's consider the alternatives: > 1 -- Change the CAM system so that it generates better code. > Since there > are multiple CAM systems over which we have little control, > this us not > feasible. > 2 -- Modify LinuxCNC so that it can follow a gcode path > within a > specified tolerance at a higher, more consistent rate. > 3 -- Provide a filter (whether integrated with LinuxCNC or > completely > separate) that convert bad paths to good paths using a > specified tolerance. > > Given a standalone LinuxCNC compatible parser, I suggest > that #3, would > provide a basis for experimentation and development that > could later be > more closely integrated into Linux CNC. > > Regards, > > Ken > > > > 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. > > > > ------------------------------------------------------------------------------ > 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
