Freesteel » The non-axial projection subjection
The non-axial projection subjection
Wednesday, October 8th, 2008
You don’t begin a project that will take the rest of the year and more without evading it as long as you can. Finally I’ve begun to break ground on this.
Background: Almost all industrial algorithms for generating toolpaths for 3-axis machining are based on the Drop Cutter function, where the tool is lowered along its axis towards a triangulated surface until it makes contact. I have discussed this here, where I also add my usual complaint about how almost all of published academic literature on 3-axis machining is based on the contact point offset from a point in a parametric surface, and so is of no use. The problems raised by that approach are insurmountable, and you don’t need to solve them because there is a better way.
For most CAM systems, if you speed up the Drop Cutter function (which for toroidal cutters often depends on solving the quartic equation), then everything runs faster. The other determination of performance is if the implementation of the machining strategy calls this Drop Cutter function too frequently. That’s how fundamental the function is.
The only 3-axis machining algorithm that does not depend on the Drop Cutter function is the Horizontal Projection function used in the calculation of constant Z (waterline) contours. (A visualization of a bug in it is shown here.) This Horizontal Projection function finds the points of intersection when the cutter moves in the plane perpendicular to its axis. In Machining Strategist/Depocam I never solved it for the toroidal case (because I didn’t know the answer to an order six polynomial which you get instead of the quartic), and used a neat little fudge where I could get to the same answer by measuring the contours for a ball-nosed cutter and then offsetting the contour in its plane by the radius of the circular axis of the torus. In HSM Works/Adaptive Clearing I finally worked out how to do it, which is fortunate because I’m going to need it here, and there’s no way round it.
The obvious fundamental 5-axis cutter location function is shown in the diagram above. The cutter is in an arbitrary orientation (the red dotted line is its axis) and is dropped in an arbitrary direction (the thick green vector) to find the point of contact with the triangulated surface (outlined in blue).
We can transform everything into a better position and make the green vector the vertical Z-axis. Then, if the dotted red line (axis) is in line with this green vector, we’re back to the 3-axis condition. If the dotted red line is horizontal (perpendicular to the green vector), then that’s Horizontal Projection function. Otherwise we can rotate the assembly so that the dotted red line is in the X-Z plane to observe that the only new parameter we need to include is the angle between the axis of the cutter and the direction of projection. (If the red axis line is below the horizontal I’m going to reflect about the horizontal X-Y plane.)
Makes it seem simple. The interface into the big calculation engine that solves the Horizontal Projection function merely needs to take a unit 2D vector in the X-Z plane representing the tilt from the red vector to the green vector. A value of (1,0) is the Horizontal Projection, and (0,1) is the Drop Cutter function.
At least that gives it a home and a tiny tweak to the interface for the other developers to access. But there’s going to be thousands of lines of hard code coming up real soon over the next few months.
BTW this doesn’t unify the Horizontal Projection and Drop Cutter functions, because the Drop Cutter, being as fundamental as it is, is unbelievably optimized. In its case there is a rotational symmetry about the Z-axis that can be heavily exploited. Once there is a tilt from this axis, the symmetry is broken.
And so to work.
6 Comments
1. Denys Plakhotnik replies at 8th October 2008, 9:01 pm :
it is easier and faster to move a CC point over an offset surface than calculating drops. for ball-nose mill 5-axis toolpath generation is almost the same as for 3-axis. the tool orientation is added to avoid collision and reach unaccessible regions.
2. Julian replies at 13th October 2008, 4:40 pm :
Thanks for this comment, and the link to a paper in the last post about 5axis. I’ve added it to my library.
The conventional method for moving CC points over an offset surface fails when the model has concave corners (where the cutter positions gouge the part) and convex corners (where there are many cutter positions for one CC point).
As with autonomous robots, these obstacles are what really matter; they are not a special case to be dealt with once we have mastered locomotion along smooth undulating surfaces.
3. Denys Plakhotnik replies at 13th October 2008, 5:40 pm :
Bull s***, it depends on an offset algorithm only. with the good algorithm you don’t have any problems. Just first article I found
http://www.cadanda.com/V1Nos1to4_33.pdf
4. Julian replies at 13th October 2008, 9:29 pm :
I’m sure that with a “good” algorithm anything will work — by the definition of the word “good”.
However, I don’t believe there are any offsetting algorithms that are good enough. The paper you pointed to is very brief and really only discusses what to do with convex edges for completely spherical cutters.
It has nothing to say for cutters that are non-spherical where the length of the normal depends on the orientation of shaft.
And for concave edges it has only this to say:
In simpler terms, they are saying: “Sorry, we can’t do this part of the algorithm in 3D.”
Even the 2D method they have reduced it to is extremely hard. I wouldn’t want to code it.
It doesn’t take many issues like this, and others I haven’t mentioned, before the complexity and unreliability of the Cutter Contact point method exceeds the speed and predictability of the cutter projection method — which is the one applied in all industrial CAM kernels that I know.
5. Denys Plakhotnik replies at 14th October 2008, 8:25 am :
In 3-axis milling, Z plane is a ruled surface. You do drops along Z direction to surface. In 5-axis ball milling there is no exact direction, unless you use ruled surface. When you have “inverse tool-offset (ITO) surface”:
http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TYR-481DWM8-FK&_user=877992&_coverDate=08%2F31%2F1989&_fmt=abstract&_orig=search&_cdi=5625&view=c&_acct=C000047079&_version=1&_urlVersion=0&_userid=877992&md5=464d38d4d40831efbab26a13e9083a15&ref=full
http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6TYR-3SP2NK3-G&_user=877992&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_version=1&_urlVersion=0&_userid=877992&md5=14fa546b497b62e5efdb4970c1592caf
http://dimacs.rutgers.edu/Workshops/CompAided/slides/misra1.pdf
pp. 85-95
http://books.google.com/books?id=TzYYSwAJKrAC&printsec=frontcover
you have the surface of feasible CL point positions. then just set collision-free inclination. Moreover, you don’t do drops while varying inclination.It seems to be enough advantage. The workflow for ball-end milling becomes “simple”:
1. offset surface
2. generate CL path on the ITO (remember each position is a gouge-free)
3. set collision-free tool orientation (visibility cone, gauss map, etc).
Unfortunately, ITO suits for 3-axis and 5-axis ball end milling only.
6. Julian replies at 4th November 2008, 11:51 am :
… or you conclude that the academic community has got this issue wrong and have done so for years, and go with the way it’s done in all high-end CAM software in the world — which is just as I have outlined it.
There’s a point when they will eventually be forced to take notice of this challenge to the theories — though not as dramatically as the theoretical economists have to explain the financial crisis.
Actually, it’s always surprised me how the academics don’t even seem to have the intellectual curiosity to inquire about how the commercial software works, so sure as they are of the fundamental principles, in spite of the lack of a working model.
Having written two machining kernels from the ground up that compete in the open market, I am still apparently qualified for nothing when compared to a crusty old book from the 1980s.
I don’t know of any other fields of engineering and software that are as disconnected as this.
Where is this Professor B K Choi these days? He used to publish papers about machining almost every month in CAD magazine. They were good for a laugh, because they were all of them entirely useless — for the production of practical software that worked.
Leave a comment