## Slow to slice

Thursday, February 28th, 2008 at 11:33 am

I spent over a week on a report that the Z-slicing was too slow. In particular it was five times slower than Machining Strategist. As I’d authored the code in that product back in 1994, and there was no evidence of substantial change, this wasn’t good enough.

Here is a Z-slice of a wobbly test surface.

Performance seemed okay when we first looked at it. The problem was most acute for very small tool diameters. A common function the Danes like to use in their machining algorithms is Silhouette Boundary. For this we define a very tall tool with a tiny diameter and ask for a Z-slice at height below the lowest point of the model. The tool only touches on its shaft and the result is exactly the shadow of the entire model, offset outwards by the shaft radius. You can offset this contour inwards to reach the desired result.

The silhouette boundary is used in HSMWorks to limit the extent of parallel passes machining. I can’t see the point of this, because it means you don’t machine the extent of the surface depending on its slope at the edge. For example, consider the convex hemisphere. The silhouette is a circle. Machining with a ballnosed tool whose central axis constrained by this boundary means you miss the edge by slightly less than the radius of the tool. If you want to machine all the way to the lower rim you have to offset the silhouette outwards by the tool radius, and then the boundary constraints will put the tool right on the limit at the tangent point of falling off the edge.

This is where it gets nasty.

Because the cut-off contour is on the exact margin where the tool drops off the model, half the points will fall off, and half the points will stay on. That’s the nature of using a curve along a line of discontinuity, and it has nothing to do with the precision; it would still happen if you were splitting electrons. If the Z-low plane is some distance below the split line of the model, then this boundary will produce a horrible zig-zag mess of toolpath ends at the edge. The best way to clean this up is to discard all line segments where one end makes contact with the Z-low base plane.

This works, and the beautiful thing is that the “clean-up” stage is so effective that you don’t need the silhouette boundary in the first place! All you need are parallel passes within a bounding box, and then you discard all toolpath motions that are in contact with the base plane to give a result that is as-if you trimmed it to a tool-radius offset silhouette boundary, only better.

The best way to fix something is to argue that it doesn’t need to be fixed.

This didn’t wash. They also use these boundaries for constant scallop machining. I had to look harder.

The Z-slice function is based on the creation of a slice for one triangle at a time, and using an area model that can very quickly find the union between these single triangle slices. This merges to create the contour for the whole part. In Machining Strategist I did it for a whole triangle at a time, which meant that there were duplicate calculations for these single triangle contours according their shared edges and points. In HSMWorks I tried to optimize out this duplication by separating the triangle into its seven components (1 facet, 3 edges, 3 points). However, by applying the facets last after the edges and points, I created an intermediate stage where the area model was highly fragmented (and therefore slow) before all the triangular holes were filled in. This was particularly bad when the tool diameter was smaller than the average triangle and could fall through.

Simple answer: rearrange the code to change the order of the parts.

It improved it a bit, but still didn’t make it fast enough.

After a few more days looking at it I found that someone had altered the size of the bucketing of the surface. The bucketing is important so that for each component of the area model (it’s composed of fibres, as seen in the skeleton model below) you don’t need to apply all the triangle components from the whole model, but just the ones in the local area.

This stage, which I think is known as “preparing the surface” in the HSMWorks task manager, was taking too long to execute, so someone had widened its resolution to “speed it up”. This wasn’t very helpful because it slowed everything else down, including my Z-slicing routine.

Well, at least that got to the bottom of that. There is an optimal value for the bucket width so that the sum of the time to generate the buckets and the time for the Z-slice is minimized — and it had been set far from optimal.

This then becomes another thing on the list to look at first when I get the next complaint that it is not running fast enough.

Theoretically, the algorithm should be running faster than the version in Machining Strategist because it is the same but more developed. In practice I don’t know, and I am not very interested.

Generally, the programmer only hears about it when the code is running more slowly than the rivals; nobody bothers to mention it when it is running much faster. In this world, when a programmer does produce something significantly faster because they immediately get used to it. Instead it’ll be the programmers in the other companies who will get hassled about it, while the guy responsible for producing something efficient has no idea of the grief he has caused.

That is, until he quits and works for one of those rival firms and his earlier work is used as a stick to beat him.

### 1 Comment

• 1. Anders replies at 8th March 2008, 5:46 pm :

Hi Julian,

I think I can see how the z-slice algorithm would work for one single triangle. It’s kind of like drop-cutter, only now you push the cutter sideways into contact with the triangle?
That must mean you first choose some points/directions along which to push the cutter into contact with the triangle?

It would be great if you could write some more on the area model used to find the outermost slice of all the single triangle slices. That’s probably the key algorithm for z-slice, and I don’t understand it yet.

I haven’t done very much with the open-source drop-cutter algorithm I coded, but I think it’s a first step towards open-source CAM to at least make rudimentary working algorithms available somewhere. So I’d also like to understand and code a z-slice once I understand how it works.

regards,

Anders Wallin

#### Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>