I think this is a fairly common problem. There are a number Gcode generators out there that take curvy cutting patterns and turn them into huge files full of short G1 moves. The Gcode generator people expect the machine controller to gobble up the crappy G code and create smooth motions at high speeds.
The one commercial application I ran into was for a vinyl cutter for sign making applications. They wanted to run at 1000 ipm while processing Gcode with segment lengths of a couple of thousands of an inch. It was crazy. Needless to say, a solution was never found. And their machines are still running slowly (the last I heard) due to the poor quality Gcode. Dave On 4/19/2012 11:13 AM, Stephen Dubovsky wrote: > Im aware the 90deg case is currently covered. I was commenting to the OP > who thought about allowing the trajectory planner to run a little faster > than it can see could end badly even with such a common case. > > For 3d profiling CAM usually writes the g-code. I don't know anyone who > would hand calculate tens of thousands of little segments:) As such, I > don't know that its necessarily "poor quality". It has to generate as many > segments as necessary to fit the arbitrary arcs to the specified > precision. Around tight curves, that requires lots of short sections w/ > high changes in velocity. But you have to go slow within the limits of the > machine around those anyway. On the longer smooth arcs, it generates > longer segments (Im using Visual mill pkg in Alibre) so no problem there > either. Are there common CAM pkgs that dont do this well? I guess if I > set the curve fit in CAM to a very small number (currently using 0.001") it > would bog my machine down. > > Like I asked: How big of a problem is this really? I can imagine a Hass > class machine that can hold tenths at high speed could be fed a huge file > w/ tenths arc fitting. Even allowing some small additional error like G64 > P0.0001 I can envision a scenario which might not run at the programmed > feed rate. So I ask again: Are there real world examples of it being a > problem? > > Stephen > > On Thu, Apr 19, 2012 at 9:33 AM, andy pugh<bodge...@gmail.com> wrote: > > >> On 19 April 2012 14:04, Stephen Dubovsky<smdubov...@gmail.com> wrote: >> >> >>> But I see how it might be a limiting factor for a modern Hass class speed >>> machine w/ massive spindle hp and feed rates possible when profiling. >>> >> It shouldn't be a limit on any machine with decent G-code. I am >> describing a problem with poor-quality G-code which is made up of >> thousands of very short line segments. >> There is a constraint to at least touch every segment (I think) so >> your concern about the 90 degree bend is covered. >> >> -- >> atp >> The idea that there is no such thing as objective truth is, quite simply, >> wrong. >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
