I went though this exercise on a vinyl cutter application doing a lot of fine cutting details a few years ago. What I found is that if you want to do a lot of fine work quickly you really need to work on your 3D cam software to do curve fitting on the output.
The only alternative to that is to go with a much higher end CNC control that can grind through the segments, but your money will be better spent on the CAD-CAM end of the process rather than the CNC controller end. I've seen Gcode that has segments a couple thousandths of an inch long and those slow CNC controllers to a crawl. Ask a CNC control maker what they think of that kind of code and they will tell you that it is simply bad gcode. The Cam manufacturer may tell you that the CNC controller should be able to handle whatever garbage they throw at it. But when you think of it, the Cam software provider has the ability to create fitted arcs instead of short segments when they are creating the gcode. Curve fitting to gcode described points really doesn't make any sense. If your gcode output is strictly short segments, chances are your Cam software is junk. Back a couple of years ago I ran some ridiculously large and finely detailed files against both EMC2 and Mach3 and I think the results were similar - and for what the customer wanted to do at the time, both were too slow. Both got bogged down when the segments were too short. At that point it comes down to the number of blocks per second that can be processed. Then of course you need to size your drives and motors to be able to keep up with the required movements and accelerations - which can be severe if you are trying to maintain accuracy at high speeds with short segment Gcode Dave On 3/18/2012 10:30 PM, Youda He wrote: > This is very interesting, we are planning to.start using linuxcnc some time > in near future. We mainly mill organic shapes, such as 3DProcessing scanned > head models, the models start as mesh stl models with million a of small > triangles we would like to mill at fastest possible speed and can tolerate > some error in precision. Do we need to insert g64 on start, or is it by > default start in maximum speed mode. or is Mack3 in this case is a better > solution? > On Mar 18, 2012 7:21 PM, "Steve Blackmore"<st...@pilotltd.net> wrote: > > >> On Sat, 17 Mar 2012 17:28:05 +0100, you wrote: >> >> >> >>> My assumption about Tarjectory planning was based on Anders Wallins >>> message as he mentioned some problem with limited look-ahead, >>> I suppose this affects the shape of the calculated path in some cases? >>> >> Effectively LinuxCNC only looks ahead one line. >> >> > From my experience with 2.4.6 it's poor on arc to line or line to arc >> moves using a parallel port setup with steppers. It's very jerky >> compared to Mach3 with the same settings. >> >> Steve Blackmore >> -- >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> >> > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
