Re: programming by hand

Doug,

Not being a "real CNC machinist", I am not familiar with what can be
done on a graphical controller ($$$), so I don't know what canned cycles
they provide. IMO, if the same "canned cycles" were saved either as
Gcode or drawing objects, they could be "imported" into a drawing or
editor as needed, with a parm screen (I think I've seen Vector do that)
and the code sent to the mill. Is this similar in result to what you're
said you can do on a graphical controller?

So what we need are "objects" that are parameter driven, for our CAD/CAM
software! Some of Jon's pieces! A good repertoire of "objects" could
equally well be accessible by a PC-based controller program, and
accomplish the same things! IMO.

Yeah, I'll bet a CAD/CAM system "wrote" the canned cycle in the first
place! So you ARE doing it "their" way! ;>)

Alan KM6VV (Who doesn't know anything about the BIG GUYS!)

PS, Is this conversational programming?


dougrasmussen@... wrote:

>
> Joe,
>
> No so sure I totally agree with you. Probably 98% of our programming
> for my 4 cnc's is done on the shop floor. I like to think we're
> pretty efficient. Most of our work is close tolerance prototype
> stuff.
>
> Given the modern graphical controllers with a good assortment of
> canned cycles, the need for CAM is diminished. Don't forget it's the
> exception to run into a part which is not made up of a few
> rudimentary shapes which can easily be handled by canned cycles.
>
> There's some great advantages of using the control's canned cycles
> also. It's very easy to modify the program (usually just one line of
> code to completely program a rectangular pocket including step
> milling, corner radius spec, plus a finishing pass, for example...
> that could easily equal 50+ lines of code from a CAM system), but one
> of the biggest advantages is the canned cycles use cutter radius
> compensation. So, if for whatever reason a feature does not come out
> on size it's easy to change it slightly by changing the cutter
> diameter in the tool offset table. Try that with a CAM generated
> program.
>
> And, yes, everyone will need a CAM system at some point. Irregular
> pockets are difficult using canned cycles. But, I think their need
> is overrated. On the other hand a CAD system is a must.
>
> Oh, yeah, here's another reason in favor of hand programming....you
> get to cut the parts the way you want not the way the CAM system
> wants.
>
> Comments?
>
> thanks,
>
> Doug
>
> --- In CAD_CAM_EDM_DRO@egroups.com, Joe Vicars <jvicars@c...> wrote:
> > It would only take about 40 hours of writing G-code "by hand" to
> offset
> > the cost of a decent CAM package. That's about 2000 bucks at
> average
> > billing rates.
> > Anything but the most rudimentary code writing would quickly run
> into
> > labor cost that would far outweigh the cost of CAM.
> > If your controller won't take a floppy or RS232 or whatever then
> that is
> > another matter, but then you probably need to upgrade the control.
> The
> > same amortization would apply to the control upgrade.
> > It just depends on how you cost out your time. Most hobbyists don't
> > bill their time as money, so a few hours of code writing is cheaper
> than
> > 500 bucks cash money.
> > Still, it is awfully inefficient with all the stuff available.
> > My $.02
>
> Welcome to CAD_CAM_EDM_DRO@...,an unmoderated list for the discussion of shop built systems, for CAD, CAM, EDM, and DRO.
>
> Addresses:
> Post message: CAD_CAM_EDM_DRO@egroups.com
> Subscribe: CAD_CAM_EDM_DRO-subscribe@egroups.com
> Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@egroups.com
> List owner: CAD_CAM_EDM_DRO-owner@egroups.com, wanliker@...
> Moderator: jmelson@... [Moderator]
> URL to this page: http://www.egroups.com/group/CAD_CAM_EDM_DRO
> FAQ: http://www.ktmarketing.com/faq.html
> bill,
> List Manager