Bernhard Kubicek wrote: > > However I ran into some problems with general scaling operations. When > multiplying all coordinates by large factors( e.g. 25.4 for mm->inch) > also the arc radiuses and I and Js, axis complains that the radius is > to some very small extend different. > I even tried to recalculate the J values by geometric operations based > on the old and new position and the i. > Also outputting more decimal digits did not solve things, at least in > my feable first attempt. > If the original (inch) file has precise numbers, like a diameter of 2.5 inch and a radius of 1.25 inch, then you need to preserve the accuracy of the numbers, in this case the arc endpoint and the increment to the center. I can easily see how this can cause a problem when changing the scale. Maybe the best approach is to convert IJK increments to R words. You can't get a mismatch between radius and endpoint if you use the R word form of an arc move. > > If there is some more time, I will also need to split an arc into > segments, to have independent x and y scaling. Is there a way of doing > this, without slowing the trajectory planner, e.g. by specifying that > it may be allowed to round small-angled "corners" it the moves, or > using G0 with a lower "Jog-speed" for cutting)? Yes, this is the G64.1 Pxxx, where the P word describes the tolerance for line segment deviation. (I'm not explaining this well, I think the manual does better.)
Jon ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
