Freesteel Blog » The structure of a CAM system

The structure of a CAM system

Saturday, June 24th, 2006 at 5:58 pm Written by:

no chainIn Cimco everyone was doing their own thing. Someone would spend a couple months writing the parallel (raster) passes routine and its associated linking routine, and then someone else would move on and write a countour (z-profile) toolpath routine and linker for the special case when the paths were closed, and then someone else was going to do the same for scallop (constant stepover), and so on. This appeared to be breaking the project down into manageable pieces to be distributed among the programmers. But it wasn’t. I could point to massive areas of duplicated effort, combined with the failure to reuse code because it had not been written with the general application in mind.

Let’s say there are five strategies for finish machining: parallel, countour, pencil, scallop, and offset scallop. We don’t have accurate terminology, and I am still looking for volunteers to help me enter definitions for these into the wikipedia.

These strategies all produce sets of toolpaths — piecewise linear curves for guiding a pre-specified tool through space while in contact with the CAD defined model. This is an important stage of development, but it’s not enough to drive the machine.

Between each cutting toolpath and the next there has to be a non-cutting toolpath to guide the cutter from the end of one and the beginning of the next. The tool can’t be teleported like, say, the tool that is the spot of a cutting laser which can be turned off and on. It’s a physical motion capable of collision and which is seen as being wholly unproductive. You can construct all kinds of elaborate arcs and over-curls into these linking paths to take account of the machine’s momentum and drive it faster, although the journey may become longer. No one knows what is the most efficient, so such motions are artistically designed to look smooth and fast to the experienced user or software purchaser.

It’s also possible to improve the ordering of the toolpaths, which itself is an art, since no one has conducted any rigourous tests or guidelines for this either. It’s all done by theory, and since the theory says it’s equivalent to the travelling salesman problem, there is no theoretically perfect answer.

A specific example. Suppose you have a whole series of contour passes — Z-slices — through a model that has the shape of two round pillars. Each slice will be made of two disconnected circular toolpaths. It is considered bad form to hop between one and the other as you go down the levels, even though this was the order they were calculated in. It is better to re-order them so you go down first one pillar, and then the next, although not beyond the level of the base of the pillars where the contours become joined. For a model with many holes and pillars, the combinatorial structure can get quite complex.

The point I was making was that it’s no good one person being put on the job of re-ordering and linking parallel passes for two months, and then the next person re-ordering and linking the contour passes later on in the summer. You have start by treating all toolpath strategies as one kind, and then consider the special cases only when necessary. Once you fragment the operations you make it very difficult to spot similarities and reuse the code.

So my plan says that every toolpath strategy goes through one huge re-orderer and linker module. It takes about ten minutes to write the first version — version zero of reorderer leaves it as it is, and the linker inserts what is known as retract paths between every two toolpaths. A retract path is made up of three segments: the cutter lifts to a safe Z height, moves to the XY point above the start of the next toolpath, and drops down vertically to the start of that toolpath.

This is not the best result for the CAM system to send out, but it is valid and works.

Now you can begin transforming it and incrementally developing it into something better, while all the time your prototype system remains functional and able to make valid and working toolpaths.

An easy way to organize the code for linking between toolpaths is to make up several styles (in addition to the retract style, which always works), call each one in turn, and then pick the one that gives the best result. If someone invents a new style, say, one that is able to connect from one position to another within the same Z-contour and manouver around islands, it is easy to add it in with the full knowledge that it won’t make anything worse, since it will only be used if it makes a result that is better than something that is already there.

There’s more to it than this, but this is the underlying pattern to look for.

Software development should not be like building a car, where on the last day you can finally put on the wheels and drive it around. It’s should be like building a road system where, once you build one bridge across each river it’s possible to drive everywhere — just not very fast. Now you carefully observe what is happening to the traffic and plan carefully: where do you put a new stretch of motorway to make the most difference? You can consider radically different alternative configurations before you commit to them. But all the time you still have something that works and is predictable. So long as a bridge doesn’t fall down.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>