Processing power issue with current toolpath strategy

I've just started writing an endmill toolpath definition. The strategy seems to be valid, but I'm not sure I can get the accuracy I want without crashing my pc (though I admit I do not exactly know the math to get the surface accuracy I'm looking for).

I'm dividing a circle, which represents the bottom of the endmill, then finding the intersection of SDL lines based on those points (just in the z direction for now as I own a 3 axis machine) and the surface. I then find the highest z point, and interpolate a curve with points using the original xy and the new z values.

I was planning on dividing both the curve and the circles by a length of .001, but this seems to be way too much. I was planning on using a similar strategy for a ballmill, populating the surface of half a sphere with points and finding the difference in length between those and those on the target surface, but that would be a significantly higher number of points.

Do I need a better strategy, a better pc, or am I asking for too much in terms of accuracy?

Thanks for the help,

Justin

Attachments:

Endmill Toolpath.gh, 19 KB

Replies to This Discussion

Permalink Reply by Joseph Oster on July 25, 2017 at 1:29am

And yeah, you could use Anemone to implement iterative attempts to avoid intersection, raising the tool by 'Z_incr' each time, but detecting those intersections can be CPU-intensive.

Here is a "ball mill" tool path using Anemone. The outer loop goes through each of the points on the path, the inner loop tests for intersection, raising the ball by the 'increment' slider value (0.0025) as needed. I tried four different methods for detecting intersection... All very slow, not sure which is best. In some cases, for certain points, it failed by detecting phantom intersections.

Your surface produces some strange results, as seen in the image below. 'Srf 2' is different, convex, one piece ('Sweep 1') and all the balls are basically the same color, indicating very small adjustments if any. But your test surface appears to be composed of pieces that aren't necessarily tangent, producing some odd results.

I tried both standard and "Fast" Anemone loops; hard to benchmark the difference... As usual, most of the development work on this was done at "low resolution", meaning a large value for 'Curve Div Length' to reduce the point count. There is a yellow group to select just one point instead of the whole list, which is very helpful using Anemone standard loop to see what it's doing.

NOTE: As written, this code does NOT WORK with offset paths. A third, outer Anemone loop is needed to loop through multiple paths if that functionality is desired.

Attachments: