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
