I am curious how any of you that are involved with the CNC side of
things handle the programs for various parts with particular interest
in Surfcam and Mastercam. It seems to me that the machinists generate
a number of programs to finish a specific part, perhaps because of the
operations involved, perhaps because the part re-oriented and perhaps
because multiple machines will complete a single part. This means
multiple files for a single part. Added to that is the reuse of
programs and it seems like documenting and tracking this stuff can
become a nightmare.
TOP
|
|
0
|
|
|
|
Reply
|
kellnerp (210)
|
7/24/2007 12:30:13 AM |
|
MasterCAM X allows you to have just one file if you wish for all mill,
lathe and wire operations This works because you can have as many
different machine / control definitions in the Mastercam X Operation
manager as you wish. You then choose which toolpath groups you wish to
post output for.
Gibbscam doesn't allow this. You have to have separate files for mill,
lathe and wire EDM.
I don't believe Surfcam allows this either.
You are correct it requires a lot of file management.
Jon Banquer
San Diego, CA
http://blog.novedge.com/2007/07/an-interview-wi.html
|
|
0
|
|
|
|
Reply
|
jon_banquer
|
7/24/2007 1:59:50 AM
|
|
On Mon, 23 Jul 2007 17:30:13 -0700, TOP <kellnerp@cbd.net> wrote:
>I am curious how any of you that are involved with the CNC side of
>things handle the programs for various parts with particular interest
>in Surfcam and Mastercam. It seems to me that the machinists generate
>a number of programs to finish a specific part, perhaps because of the
>operations involved, perhaps because the part re-oriented and perhaps
>because multiple machines will complete a single part. This means
>multiple files for a single part. Added to that is the reuse of
>programs and it seems like documenting and tracking this stuff can
>become a nightmare.
>
>TOP
Xposted to alt.machines.cnc
--
Cliff
|
|
0
|
|
|
|
Reply
|
Cliff
|
7/24/2007 4:33:22 PM
|
|
On Mon, 23 Jul 2007 18:59:50 -0700, jon_banquer <jon_banquer@yahoo.com> wrote:
>MasterCAM X allows you to have just one file if you wish for all mill,
>lathe and wire operations This works because you can have as many
>different machine / control definitions in the Mastercam X Operation
>manager as you wish. You then choose which toolpath groups you wish to
>post output for.
>
>Gibbscam doesn't allow this. You have to have separate files for mill,
>lathe and wire EDM.
Needle files, 12" mill bastards, etc?
>I don't believe Surfcam allows this either.
>
>You are correct it requires a lot of file management.
Thus a few buzzwords but no answers.
OTOH You'd have to actually USE a system & actually *create*
programs to see any possible problems or know what was asked
about.
>Jon Banquer
>San Diego, CA
>http://blog.novedge.com/2007/07/an-interview-wi.html
Xposted to alt.machines.cnc
--
Cliff
|
|
0
|
|
|
|
Reply
|
Cliff
|
7/24/2007 4:37:10 PM
|
|
On Mon, 23 Jul 2007 17:30:13 -0700, TOP <kellnerp@cbd.net> wrote:
>I am curious how any of you that are involved with the CNC side of
>things handle the programs for various parts with particular interest
>in Surfcam and Mastercam. It seems to me that the machinists generate
>a number of programs to finish a specific part, perhaps because of the
>operations involved, perhaps because the part re-oriented and perhaps
>because multiple machines will complete a single part. This means
>multiple files for a single part. Added to that is the reuse of
>programs and it seems like documenting and tracking this stuff can
>become a nightmare.
>
>TOP
CNC side is not all that complicated, save by part number and
revision.
What I do is create a master file using the part number. EVERYTHING
associated with that part number is in that ONE electronic file and is
saved by part number, revision and operation. All the files are read
only so if a change comes call up last revision, do a file save as,
new revision, make the necessary changes to these new files and last
step make file read only so they can't accidentally be changed.
Tom
|
|
0
|
|
|
|
Reply
|
brewertr
|
7/24/2007 5:57:10 PM
|
|
On Jul 24, 10:57 am, brewe...@aol.com wrote:
> On Mon, 23 Jul 2007 17:30:13 -0700, TOP <kelln...@cbd.net> wrote:
> >I am curious how any of you that are involved with the CNC side of
> >things handle the programs for various parts with particular interest
> >in Surfcam and Mastercam. It seems to me that the machinists generate
> >a number of programs to finish a specific part, perhaps because of the
> >operations involved, perhaps because the part re-oriented and perhaps
> >because multiple machines will complete a single part. This means
> >multiple files for a single part. Added to that is the reuse of
> >programs and it seems like documenting and tracking this stuff can
> >become a nightmare.
>
> >TOP
>
> CNC side is not all that complicated, save by part number and
> revision.
>
> What I do is create a master file using the part number. EVERYTHING
> associated with that part number is in that ONE electronic file and is
> saved by part number, revision and operation. All the files are read
> only so if a change comes call up last revision, do a file save as,
> new revision, make the necessary changes to these new files and last
> step make file read only so they can't accidentally be changed.
>
> Tom
When MS "DOS" was Boss I used to pick out a floppy and put a P/N on it
and store all the files in there. The floppy was then stored in the
file cabinet with the print etc.
A disk crash was then not a BIG problem. I suppose CD's would work as
well.
I had my Acad generate the files ON the floppy. Nothing on the 'puter
except programming files.
Regards,
Stan-
|
|
0
|
|
|
|
Reply
|
Metalcutter
|
7/24/2007 8:57:27 PM
|
|
also add,
programs left in the controllers, is there someone who monitors this?
custom edits at controller, do they ever get documented?
|
|
0
|
|
|
|
Reply
|
kenneth
|
7/24/2007 10:40:04 PM
|
|
> also add, programs left in the controllers, is there someone who >monitors this?
Usually the responsibility of the person running the job to send it
back to the server.
> custom edits at controller, do they ever get documented?
Define what documented means to you in this sense.
Jon Banquer
San Diego, CA
http://worldcadaccess.typepad.com/blog/2007/07/spend-a-littleo.html#comment-76366100
|
|
0
|
|
|
|
Reply
|
jon_banquer
|
7/25/2007 12:55:39 AM
|
|
Thanks. Some interesting insights there. And very different in
philosophy from CAD files. From my own observations (more as a
tourist) and from bigger operations comes the issue of multiple people
getting different CAM operations to perform. Right away that shifts
things to a network, not a floppy or CD.
I am wondering whether there are ever any operations so formal as to
have a CAD drawing for each set of CNC operations performed?
I suppose that if "on machine" edits were to be captured there would
have to be some support from the machine vendor to support capture of
such events.
I think there is also the issue of tying a particular program to a
particular machine with a particular set of tools in the changer.
Is there ever a document made to go with the files on the floppy that
contain notes needed to reproduce whatever part is being made?
TOP
|
|
0
|
|
|
|
Reply
|
TOP
|
7/25/2007 2:18:09 AM
|
|
"I suppose that if "on machine" edits were to be captured there would
have to be some support from the machine vendor to support capture of
such events."
A CNC machine runs on G and M code. I've never seen anything like you
describe. When the job is finished the machinist uploads the optimized
G code file to the server so the program is optimized next time it's
run on the same machine. In better shops the time is taken to update
the CADCAM file rather than the G code file. There are major
advantages to updating the CADCAM file rather than the G code but many
shops that I have worked in don't take the time to do this.
"Is there ever a document made to go with the files on the floppy
that
contain notes needed to reproduce whatever part is being made? "
Yes. Often In better companies or for more difficult parts you have
something called an M.O.T. which stands for Methods, Operations and
Techniques and it describes the way the part is to be made... usually
with numbers and a description of what is to be done for each
operation.
The M.O.T. is a part of the "traveler".
Jon Banquer
San Diego, CA
http://worldcadaccess.typepad.com/blog/2007/07/spend-a-littleo.html
|
|
0
|
|
|
|
Reply
|
jon_banquer
|
7/25/2007 6:05:45 AM
|
|
On Tue, 24 Jul 2007 23:05:45 -0700, jon_banquer <jon_banquer@yahoo.com> wrote:
>"I suppose that if "on machine" edits were to be captured there would
> have to be some support from the machine vendor to support capture of
>such events."
>
>A CNC machine runs on G and M code. I've never seen anything like you
>describe. When the job is finished the machinist uploads the optimized
>G code file to the server so the program is optimized next time it's
>run on the same machine. In better shops the time is taken to update
>the CADCAM file rather than the G code file. There are major
>advantages to updating the CADCAM file rather than the G code but many
>shops that I have worked in don't take the time to do this.
>
>"Is there ever a document made to go with the files on the floppy
>that
>contain notes needed to reproduce whatever part is being made? "
>
>Yes. Often In better companies or for more difficult parts you have
>something called an M.O.T. which stands for Methods, Operations and
>Techniques and it describes the way the part is to be made... usually
>with numbers and a description of what is to be done for each
>operation.
>
>The M.O.T. is a part of the "traveler".
>
>Jon Banquer
>San Diego, CA
>http://worldcadaccess.typepad.com/blog/2007/07/spend-a-littleo.html
|
|
0
|
|
|
|
Reply
|
Cliff
|
7/25/2007 9:04:28 AM
|
|
On Tue, 24 Jul 2007 19:18:09 -0700, TOP <kellnerp@cbd.net> wrote:
>Thanks. Some interesting insights there. And very different in
>philosophy from CAD files. From my own observations (more as a
>tourist) and from bigger operations comes the issue of multiple people
>getting different CAM operations to perform. Right away that shifts
>things to a network, not a floppy or CD.
>
>I am wondering whether there are ever any operations so formal as to
>have a CAD drawing for each set of CNC operations performed?
>
>I suppose that if "on machine" edits were to be captured there would
>have to be some support from the machine vendor to support capture of
>such events.
>
>I think there is also the issue of tying a particular program to a
>particular machine with a particular set of tools in the changer.
>
>Is there ever a document made to go with the files on the floppy that
>contain notes needed to reproduce whatever part is being made?
>
>TOP
|
|
0
|
|
|
|
Reply
|
Cliff
|
7/25/2007 9:04:40 AM
|
|
On Tue, 24 Jul 2007 19:18:09 -0700, TOP <kellnerp@cbd.net> wrote:
>I am wondering whether there are ever any operations so formal as to
>have a CAD drawing for each set of CNC operations performed?
Yes, normally associated with larger companies and high production.
>I suppose that if "on machine" edits were to be captured there would
>have to be some support from the machine vendor to support capture of
>such events.
Programs are normally sent and received by cable, when permanent
changes are made just send that edited program back and add comments
about changes made if necessary. Whatever method is used to send
programs to the machine controller just reverse it back when changes
are necessary and permanent.
>I think there is also the issue of tying a particular program to a
>particular machine with a particular set of tools in the changer.
A good argument for standardizing machinery, controls and tool
positions on the shop floor.
CAM program has post processors that allow it to generate code for any
machine the shop has. The CNC program itself is normally tied to a
particular machine and control but not the CAM program.
>Is there ever a document made to go with the files on the floppy that
>contain notes needed to reproduce whatever part is being made?
Yes, CAM programs can generate setup sheets with tool information and
position for setup/operators. How it is generated and in what format
would be determined by shop policy. For more difficult setups and
parts it may include photos or renderings of fixtures, clamp
positions, special tooling, part zero etc.
>TOP
Tom
|
|
0
|
|
|
|
Reply
|
brewertr
|
7/25/2007 1:11:25 PM
|
|
> I am wondering whether there are ever any operations so formal as to
> have a CAD drawing for each set of CNC operations performed?
I've seen it.
> I think there is also the issue of tying a particular program to a
> particular machine with a particular set of tools in the changer.
IIRC, I've seen that too.
> Is there ever a document made to go with the files on the floppy that
> contain notes needed to reproduce whatever part is being made?
I have not done these things first hand, so I don't know how the documents
are managed. One of our customers does high-volume turnkey milling systems
that quite often involve complex machining programs and even alterations to
the controller's software. I'm sure all of this has to be documented for
the end customer and passed on somehow.
|
|
0
|
|
|
|
Reply
|
Dale
|
7/25/2007 1:19:42 PM
|
|
On Tue, 24 Jul 2007 22:40:04 GMT, "kenneth" <kb@none.com> wrote:
>also add,
>programs left in the controllers,
I don't leave part programs in the controller. I delete last program
before I upload a new one.
>is there someone who monitors this?
Put part number, revision number, who created program and the date in
the program header. That way if you save programs in the controller it
is easy to see if it is the correct program and revision.
>custom edits at controller, do they ever get documented?
CNC Programs are or should be treated the same as any controlled
document IMO. I don't allow editing at the controller, if a mistake
was made in programming then the programmer should fix it.
I get in trouble every time I say this so I will point out that this
is not always possible and shop policy should dictate who is
authorized to make changes to programs and under what circumstances.
Shop policy should also insure that those changes are documented and
saved as necessary.
Tom
|
|
0
|
|
|
|
Reply
|
brewertr
|
7/25/2007 2:01:36 PM
|
|
Another part of this question is what kind of lifetime does CAM data
have? Unlike a part print, CAM data seems to be able to be obsoleted
very quickly. Since the parts being made have to meet the print to be
accepted the part print has to be kept and can be used to reproduce
the part at any time. But CAM data could change for the same part if,
for example, a different machine is used to produce the part, somebody
comes up with more efficient code or a host of other reasons. When a
program like Surfcam or MasterCam are used, is there a part of what
they do that can be considered machine independent and another part
specific to a machine? If so is the tendency to keep the machine
independent part and let the machine specific part go after a while?
What event would trigger deletion of a CAM program?
TOP
|
|
0
|
|
|
|
Reply
|
TOP
|
7/26/2007 2:40:34 AM
|
|
On Wed, 25 Jul 2007 19:40:34 -0700, TOP <kellnerp@cbd.net> wrote:
>Another part of this question is what kind of lifetime does CAM data
>have?
If kept by revision there is no "Lifetime".
>Unlike a part print, CAM data seems to be able to be obsoleted
>very quickly.
CAM holds the model and tool path, that shouldn't change unless the
part or machining strategy changes.
>Since the parts being made have to meet the print to be
>accepted the part print has to be kept and can be used to reproduce
>the part at any time.
>But CAM data could change for the same part if,
>for example, a different machine is used to produce the part,
CAM data does not change, post (machine specific G-Code) from CAM data
for new machine.
> somebody
>comes up with more efficient code or a host of other reasons.
Revise the CAM model and or Tool Path so code can be posted to any
machine.
>When a
>program like Surfcam or MasterCam are used, is there a part of what
>they do that can be considered machine independent and another part
>specific to a machine?
The part model and finish tool path won't change unless a customer
revision is made.
Machining strategy could change depending upon the CNC machines on the
shop floor. It is possible feeds, speeds, tooling could change if
machine HP, work envelope, rigidity or availability of machine
specific tooling changes.
>If so is the tendency to keep the machine
>independent part and let the machine specific part go after a while?
Don't understand the question, if its broke fix it, if its obsolete
never to be used again get rid of it.
>What event would trigger deletion of a CAM program?
A part that will never come back, even still I may back it up to CD or
DVD it's cheep enough and just in case the job that was never supposed
to come back does.
>TOP
Tom
|
|
0
|
|
|
|
Reply
|
brewertr
|
7/26/2007 3:55:09 AM
|
|
"Another part of this question is what kind of lifetime does CAM data
have?"
IMO, this question is too broad in scope to answer. I don't think
anyone really knows the answer to that.
"What event would trigger deletion of a CAM program?"
Here are two events that spring to mind immediately:
Moving the job to a CNC machine that is capable of high speed
machining where you most likely will want a totally different toolpath
strategy than what currently exists. It might very well be easier to
start again rather than delete tons of toolpath and recreate them.
If the volume of the order increases so that it no longer makes sense
to do the job on the machine(s) you were doing it on.
Example:
Job is being done on a vertical mill. Volume now dictates the job
would be better off being done on a horizontal mill that has
tombstones and a pallet pool.
Jon Banquer
San Diego, CA
http://blog.novedge.com/2007/07/an-interview-wi.html
|
|
0
|
|
|
|
Reply
|
jon_banquer
|
7/26/2007 4:56:39 AM
|
|
On Wed, 25 Jul 2007 21:56:39 -0700, jon_banquer
<jon_banquer@yahoo.com> wrote:
>"What event would trigger deletion of a CAM program?"
<snip>
>
>Example:
>
>Job is being done on a vertical mill. Volume now dictates the job
>would be better off being done on a horizontal mill that has
>tombstones and a pallet pool.
Jon,
Your example seems a little short sighted and doesn't justify deleting
a CAM program.
No reason to delete a good CAM Program for an existing and repeating
job unless you can control order quantities and delivery dates. Job
shops or even most shops don't know what the customer reorder
quantities are going to be or delivery requirements, future machine
utilization etc., these are all variables and can change over time.*
It costs next to nothing to save existing CAM programs but it costs a
lot if you delete one you could use again later on down the road.
In your example it would be smart to save the vertical mill program
and create a new CAM program for the horizontal mill ( or pull up the
VM program, do a file save as, edit it for HM and save).
>Jon Banquer
Tom
*An exception could be high production facilities with dedicated
machining cells, long term agreements and minimum order/run
quantities.
|
|
0
|
|
|
|
Reply
|
brewertr
|
7/26/2007 6:40:50 AM
|
|
THANKS
|
|
0
|
|
|
|
Reply
|
TOP
|
7/27/2007 11:41:50 AM
|
|
|
19 Replies
205 Views
(page loaded in 0.237 seconds)
|