Re: Conversational CNC Programming

Ray,

Two of the machines in my shop are conversational with graphics,
Dynapath & Fagor, mill & lathe respectively. Well over 90% of our
programming is done on the floor in front of the machine right off
the drawing. I've found this to be much faster than using CAM in
the office and downloading. Both of these controls have extensive
assortments of canned cycles. Plus handy little features like
automatic corner rounding/chamfering (I would never want to be
without this feature again).

Sometimes we'll have to mix a snippet of CAM generated code into the
conversational program. Both these controls allow a mix
of "standard" Gcode mixed in with their conversational canned
cycles. This is done when there's a complex contour or such that
can't be easily done with an available canned cycle.

One thing I really like about the canned cycle/conversational
approach is ease of debugging/modifying the programs. I've had
conversational programs with only a few lines of easily
understandable code versus a CAM generated program accomplishing the
same task that might literally be thousands of lines of code. Try
debugging or modifying the CAM generated program, almost impossible
without going back into the office and downloading a modified file.
You know from experience that programs do need to be modified,
sometimes there are things you just can't make a judgement on until
you try it, depths of cut for instance. With the conversational
approach most of these program mods are just a simple parameter
change.

An argument in favor of shop floor programming in the short-run
production environment is a person can program the part the way he's
comfortable running it. We all have our own "style" and generally
I've found letting the operator do it their own way is better for
through-put.

My $.02 on the subject, and reasons why I don't think any of
the "hobby" class controllers will suit my method of running a shop.

Doug



--- In CAD_CAM_EDM_DRO@yahoogroups.com, "Raymond Heckert" <jnr@a...>
wrote:

> What you're describing fits the definition of 'conversational

programming'.

> Now, while I haven't been everywhere, it *has* been my experience

that

> off-line programming is more time/cost effective. Picture it as;

the

> machine is capable of producing parts at a rate of 3 to 4 hundred

dollars

> (US) per hour (and, indeed considerably more, in some cases). The

operator

> is getting probably $16 to $20 per hour - if he (okay, or she) is

a real

> Cracker-Jack. Anyways, why would you employ that operator to spend

a half

> hour programming a complex part that could have been programmed

off-line by

> a programmer making, perhaps $20 to $24 per hour, but, in the

meantime, the

> machine could be EARNING several hundreds of dollars in that

amount of

> time? At least that's been my experience with "conversational

programming'

> in a production, job-shop. It might work okay for Home Shop

Machinists,

> though. Anybody else have thoughts on this? Or is this bordering

on O-T?

> (Or is it a case of, "If you have to ask, it is")?
>
> RayHex
>
> ----------
> > From: forumtvm <forumtvm@y...>
> snip
> >
> > What I am trying to get is a "video" of someone action on

a "real"

> > CNC machine with a controller on conversational programming.

What

> > does he do? Does he, like described above, have an interface

where he

> > respond to queries and have the "conversational program"

generate an

> > NC program which he will then have to feed to a controller to

run it,

> > or does he run it like MDI except it is not blocks like G00 X5,

etc.

> > Sorry, just hoping to visualise what exactly is conversational
> > programming.