On Sat, 30 Jul 2011 13:30:25 -0500, you wrote: >I remember that the developers at one point changed the way g64px.xxx worked >so that it actually converted arcs to short line segments so the combining of >line segments worked for the arcs also. > >but that is just a vauge recolection.
An odd solution, maybe that now explains the following "G64 P- Q- it turns on the "naive cam detector"; when there are a series of linear XYZ feed moves at the same feed rate that are less than Q- away from being collinear, they are collapsed into a single linear move. On G2/3 moves in the G17 (XY) plane when the maximum deviation of an arc from a straight line is less than the G64 P- tolerance the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end). those lines are then subject to the naive cam algorithm for lines." However, It still doesn't explain why the huge slowdowns on just G64 moves! "G64 without P means to keep the best speed possible, no matter how far away from the programmed point you end up." Just ran it again in Mach and EMC, in Mach commanded feed was 3600 mm/min, it never dropped below 3500. In EMC it only reached 3500 or over on ten short occasions or so throughout the whole file. The rest of the time it was accelerating and decelerating wildly and never getting to anything like maximum velocity, despite both having same motor tuning parameters and pulse widths etc. Clearly - it's not doing what the manual says it does in G64 mode. Something for the developers to look at. Steve Blackmore -- ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
