5 Axis CNC router spindle collision simulation

I am trying to build a tool to simulate the position a 5 aixs cnc router spindle to avoid help collisions when programming/machining difficult shapes. (See image 1).

The CAM software that we use only simulates the toolholder and not the actual spindle.

The way I am initially approaching this is to draw a surface in the area to machine in rhino and input this surface into the definition. (see image 2) The spindle is then orientated to this surface, (see image 3) and I can then move and rotate the surface to find the best angle from which to machine the area without a collision. (see image 4)

My simple GH definition is rather crude but already proving invaluable to me for this type of work and so I would like to develop the tool further.

Ideally, I would like this definition to be used through custom toolbar and button that I produce for Rhino. This would mean that the rest of the team who are not familiar with grasshopper could easily use it.

I have made a few simple tools using grasshopper player linked to a custom button which has worked well, so I was thinking this may be a good way to go?

I have produced a basic GH definition to start which is very simple, (see attached GH file)but I have encountered a few initial problems.

The main issue is when running the definition through grasshopper player in rhino I can’t select, move and rotate the surface whilst the definition is active.

Is there a way for the preview of the spindle to be visible whilst you move/rotate it to the right position then click to bake it into rhino?

I would like the work flow to be:

  • Prompt-Select target surface.
  • Prompt-Select the tool. I will make a selection of my current tools and toolholders to choose from. This is not in the definition yet but simple.
  • manually rotate/move the surface to the optimum position whist simulating the spindle movement.
  • Prompt-Happy to bake?
  • Spindle is baked to current layer in rhino

Another issue I have encountered is the simulation fails when the A axis is exactly 90 degrees. I understand why this happens and have made a crude work around which is not great (see image 5) and I was wondering if anyone could think of a better way of finding the rotation angles of the a axis and c axis that would work better?

I have a similar problem with the C axis angle flipping 180 degrees when the A axis angle is larger than 90 degrees. Again, I understand why this happens and have a similar crude work around to fix this. (see image 6)

You will also see that I have a cut off when the A axis angle is greater than 120 degrees as this is the machine limit.

I find this an interesting exercise and I would be very interested to see how other people with a greater understanding of grasshopper than myself would approach this project.

Hopefully someone can offer a more elegant approach to this than my crude attempt.

5_axis_sim_003.gh (171.8 KB)





image 5

1 Like

Nothing here to to help avoid collisions. Cool animation over a bumpy surface though.

I think an easy solution might be GH Remote, that would allow to publish a “bake” button, and continuosly read the position of your “destination surface” using Geometry Pipeline
but it would mean that this GH definition is open in background (I mean, you open GH, open this particular definition, and then you can also close GH if you want as long as you don’t load a different definition):

Thanks alot I this will be useful of all sorts of things. I didnt know about GH remote.

1 Like

in order for GH to run in background and do as little interference as possible with the user, one way could be the Geometry Pipeline thing mentioned above

it sort of continuously reads geometry from the opened Rhino file, and you can filter data based on layer and geometry type

for instance, setting to the following would make GH read only Breps and Surfaces in the Layer named Orientation_surface (you can double lcick on Layer and Name to type)

because the definition won’t work under GHPlayer anymore, also the Context Bake component should be swapped for something that can handle direct baking with a button… any kind of boolean baking will work, also a Python or C# script can do that

your definition flows well: by just grafting the initial input you can easily handle lists of multiple “orientation surfaces” seamlessly:

if you are not happy to see all the spindles, one for each different orientation surface, there are some tweaks you can do to the output of Geometry Pipeline based on Rhino visibility, so if you hide one of those orientation surfaces in Rhino, it will also not calculate its spindle in GH

for instance, there are sets of component in Rhino 8 that gives you Rhino attributes like Visibility, so if you hide it you’ll get a different value and you could filter surfaces based on that (also the plugin Human has a Rhino Attributes component where “Visible” is reported as a True/False value to allow for direct use with Cull Pattern) [btw, I’m still not very up to date with the newly released R8 components, so there might be better ways to handle this]

I’m not attaching a definition because at the end it’s just a couple of components dropped at the very start of the definition… I’ll explore a bit the angles part in the coming days, looks to me you have done a great job!

Thanks for the help, much apreciated.

I started again this afternoon with a slightly different aproach to avoid the couple of bugs that I was getting. Still had a few issues but I think it is working better, just trying to impliment the GH remote that you reccomended. I think this will be good for specifying the tools as well.

If you get a minute it would be great to hear your thoughts on this slightly different aproach? Its all a steep learning curve for me as I’m only just getting started with GH

thanks again

5_axis_sim_004.gh (196.9 KB)

I’m curious as to which software capable of programming 5-axis lacks a machine model. That seems like a huge omission.

It’s been my experience that trying to do this kind of stuff yourself can end up costing more that a readily available solution. It can be a very interesting project, but it may not be an economically feasible project.

I am using RhinoCAM. It has a machine tool simulation but it doesnt work (only toolholder simulation), they told be that they were working on it. Even if they do get it working it wouldnt detect a collision of the spindle, only the toolholder. Its pretty budget software for 5 axis machining but I like doing it all in rhino as the CAD side of things is so good, even if the CAM is basic.
Although I am using my GH definition in a very simple way of visually predicting a collision it has proved an invaluable tool for programming cut paths for difficult to reach geometries even in this basic state.
Its also a fun excersise for me trying to learn grasshopper.

Your definition in the post above is missing the input surface.

If you mean “5_axis_sim_004” you have to make a layer called TS draw a planar surface and name it TS in the properties then the geometry pipeline will recognise it and input it. Sorry just setting up it to work in GH remote.

The first definition you manually set the planar surface

it needs cleaning up but here it is in a basic state with the GH remote added with cutter and toolholder definition.

Thanks again for your help I think this will work well.

let me know your thoughts if you get a spare minute.

5_axis_sim_005.gh (648.0 KB)

One last thing, do you know what I need to write in the button for it to open grasshopper and this specific file?

Thanks Tom. We use RhinoCAM too, and I have machine models that work, but you are correct about collision detection against the machine components. There should be a new release very soon, so maybe that will be included in the new release.

if you are not interested in having multiple spindles simulated altogether in the screen, then you can just ignore my definition because your is already working 100% ok :+1:

also, the thing of not allowing baking AND the thing of drawing a sphere around the object if the angles are wrong is very smart and useful

if having multiple spindles together is of any help, then this will respond to show/hide in Rhino (needs plugin Human or a different workaround), shows correct spindles in green and wrong ones in red, and does not allow baking if one wrong spindle is being visualized on screen (which means that if you hide it, then the correct ones will bake)

a fast visual explains it better :slight_smile:


5_axis_sim_005_multiple_surfaces_together.gh (644.9 KB)


this should work for the button that opens the GH file directly: How to create a button in Rhino that launches a specific Human UI/GH script - #2 by andheum


about collisions, you might use a one|many collision between each part of the spindle (but not including the tool: that is not in the game because it has to collide :slight_smile: ) and the geometry (or the layer of the geometries you are working on → a new Geometry Pipeline)

in cascade, another check is added before baking, so if a collision is detected, or a wrong spindle is detected, nothing will bake even if the bake button is pressed

something like this, with an Obstacle layer in Rhino:


5_axis_sim_005_multiple_surfaces_together_and_collisions.gh (651.1 KB)

Apologies for the late reply, thanks for everything, this has all been very helpful and I’ve learnt a lot. I will continue to develop this tool as I use it. Working on a few more at the moment to help with more 5 axis machining. Love the GH player and remote with my own custom buttons. The possibilities are endless.