How long does your shaft need to be?

Sunday, July 20th, 2008 at 5:59 pm

This is the result of a rapid “old feature” -> “idea” -> “new idea” -> “experiment” cycle of about a week. The Danes said they needed the feature to measure how long the toolshaft should be for a given toolholder and surface model.

In Machining Strategist/Depocam, this feature is implemented by analysing all the positions of a theoretical tool holder at every point of a given toolpath and comparing its interference with all the triangles in the model in a potentially n3 algorithm. This produces a monotonic graph of height above tooltip against maximum diameter the toolholder could be at that level and not collide with the part. You can use this to instantly predict the length the tool shaft needs to be (the stem between the cutting tip part of the tool and the chuck) given different shapes for the holder or chuck.

This is nice in theory, but in practice chuck shapes don’t change, so you might as well start with a single holder or chuck shape and calculate how high it has to be from the tool tip along every part of a given toolpath. The calculation gets faster and faster as you sample along the path, because you need the global maximum value, and with every increment of the running maximum there are fewer triangles to test the toolholder against. Add to this the fact that the operation is trivially parallelizable, and that my 3-axis holder location function is surprisingly fast (designed without compromising on memory), and the result is responsive without this intermediate data.

However, the Danes want something even more user-friendly. They wanted the tool holder length for the job without giving it a toolpath to begin with.

I couldn’t see the point in this, because the only way to implement it would be to produce a dense toolpath across the part, call the previous function, and then discard this useless toolpath. Now you’ve got a single number for the length of tool shaft, and you calculate the toolpath you wanted to anyway. Then you’d have to verify the shaft length against it just to be sure. And really you should just have the patience to wait to get this number at the right time in the course of the calculations, so you don’t waste duplication of so much cutter locationing on the surface. Unlike the tool shaft height algorithm, it doesn’t get faster the more you sample. You’ve got to scan everywhere densely because there might be just one deep narrow slot into which the tool falls, necessitating a very long tool shaft.

(Thinking about it now — and perhaps the Danes knew this and forgot to tell me during the ensuing argument over the pointlessness of this feature request — this feature does have an application for 3+2 machining when you want to to access the model from different directions in order to get away with a shorter tool.)

So, anyway, leaving it for a couple of days, coming back to it, and thinking some more, I realized the bit I didn’t like was the huge calculation resulting in one lone floating point number. What if I produced a height field where at each XY point on the drive plane it gave you the minimum length of the tool shaft? You could colour shade the surface instead of producing a height map if you had to. But still you need the numbers. I realized I could build it into my under-used stock model algorithm (it’s used to produce the fillet surfaces, but it doesn’t do animations, so no one wants it when they can bring in MachineWorks, which already works for everything, like 5-axis, which this one doesn’t). The other advantage of the stock model algorithm is it’s the same one that runs all the other algorithms (scallop, zslice, pencil, area detect) and so is already parallelized. So there.

Probably going to run out of memory, but who knows. It makes the right picture. As you can see, the high points correspond close to the steep walls. And if it was ridiculously fast, (which is isn’t going to be) you could use the mouse to vary the tool-axis in real time and see the heights changing as you maneuvered towards a more optimum position.

We’ll shelve it for another couple of weeks and come back to it. I’m minded of the fact that users normally have to type in their “desired” 3+2 style tool axis in a dialog box, usually by guesswork or using their favourite default number (eg 45degrees from vertical). It is possible that this will work will move towards the computer discovering the optimal tooling angle on its own. Or at least shifting it slightly to a better position (such as 39degrees from vertical) in a way that suddenly allows you to use a shorter tool from your stock list. The truth is, in any user interface dialog box which allows the user to set it to “any number they like” (as if this is an advantage), the option should be to type in: “The best one”.

Meanwhile, we’ll just check out check out a number of very uninspiring websites, declare it forevermore now unpatentable, and move on.

• 1. Francis Irving replies at 20th July 2008, 10:40 pm :

Come and kids, leave the guy a comment. For goodness sake.

• 2. Browser Search Plugin replies at 21st July 2008, 9:13 am :

Allow your visitors to search your website directly from their browsers. We have developed an incredible solution, which will allow you to create a small piece of code which can be placed on your website. This will allow the users to add a search plugin to their browsers – be it Firefox or Internet Explorer. So your site will be searchable directly from their browser. This means additional visitors and repeat customers. Get started now, its free for life. Browser Search Plugin

P.S. Do get back to us if you need any type of installation help.

Thanks
Rich

• 3. Bookmarks about Interface&hellip replies at 6th October 2008, 6:00 am :

[…] – bookmarked by 1 members originally found by treeeshale on 2008-09-18 How long does your shaft need to be? http://www.freesteel.co.uk/wpblog/2008/07/how-long-does-your-shaft-need-to-be/ – bookmarked by 1 […]