let me point out that the underlying issue is the current line-by-line G-code interpretation model (aka 'limited lookahead')
any view or optimization beyond that scope necessarily involves some path history which has been addressed by introducing 'queues' at considerable extra complexity; for instance naive cam detection (the chained points queue) or offset curve computation (queued canon). 'queue' is a bit of a misnomer - these are basically ad-hoc polylines extending beyond a single gcode line to retain history, on which some operation (NCD, CRC) eventually is applied. to stay within that model, for instance the polyline-to-NURBS conversion would require yet another ad-hoce path 'queue'. The other option is to go the preprocessor route as Ken proposed. I can imagine a different approach: drop the line-by-line interpretation model, and switch to a mode where the interpreter would run either to completion or the next queue buster (tool change, probe, hal pin read) autonomously, and generate a path model internally. This means basically 'lookahead to the end of program or the next queue buster', which results in one or several polylines. Transformations like the ones discussed here, but also NCD and CRC could be done on a single path data structure instead of various ad-hoc structures, before generating any canon commands. I would think that moving these operations into the interpreter would also benefit regression testing - since several key operations like NCD, CRC and offsetting is currently wrapped into emcanon.cc their results cannot fully be subjected to regression tests with rs274 whose canon layer doesnt have these features. Downsides I can think of: More memory is needed to retain the path. The interpreter state model in task needs to be reviewed to cope with this approach. Also, I use the term polylines a bit sloppy, it's not just lines and arcs but also about probe and tapping. some problems cannot be addressed with a deeper interpretation-time path model like blending, which must be done at runtime due to external inputs like feed override which can impact on the actual path. - Michael Am 20.04.2012 um 08:53 schrieb Viesturs Lācis: > 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 > > ------------------------------------------------------------------------------ > 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
