Freesteel » How long does your shaft need to be?
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”.
CADCAM employees, respecting the irrational demands of their companies, are normally astoundingly reticent about any kinds of innovations and ideas that might be going on. The official reason for this habit is that the atmosphere in their office is so bubbling with heaps of potently good CADCAM innovations that if one such idea leaked out, someone who heard it would be able to apply it, win the entire market share, and put them out of business. Another explanation, probably closer to the mark, is it’s like the secret conclusive evidence for weapons of mass destruction. The secret was there wasn’t any. The commercially confidential information is that all the programmers in the office are bored out of their tiny minds, don’t want to have any ideas that just cause more work and absolutely advantage or glory coming back to them owing to the anonymized force of the corporation, and can’t even be bothered to surf around the internet for places where some sort of half-formed ideas might be disclosed by some nitwit who’s out of control of his employer and doesn’t understand the protocol of silence and the jealous protection of technological stagnation that allows clanky old ancient first-draft CADCAM kernels to continue to compete in the market like they were fresh out of Stanford, and be bothered to leave an anonymous comment at the bottom of their blog to encourage them to continue this nutty practice of giving away important secrets that harm his own business and helps everyone else’s to get better. It’s not like ideas only develop without sharing and testing and discussions and different implementations to get towards something that might eventually be half good, like the sales-theory that it will all come out straight and perfectly formed in the next release and take the market by storm. People are not that excited by things any more. And those developers who do still have some life left in them to offer need to understand this so they can move their work forwards and faster and eventually leave this tranche of ossified kernels behind, because at the moment it takes more than a decade for the market to notice that the programmers have, like Elvis, left the building and that ten years of uninvested consumer profits have been frittered away like a sour bet on the stock market and a yard deep stack of pointless legal paperwork. It’s amazing any progress gets made in spite of this sickening business cultural attitude. And that’s exactly how long your shaft needs to be.