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
