KevCAM – A FlowAlongSrf Rhino Hack for CAM Toolpaths – Part 1

I use a program called madCAM for all my CAM toolpath generation.  I like it very much and in general it works very well for what I do.  Since I only have a 3-axis machine, I have the entry level version which sells for $750.  I found their claim that you could download the program and within minutes be making g-code to be literally true – I think within 90 minutes of downloading I was cutting material.  I do nearly all of my machining by zig zagging the tool path, and that works really well for about 95% of what I do.  Here’s the mill I use:

I don’t want to get too deep into the ins and outs of the mill, because that will be for a whole other set of posts, but as you can see it’s a pretty decent size – the work envelope is about 70″X36″X36″ (x/y/z).  The y and z axis are driven by ballscrews, and the x axis has two pulleys and belts, which is driven by a shaft connected to a gear reduction box.  The x axis is very good, but the y and z axis are truly excellent.  So, I do most of my milling zig-zagging in y, which means the mill travels in the y-z plane across the work, gets to the end of the part, increments in x, and then goes back across the part in y-z.  Here’s a picture that can probably explain it better than I can with words:

I’ve greatly increased the step-over to better illustrate the concept.  In practice I use a 0.5″ ball end mill for nearly all my work and I’ve found that a 0.02″ step-over will produce a fine enough finish that no hand sanding is needed to remove any of the scalloping from that tool.  This toolpath was generated using madCAM, and when you zoom in on it, you can see that the toolpath shows the center of the end mill, not the tip:

And now, for a short digression about how I deal with the edges of my molds.  Looking at the screen shot above, you can see there is a flat surface along the right edge of the part.  If you look at the previous image, you’ll see there is a border around the entire part.  I create these for two reasons.  First, when making composite parts, it’s always best to make the mold slightly oversize, and then trim to final size.  If you make the mold EXACTLY the right size, often times the laminate gets bunched up or distorted at the edge.  So I create this surface at the edge with a 20 degree bevel so that my mold does not end at the end of my part, and those problems happen off the area that I care about.  The 20 degree bevel also makes a very nice visible cutting line when I go to trim my part.  The second reason to do something like this is that it keeps your toolpath reversal – where it turns around from going in positive y to negative y – OFF of your part.  Even with a well dialed in mill, you can often still see these reversals.  Especially when you’re milling at high feed rates, you’re asking a LOT of your mill to do a hard turn around like this – especially if you’re in constant velocity mode.  By having the reversal happen off the actual part, you can often times keep the feed rate high and maintain your accuracy.  Like I said, this is a bit of digression, but you’ll see how it comes back into play later.

This zig-zagging toolpath works really well for about 95% of what I do.  As long as the part can be well machined with a zig-zag, then I’m gold.  I can also zig-zag in x, I find I just have to run my machine a little slower, but I still get the same level of quality.  Let me show you a situation where zig-zagging does not work well:

This is sort of like a half pipe that has been bent around a corner.  The section with the visible isocurves is the part – the perimeter is the trimming flange described above.  I created three toolpaths using madCAM, the first being a zig-zag in y with a stepover of 0.04″.  Here’s the problem:

The portions of the model that are steep and pointed in the y direction get under machined – the effective stepover gets reduced from 0.04″ to more than double that, since it is projecting that linework onto the model from above.   I could try it zig-zagging in x, but that’s just going to shift the problem to the middle of my model.  So another option with madCAM is to use the Contouring mode.  Here’s what we get:

There’s two things I don’t like about this.  First, and frankly this surprised me greatly, but the variation in stepover is even larger!  Also, notice that many of the toolpath turns are on the part – there’s no way of keeping them off of the part.  I’d rather not have those if need be.  So this pretty much leaves me with one other option, which is to use z-level finishing on the entire part.  I’ve intentionally tilted the model a bit askew so that the top is not level in x-y  to show why this sometimes doesn’t work either:

Since z-level finishing machines at one single z level at a time, you can see that there is a lot of time spent moving the tool back to the entry point, so it’s not that efficient.  Also, with something like this, I’ve found that things like the beveled edges don’t end up being very sharp.  Okay, so I think you get the idea of where you can hit the wall with these lower end CAM packages.  To get more complex toolpaths, typically you need to go with a professional CAM package which can cost many thousands of dollars.  Now, if you’re like me, you’re probably going to say to yourself “why should I spend thousands of dollars to simply get the last 5%?”  Really, madCAM works for me nearly all the time, problems like this are the exception, not the rule, so why pay many times what I have into my CAM package just to solve some small issues?

Enter KevCAM:

A few years back, when I was just learning Rhino, I posted on the Rhino message board that I was having some trouble modeling wingtips for airplanes – like the classic tear drop style tips you see on the P-51 and such.  I got in a rather lengthy discussion with this guy named Kevin who clearly knew far more than I did about Rhino, and had some really interesting ideas about how to make the tips.  We ended up talking on the phone for quite a few hours, and when I mentioned that I had a mill he said “you know, I’ve made this open source CAM program that uses the Rhino FlowAlongSrf command to make toolpaths.”  He talked me through a basic rundown of the process, and told me how he’d been using it for high end tooling.  I just kinda tucked that into the back of my brain until I felt like I knew enough about Rhino and had the necessary skills and need for such a thing.  A few years later, now that I’m more up to speed on things, and can clearly see why such a tool would be extremely useful, I had him run me through the process again, and this time a million light bulbs went on in my head all at the same time when I realized just how amazingly powerful this tool is.  Let me start with a few things up front.

1. This is essentially a hack of the FlowAlongSrf Rhino command.  If you don’t understand FlowAlongSrf, this won’t make much sense, so get yourself acquainted with it.

