wikipedia puts a somewhat different spin on nurbs. see the "use" section of the article, first paragraph.
--- On Fri, 4/20/12, Viesturs Lācis <viesturs.la...@gmail.com> wrote: > From: Viesturs Lācis <viesturs.la...@gmail.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, 3:37 AM > 2012/4/20 Erik Christiansen <dva...@internode.on.net>: > > > > 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". > > > > As discussed previously, converting small lines to arcs is > not a > solution, because of different issues, associated with arcs, > that are > not in xy, xz or yz planes, see Chris Radek's messages in > "nonplanar > arcs" thread. > Nurbs do not have all those negative aspects. They even > provide > additional benefit - they can describe splines and other > nasty > geometry, that is difficult to express even with arcs. And > it seems > that LinuxCNC already is 3D Nurbs capable, so it is not xy, > xz or yz > plane dependable. The only trick is the math to convert from > series of > points to Nurbs. > > > 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.) > > Well, if there are many small lines that create a smooth > arc, then the > "Must be able to come to a dead stop within the current line > segment" > approach sucks. But what to do, if the radius of "smooth > arc" suddenly > decreases or even ends with a sharp corner? Like the > butterfly shape > in that paper I posted link to. > Simply removing "Must be able to come to a dead stop within > the > current line segment" will be disastrous, so some changes > are needed > anyway. I have no idea, what does it take to expand the > "lookahead" > "distance" to several lines or even more. > > > 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. > > This means that some preprocessor would need to be created. > And as You > mentioned, the filter would need to know, how fast machine > can > decelerate, so that it knows, where exactly to put the new > feedrate > value. > > 2012/4/20 andy pugh <bodge...@gmail.com>: > > > > It is relatively straightforward to convert a series of > points to a 3D > > polynomial (a least-squares curve fit will do it) > > > > However, that returns a polynomial, which isn't an arc > or a line. > > Based on the looks of those Nurbs splines, I _think_ that it > is some > kind of polynomial that describes it... > I downloaded the Rhino 4.0 demo version. It has a function > to convert > a mesh of points into a Nurbs surface. I guess that this > means - they > can be converted, but I just have no idea how, because I do > not really > understand that Nurbs math. I tried to draw some splines in > Rhino, but > it did not really help me understand them better. > > Viesturs > > ------------------------------------------------------------------------------ > 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
