Re: TurboCad CAM???

Group,

I side with those who feel a CAD company has an easy programming task
in expanding their software to CAM. Supporting and handholding that
software and whether there's a large enough market to justify the
expansion into CAM is another issue.

For a few years I've been doing the majority of my CAM work off a VB
add-on I wrote to VisualCADD. And before Vcadd I was doing the same
thing using the macro language with DOS based GenericCadd. The
software was written over a period of several weeks as time
permitted, including a learning curve to understand the internal
workings of Vcadd's routines. For a simple system like I wrote a
programmer knowledgeable in the CAD sytem could do it in short order.

I didn't incorporate cutter path offsetting in my program because I
feel that should be left strictly as a function of the CNC's
controller using G41/42. But, if I'd wanted to incorporate
offsetting, the routines in VCadd are there to do the job. TurboCad
certainly has similiar offsetting routines so that's not a major
issue.

Likewise I didn't incorporate pocketing. Most controls do a good job
of supporting regular (rectangular, circular) pocketing via canned
cycles. Irregular pocketing is something else, I think it could have
been done in a pretty slick fashion using Vcadd's hatching routines,
but irregular pockets are such an exception to our usual work it
wasn't worth the effort for me.

My reason for writing the software wasn't to re-invent the wheel (I
have a full featured 3d CAM system, DOS based, unfortunately). I
just couldn't find a CAM program that'd give me quick & dirty
snippets of Gcode for those aspects of parts that can't be done using
the CNC's canned cycles. From my programming experience I got a feel
for writing a 2d CAM program and it ain't that big a deal provide you
have access to a CAD program's internal routines.

Incidently, my software works very much like Vector. Select the
cutter path in CAD with a construction point as the start. The
software searches the CAD database for "selected" entities and
progressively goes down the chain finding those that are both
selected and have connected endpoints. Just a lot of programming
busy work, nothing complicated. As I recall, the worst of the
programming was determining if an arc was CW/CCW (G02/03) given end
points, center point and which end the cut started on.

So, all this said, I think the programming is trivial for an existing
CAD company. I just don't understand their reasoning in wanting to
enter this market.

thanks,

Doug