2. This is also a fairly advanced trick – I would not expect people who have very limited experience with Rhino to find it intuitive or easy.  If you can complete the Rhino Level II training then chances are this will make sense to you. This is not a “push a button and make g-code spit out” type of process.  It takes some thinking and ingenuity, but it works very well.

3. It’s really, really cool.  Like one of those “fireworks are going off in my head” kind of ideas.  My hat is off to Kevin for coming up with such a thing.

Okay, so let’s get to it.  Let’s start with the simplest case.  We’re going to build this thing all the way up, but first we have to start small and simple.  So let’s start with just our mold, and not our trimming flange.  That would look like this:

Conceptually speaking, what is it that we want?  Well, ideally, the tool would travel along the isocurves – either in the u or v direction, and then turn around when it hit the edge.  Kind of like a zig-zag pattern, but oriented along the u/v isocurves of the surface.   I’ve extracted a few isocurves in the u direction and highlighted them:

Conceptually speaking, that’s what we want, right?  This is what’s called iso-parametric machining, and you have to pay a lot of money to get it.  Usually.  Or, you can just get it for free in Rhino.  Here’s how – let’s start by making a flat surface next to our mold:

For now, the size doesn’t matter.  Next, run the dir command on both:

Since these are NURBS surfaces, they both have a rectangular topology.  Look closely at the picture above – from a u/v perspective, where is the “origin” of each surface?  Here’s the answer:

Knowing and understanding this is crucial to making this work.  Now let’s make a hatch on our flat surface – you’ll need a curve boundary to do this, so just DupBorder if you need:

Use Hatch 1. Click Set Base and feed it your “origin” point.  Now explode your hatch so that it’s just lines:

Notice that the hatch lines don’t go to the edge of the surface with regards to the y direction.  Here is what you have to know and understand – FlowAlongSrf will preserve the relationship between these lines and that base surface when it applies them to the target surface.  So, since we want to machine ALL of our mold surface, we need to make our base surface smaller.  You could trim the surface right?  Well yes, but then you’d have to run ShrinkTrimmedSrf, because what you might not know about FlowAlongSrf is that it looks at the relationship between the curves and the UNTRIMMED base surface.  It’s easier to just delete this surface and make a new one using Surface->Plane->Corner to Corner.

Now your base surface is exactly the same size as your hatch edges.  This is good.  Run dir again just to make sure the orientation of the surface has not changed.  Now, for the true moment of genius – FlowAlongSrf.  Start the command, and when it prompts you for the objects, select your curves and hit enter.

Now it says “Base surface, select near a corner” – pick your flat plane at the “origin” point.  Then it will prompt you for the target surface – click the mold surface at the “origin” point.  And you get:

Wow!  Okay this is really cool, we’ve got lines oriented along our u/v isocurves.  This feels very very close to what we need, but there’s two things missing.  First, these curves are not joined together.  Okay, well you could do that manually, or you could download this handy little plugin that Kevin wrote called Joiner.  Joiner will put line segments at alternating ends of your lines.  Funny enough, you still need to run Join after you run Joiner, to make your hatch all one continuous curve.

So now your hatch curves look like a zig-zag toolpath.  The second problem is this – if you’re using  a ball end mill, which you would be very wise to use in this situation, you need to define the CENTER of the ball end mill as the toolpath, not the tip.  Remember above when I said that FlowAlongSrf will preserve the relationship between these lines and the base surface when it applies them to the target surface?  Well, we now use that to our advantage.  If I’m using a 0.5″ ball end mill, what is the relationship between the surface I’m milling and the center of that ball?  Well the center of the ball is half of the tool diameter away from the surface, perpendicular normal to it.  So let’s create that same relationship between our linework and our base surface by simply moving our linework vertically up 0.25″:

The relationship between our linework and our base surface is now the same relationship we want between our toolpath and our mold surface.  So, let’s run FlowAlongSrf again and see what we get:

Uhhhh….that sure as heck looks like iso-parametric toolpaths to me!  Really efficient toolpaths at that.  How much did we pay for that?  Right, nothing.  Let’s check to see if the lines are indeed the proper distance from the mold surface for a ball end mill.  Put a 0.5″ diameter sphere anywhere on the linework, and then do an intersection curve between it and the mold surface:

Rhino tells me that tiny little smiley shaped curve is the intersection of the two.  Spot checking around the model, sometimes I get points, sometimes I get tiny curves, sometimes I get no intersection at all.  What this tells me is that offset is very uniform and very close to what it should be.

Conceptually speaking, this is the whole enchilada.  All subsequent posts will be building off this basic concept and filling out all the nuts and bolts of the technique, but I’m sure some of you already have the gears in your head spinning about how you can apply this to your projects.   I’ll be adding at least two or three more posts on this in the coming days, but for now I encourage you to get familiar with the concepts and techniques shown above.

If you would like to download the file used in this post, you can do so here.

5 Responses to “KevCAM – A FlowAlongSrf Rhino Hack for CAM Toolpaths – Part 1”
  1. Mark Calder says:

    Sky, this is excellent information. I really appriciate your posts.

  2. kmckenn says:

    Interesting discussion… Now, if I only knew as much about WordPress Blogging as I did Rhino and CAM/CNC, I’d be a whole lot better off! Hopefully that learning curve isn’t too long…

  3. Gary says:


    Talk about a light bulb going on!!! This is fantastic. Although I use the VisualCam plugin for Rhino for my mold work – I can see this might have some excellent use for something… I’ll have to come up with a project to try it on.

    Thanks so much for a clear succinct description of the process.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: