On 4/23/2012 2:24 AM, Michael Haberler wrote: > let's discuss terminology for a minute (paths vs gcode segments) > > we have: > 1. linear G-code programs (no oword control structures) > 2. G-code with arbitrary control structures > 3. Some other yet-to-be-invented language for machine control. > > execution of any such program generates a path (sequence of moves), which is > input to the trajectory planner. > > <...> > > So for these features the language really drops out of the picture (although > it might supply parameters to drive operations on paths), which is why I used > the term 'path history'.
As an aside, the choice of language (and the nature of the program written in it) will still determine how much work the interpreter has to do before a warning sign can loom into view in the headlights (to borrow Eric's phraseology) of the trajectory planner. It may not be an issue in developing an architecture, but it may still be a performance consideration. > Any preprocessor-based solution to one of these problems also needs to > generate the path, operate on it, and then regenerate matching G-code (which > will be the fun part of any such venture). Not that my opinion as a bystander counts for much, but I'm acutely uncomfortable with a preprocessor-based solution as the only effort, in part because it annoys me to think of all the work some of us did in the 80s and 90s to make sure IGES and PDES/STEP could pass NURBS curves and surfaces into and out of CAD systems as required in real-world designs like cars, ships, airplanes, and most consumer products. First the CAD system creates them, then the CAM system destroys them, then a preprocessor tries to infer them. Sigh. At a suitable level of abstraction, the same problem exists in the CAD world where people keep trying to convert back and forth between CAD models consisting of BRep, CSG, or other geometric representations and visualization models consisting of tessellated surfaces such as triangular meshes. So-called surface-reconstruction software demands a premium price in today's market. On the other hand, those users who see the need can pursue a preprocessor-based solution now, not waiting for a better solution that may or may not appear at some date in the future. I've never believed in letting the perfect be the enemy of the good. If a better solution does show up in future, so much the better. One can never have too many tools:-) Regards, Kent PS - sorry for my brain spasm over "CRC" yesterday. A nudge from Andy, a new day, a cup of fresh coffee, concentration on subtractive instead of additive manufacturing and I'm back in the right ballpark. ------------------------------------------------------------------------------ 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
