On Dec 30, 2013 12:24 PM, "sam sokolik" <sa...@empirescreen.com> wrote: > > Could you explain your 'small gain'? from what I am seeing - you have > to slow down to do a parabolic blend (If I understand it - it is a > read-ahead buster) > > There are paths (like steve.ngc) which would be able to keep the speed > up if there was arc-arc, arc-line blends and you can optimize the path > (depth). And yes - I know it is a lot of work. > > (you are doing a great job - it is very impressive how quick you got to > this point) > What i mean by small gain is more statistical. It seems like most engraving-type g-code is made up of line segments, so the biggest overall gain is from making arc blends between lines, simply because there are so many line intersections. It is true that hitting an arc-arc or line-arc blend is a lookahead buster, though, so it doesn't take much to cause annoying slowdowns like in Steve.ngc.
I'm planning on a little more hardware testing first, but if code like Steve's and Julian's is common, then it looks like blends with existing arcs are a must-have. Even the Stellabee code showed a little bit of slowdown due to the occasional arc , though overall it's a small effect. Does anyone else have example code that shows this kind of slowdown? -Rob ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
