## Five axis theory before flying

Saturday, August 17th, 2013 at 6:02 am

Just to show willing, and because it’s not working out as effortlessly as I’d hoped, here are some notes on my approaches to five axis theory.

One classical approach is to create a 3-axis toolpath for a ball nosed cutter ignoring the shaft. Then work out a sequence of tilt angles at each point along the toolpath so that the shaft and holder doesn’t collide with the part. The actual cutting tool is invariant to the tilt because it’s a sphere. I made an adequate implementation of this last year.

Another common approach is to create a path in the part surface that is to be the tool contact point and then derive a tool position and tilt from this a la single surface machining. There’s a similarity between this and the first approach in that the fulcrum for the tilt is the contact point at the surface of the tool rather than at the centre of the ball.

I shouldn’t need to go into why deriving a toolpath from a sequence of contact points is an epic fail, having dispatched this as a viable option for all but the simplest, most unrepresentatively unrealistic, yet intuitively compelling cases back in 1994. It’s daleks and staircases. Folks who believe it can be done either haven’t personally tried to make it work, or, if they have made it work will most likely have debugged their code into a completely different algorithm.

For a long time I believed general five-axis could be done by a sort of drive surface projection. This is a generalization of 3+2 axis machining, where the drive plane is tilted from its usual horizontal configuration.

A drive surface is a surface of some description with a vector field in it (often the perpendicular vector to make the defining it easy) against which you run everything as though it were 3-axis machining.

Whereas the fundamental function in 3-axis machining is:

```z = DropCutter(x, y, cuttershape, partsurface)
-->[toolposition]  (x, y, z)
```

this one is:

```d = ProjectCutter(u, v, drivesurface, toolshape, partsurface)
-->[toolposition]  drivesurface_pos(u, v) + drivesurface_vec(u, v) d
```

which can be derived by:

```calculate transform T such that:
T [drivesurface_pos(u, v), drivesurface_vec(u, v)] = [(0,0,0), (0,0,1)]
then:
ProjectCutter(u, v, drivesurface, toolshape, partsurface)
= -DropCutter(0, 0, cuttershape, T partsurface)
```

This all seems great because you get to re-use your functions from 3-axis machining and, if you equate the u,v in the drive surface space to an x,y in a different place, you can potentially reuse the some of the complex algorithms, like pencil and scallop.

For some reason, I never quite got round to implementing this approach, because I knew there was a catch.

The catch is that your toolpath gets shredded into domains with different cutting directions wherever the projection lines cross before they reach the part surface. These domain boundaries will segment the cutting regions unnecessarily and create artifacts all over the place.

So I decided that I need to model the tool surface — the surface of tool centre points when it is contact with the part. This is quite tricky, but I’ve faked it for one particular example of an impellor, and I am now experimenting with different tracking algorithms around and within this surface — none of which have been wildly successful. In the long term I’d like to implement something akin to the adaptive clearing strategy within this surface to get those swirly swirly motions.

I’m not there yet. I may have taken too many short-cuts with my tool surface model which is a little too coarse and facetted, but I don’t want to program it properly unless I know I can make something that works, or I’ll have another pile of slowly rusting half-completed software machinery left there in case I can find another application for it, which I won’t because by the time I do I will have forgotten how it worked. Fakes are piling onto fakes; at some point I have to take an act of faith and knuckle down and do some of this properly.

In case you’re asking, yes it was another very nice flight yesterday of an hour and a half. This was the first time there were other hang gliders apart from me on the Loser takeoff. I spent the entire time getting chased around the sky towards by a T2 who kept joining me in my thermals. The air is big. You get dreamy. Then someone is closing in on you at 60mph. Eeeek! I went away to another mountain with decaying trees almost getting sucked into a cloud, and then eventually fell down into the the valley beside the rusty mountain where I struggled to maintain altitude between a farmhouse and the forested slope above me before bailing to the usual landing field behind Hilde’s.

Didn’t get much sleep last night as Bad Aussee’s finest and then some were out there pumping water from the river miles up to hill to a barn fire since three in the morning. No worries. Nothing a bit of airtime can’t sort out. Becka possibly arrives back at the campsite today after seven days on someone else’s caving expedition. I’ll leave her with the bike so she can go and get the car because I’m not going to wait around just to drive someone to a cave, which is an endeavor that is not time critical (it’s been the same for a million years, so a couple of hours won’t make a difference). Folks round here don’t think this is a good plan, but with an cave-time vs air time-ratio of ten to one between us, I deserve more.

### 1 Comment

• 1. Tony replies at 23rd August 2013, 9:45 am :

Ha the joy of 5 axis machining.
I was in a company some time ago, they were workNc customers and only had 3 Ax software, but the machine was full 5 ax and huge, they had programmed to ball centre and while the toolpath was cutting the part (XYZ movement) (a full size sports car) the operator was revolving the head around B & C with a handwheel to ensure the head missed some of the machined features, it was not moving fast, but was also very impressive