On Sun, Dec 1, 2013 at 6:20 PM, andy pugh <[email protected]> wrote:
> On 28 November 2013 18:09, Robert Ellenberg <[email protected]> wrote: > > > There are a few cases that I could easily tackle, such as detecting > > tangents between line-arc and arc-arc pairs. I'd have to add a few steps > to > > tpAddCircle and tpAddLine, but it would be straightforward. In general, > > adding a tangent arc between existing arcs is complicated, and might make > > more sense to do in user space. > > Isn't a line-line blend just a special case of an arc-arc blend with > infinite radius? > Yes, that's true. Unfortunately, trying to implement a more general method is more complex to actually code in C, especially when we can't easily pull in linear algebra libraries in the kernel. I think in principle the construction of a blend-arc tangent to two > existing arcs is fairly simple, at least geometrically, the blend-arc > centre is at the point where the straight lines between the blend > start point and the original arc centres meet. I suspect that the tricky part is determining the point on the arc to begin and end the blend? I agree if you can assume that the arcs and lines are co-planar. The geometry is easy to grasp and construct. Unfortunately, solving for the radius that satisfies these constraints (and a blend tolerance) is tougher than the line-line case. As part of the proposal for this method, I went through the math for each case: - line-arc blends are messier in terms of setup, but the solution ultimately boils down to a quadratic constraint equation. I prototyped this in octave, so I'm at least confident that it's possible. - arc-arc blends are more difficult, in part because the relationship between the center location and the radius depends on the radii and direction of the original arcs. My paper math suggests that you can solve this problem with a set of 3 linear equations, but I'd need to prototype this in octave to say for sure. Once you've solved for a radius, it's basically substitution into the other equations to get the center and intersections. I'd be very curious to see a part program that had a lot of non-tangent arc-line and arc-arc intersections (other than the torture test G code, that is). If these cases are not as rare as I thought they were, then it would make sense to get started on them sooner. The other factor here is that the combination of circular arc blends and trapezoidal velocity profiles is not really an ideal solution as machining speeds increase (because of discontinuous acceleration). I suspect that it would be wiser in the long term to get NURBS and limited-jerk motion working. Due to the extra processing involved here, I'd prefer to wait for this step until we can overhaul NML and move more of TP into user space. -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=84349351&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
