another operation of the specialized gcode text editor: convert the selected chunk of gcode/nurbs to a chunk of nurbs/gcode.
i dont have a good idea of what a nurbs nc file might be like, but whatever it is, it still has to result in more or less programmed machine tool positions. the advantage in such case seems to be more in ease of user manipulating the control code. at the machine level, the actuators are going to move stepwise unless the whole spiel is somehow analog. so the question then is how to parse enormous sequences of linear steps into code friendly sections. g1 is straitforward enough, but too slow because the physical impementation involves inertia. g2/3 improves by implying the g1 to g1 transitions within itself. would there be any advantage to making each physical machine axis into a couple of circular movements, one going along R from 0 to 360 degrees while the other rotates around 2R to make the motion linear? ..a rotary differential movement instead of a linear movement. ..the arbitrary interpolation schemes seem to be limited by the compliance character of the machine movement. maybe the solution is a more fluid machine movement somewhere beyond three orthogonal screws? --- On Fri, 4/20/12, Viesturs Lācis <[email protected]> wrote: > From: Viesturs Lācis <[email protected]> > Subject: Re: [Emc-users] Trajectory planning and other topics from a > EMC(LinuxCNC) newbie (TheNewbie) > To: "Enhanced Machine Controller (EMC)" <[email protected]> > Date: Friday, April 20, 2012, 4:40 AM > 2012/4/20 Michael Haberler <[email protected]>: > > > > 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. > > > > 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. > > > > It seems like I did not express it in a proper way: > My idea was to adjust Ken's suggestion with Nurbs. Basically > it would > be a filter, which would take g-code file with all the tiny > G1 moves > and return the same path, expressed with Nurbs. > User then can save the output and reuse later. > > Michael, all the things You listed to be changed makes me > think that > filter is much easier to do (except the math part). > > 2012/4/20 charles green <[email protected]>: > > wikipedia puts a somewhat different spin on nurbs. > see the "use" section of the article, first paragraph. > > > > Yes, I looked also at the "Construction of the basis > functions" > section and did not get much out of it. Well, I did get > nothing out of > it :)) > > 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
