++On Fri, 20 Apr 2012 09:53:05 +0300 Viesturs Lācis <[email protected]> wrote:
> 2012/4/20 Scott Hasse <[email protected]>: > > It seems to me that the likelihood of fixing all of the methods of > > gcode generation such that they don't generate short line segments > > is approximately zero. Also, it seems that even if a proprietary > > LinuxCNC gcode extension allowed arbitrary plane arcs, splines, > > etc. that the likelihood of CAM packages being able to make proper > > use of that is also approximately zero. > > Unfortunately it seems to be true :( > > I was thinking about Kenneth's idea: > > 2012/4/19 Kenneth Lerman <[email protected]>: > > > > 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? > I do not know, how many people have seen this: > http://158.110.28.100/amst08/papers/art837759.pdf > This paper shows the difference of the machining velocity, which > substantially increases as "better" code is presented to the cnc > controller. > It seems that the version in the paper is 2D Nurbs, but Yishin says > that they have 3D Nurbs in Araisrobo branch. > The only thing I do not get, is how to do the reverse math - describe > a line, if (a lot of) points on it are provided. 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. > > Viesturs Just thinking out loud; usually gets me in trouble. ;-) However: Long before I knew anything about g-code it seemed obvious that any capable machine would be able to use at least a 2nd order polynomial. Some years ago I tried fitting curved sections of a lockplate (think flintlock or percussion). They would fit over distances of one or two inches with a tolerance of +- 0.001 which I think is reasonable since few of us can cut to better than a thou anyway. ;-) Now to extend the above: as long as we constrain ourselves to work external to the machine we are stuck with short segments. (no proof included). However, adding internal functionality to emc in a manner much like G2/G3 I think has merit. a. add nurbs, apparently already done the ara... branch. b. extend G2/G2 to the general case ... ellipse which collapses to a circle when the axes are colinear(?). c. add a polynomial of nth-order. Maybe nurbs actually takes care of the other cases but I'm not at all certain of that. Since those would be calculated by traj the movement for a block of code would be longer and hopefully much smoother; much like the present G2/G3. Unfortunately, I can conceptualize things that I don't have the brain power to program. Darned! Just my tuppence. Dave > ------------------------------------------------------------------------------ > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
