What's new
What's new

Who proves programs in your shop???

Who proves new programs in your shop?

  • The person who programmed it.

    Votes: 28 66.7%
  • Set up staff

    Votes: 11 26.2%
  • The operator

    Votes: 9 21.4%
  • Nobody. Full send!

    Votes: 3 7.1%

  • Total voters
    42

cc22288

Aluminum
Joined
Dec 27, 2019
I'm trying to figure out if I'm crazy or not, but currently my shop has setup guys prove programs. So a draft is released, proven by the setup guy, changes are made, and then its saved back into our system. I think this is inefficient and creates alot more opportunity for changes to go unsaved and make things difficult down the line, but im open to being wrong. How does it work in your shop?
 
I'm trying to figure out if I'm crazy or not, but currently my shop has setup guys prove programs. So a draft is released, proven by the setup guy, changes are made, and then its saved back into our system. I think this is inefficient and creates alot more opportunity for changes to go unsaved and make things difficult down the line, but im open to being wrong. How does it work in your shop?

You mean the G code gets changed at the machine and then saved? Does the cam file ever get updated to reflect what changed at the machine?
 
Depends. Typically it's a bit of a free-for-all. We have 6 machinists that all do varying amounts of programming.

For anything that has significant quantity, the programmer runs it. I find that programs tend to get much better optimization when the person who programmed it has to actually sit and watch it make chips.
 
Surely the right way is to make this a two stage process.

Set-up guy proves out the initial program making any changes to the original code to get it running safely and at least acceptably fast to be the first version of the shop floor master.

Machinists then use their experience to improve, speed-up, or whatever the program so it works better on the floor. Operator changes need to be discussed and reviewed before a new improved shop floor master is saved. Review process sounds formal but it doesn't have to be. Main thing is to make a note of the changes relative to the original code. As time goes on you will build up a list of useful changes and when to use them. Such lists can be very informative as they produce in context data to help with tooling et al selection.

If you have an established and effective way of programming the initial code its often quicker and easier to simply sub in the "works better this way on our machines" after proving out the initial version than it is to try to produce a "works best on our machines" version immediately.

Naturally you always keep the original as well as the latest shop floor version.

As with all these organisation things it does depend on the size of the firm, the amount of work done and the types of job undertaken. I figure that once you get past 10 or so guys on the floor you need to start getting formal about things or you never really know where you are or whats going on. Below 4 or 5 you can probably wing it.

Clive
 
I'm of the opinion that my code coming off my CAM system should not need to be changed at the machine.
Something doesn't work, back to the office, adjust the model, send out the code and go again.
I routinely re-punch a program, send it to machine, cycle start.
Now, I have not got my lathe programming quite to that level,yet. It puts out good code, but lots of open G00 lines with no x or z. So some clean up still.

I used to save used programs, but it just isn't worth it. I have few programs in my speedio. Program number 2000 is every production program. 1234 is every fixture cutting program.
Once they are running right as programmed, then I can fiddle with DOC, RPM etc.
 
I am all three, so I program, setup and run my machine. Half of the guys in our shop program their parts and obviously setup and run their machines. The other half sets up and run their machines. We don't have purely operators. 12 CNC guys and 3 manual guys.


As far as for shops who are high volume, high production, I think the programmer should prove out the program while the setup person is there with him before handing the machine to the operator.
 
Call me old fashioned, but I can't imagine that a programmer would not prove out,
and improve a program.

A computer programmer is making a program.. Do you think they never actually try
and run the program? This really isn't any different.

Completely fine to have the setup guy dial in the fixture, and set the tools,
but that f'n programmer better be standing there. He's the one that *KNOWS*
what is supposed to happen.

If its something stupid and simple, F* it. Send it and hit GO. I do it all
the time. Complicated, my ass is right there at the machine.

---------

I'm also not a fan of saving "The Program".. Save the Cad/Cam, and repost it.
If something that you might do every couple of years, or its been a long time
since you last did it. You want to double check it, and looking at the CAM is
a lot easier than futzing around with a text file. Maybe you have new endmills,
or you are using a carbide drill now, or whatever...

I have very very few actual programs saved. And the ones I do have saved are
really not normal, and required a lot of hand coding, but I still go back to the
CAM and check it all out.

I'm with Hounddog.. EVERYTHING goes into the machine as 01000. I have a few
programs with their own #'s, but its very few. One part I do a lot is 1500,
I have a program that hoses down the whole table, I think that is 4321. Subs
are 1001, 1002, 1003.

I also save 99.5% of my programs as "Delete Me". Which I have never actually deleted,
I just keep writing it over and over and over..
 
How big is the program?
My average on a square shank toolholder on the mill is 500 to 2000 lines and perhaps 10+ tools.
I would think most lathe stuff much smaller.
When on a lathe lets say clip grooves with entrance rads or chamfer. These tend to need a tweak with tool changes. Should this get stored in the database?
Bob
 
I program the majority of the work. The person setting up proofs out the program. I will discuss with them what I did if it's out of the ordinary, but they post it, so they have the ability to view the program before running it. Then if edits need to be made they either talk to me and we work it out together, or they just make the necessary changes and let me know for future information. There's no reason to have two people watching a program run if they can quick walk through it and simulate it in cam(unless they're green).
 
To answer some questions:

We're a fairly large operation. We have about 30 machines in production and 3 in development. The people operating in development are operator-only. The guys in R&D do their own setups. We have ONE person programming for both the production shop and the new development shop.

You mean the G code gets changed at the machine and then saved? Does the cam file ever get updated to reflect what changed at the machine?

Sometimes yes and sometimes no. Its supposed to be sent back to the programmer to be saved but it often doesn't happen that way.
 
Surely the right way is to make this a two stage process.

Set-up guy proves out the initial program making any changes to the original code to get it running safely and at least acceptably fast to be the first version of the shop floor master.

Machinists then use their experience to improve, speed-up, or whatever the program so it works better on the floor. Operator changes need to be discussed and reviewed before a new improved shop floor master is saved. Review process sounds formal but it doesn't have to be. Main thing is to make a note of the changes relative to the original code. As time goes on you will build up a list of useful changes and when to use them. Such lists can be very informative as they produce in context data to help with tooling et al selection.

If you have an established and effective way of programming the initial code its often quicker and easier to simply sub in the "works better this way on our machines" after proving out the initial version than it is to try to produce a "works best on our machines" version immediately.

Naturally you always keep the original as well as the latest shop floor version.

As with all these organisation things it does depend on the size of the firm, the amount of work done and the types of job undertaken. I figure that once you get past 10 or so guys on the floor you need to start getting formal about things or you never really know where you are or whats going on. Below 4 or 5 you can probably wing it.

Clive

Why is it so sure that thats the right way? The problems with that are that the setup guys cant make changes to the programs except at the controller. Then the file on the floor doesnt match the CAM session. That to me is problematic. And we dont have machinists really, other than myself and the programmer. We have programmer, setup, and operators.

But if the original is kept as the latest shop floor version and a setup guy makes a change at the controller, theres a chance it doesnt get saved back. Then the next time you run the job you have a different cycle time and it screws with your rate, no?

I agree with your last paragraph though, if I owned a shop with a handful of guys I wouldnt be even making a deal about it. But this is a larger operation and im losing my mind with all of the inconsistencies and lack of version history.
 
To answer some questions:

We're a fairly large operation. We have about 30 machines in production and 3 in development. The people operating in development are operator-only. The guys in R&D do their own setups. We have ONE person programming for both the production shop and the new development shop.



Sometimes yes and sometimes no. Its supposed to be sent back to the programmer to be saved but it often doesn't happen that way.

To answer the question of the thread, the programmer runs the job through on the machines here. That's me. If I make any changes at the control I make sure to update the cad/cam file to reflect that, this way the computer has the latest.

Having different people change it at the machine and maybe saving it and maybe not, sounds like chaos. Never mind the different cycle times, what if all of a sudden you are burning up tools where you weren't before? Did the last setup person make a change and not save the nc file? What if a setup person saw the program would have the tool hit a clamp, so they changed it and forgot to save it?
Even better, what if there's a revision to a part so you have to move a hole or make a wall thinner or whatever, now you have to repost the program and then what? Go through all those changes again at the control that have already been done? Or manually add the new changes to the gcode? lol yikes!
I'm nutty about being able to hit the 'post' button and having good code come out, ready to run. Especially on a repeat job.

Bleh. Sounds bad. You have my sympathy.
 
Last edited:
I've setup my shop that whoever programs the part sets the job up the first time. We have $400 solid state terminal computers with 27" screens at each machine so you can remote desktop into your CAM office computer and make tweaks while proving out the first job. No walking back and forth to the office to change things lol. Got so sick and tired of that !
If the job has been repeated 1-2 times and we are happy with cycle times we have one of the younger guys who are learning setup and prove out the first piece. 24 machines in the shop. 15 employees . 4 programmers (1 being myself) with 7 operators only. No "setup" guys.
 
I've setup my shop that whoever programs the part sets the job up the first time. We have $400 solid state terminal computers with 27" screens at each machine so you can remote desktop into your CAM office computer and make tweaks while proving out the first job.

Nice! If it's a long involved program I'll take a notepad out to the machine and write down changes as they're made then fix the cad file when I'm done. It's just 4 machines, an operator and me here though.
 
I've setup my shop that whoever programs the part sets the job up the first time. We have $400 solid state terminal computers with 27" screens at each machine so you can remote desktop into your CAM office computer and make tweaks while proving out the first job. No walking back and forth to the office to change things lol. Got so sick and tired of that !
If the job has been repeated 1-2 times and we are happy with cycle times we have one of the younger guys who are learning setup and prove out the first piece. 24 machines in the shop. 15 employees . 4 programmers (1 being myself) with 7 operators only. No "setup" guys.

Getting slightly off topic, but what equipment and software are you using for those terminals? Been meaning to set that up for ourselves.
 
I write 99% of all milling programs at my shop. I am what I call the gate keeper of all proven programs so I usually decide what gets saved back to the network and what gets deleted. Most of my cad/cam programs get proven out in the shop and when they are done running the programs I usually save them back into the vault for future runs. I have enough trust in my set up guys to save what ever they change without reviewing it. If there are major changes in the program because of tooling, fixturing or maybe oversize stock the guys will let me know and I will update the set up sheets, programs etc.
 
Option 5: It depends

I program for 6 vmc's.(3,4 and 5 axis) Verify and simulate the programs in Mastercam then the operators load them, setup & run them.
If any changes need to be made they tell me and I make the changes and they re-load their programs.
There are extremely rare scenarios where they will make changes such as a carbide drill broke and we need to use a HSS drill and they'll just modify the drill cycle to peck and flood coolant.
 
I'm of the opinion that my code coming off my CAM system should not need to be changed at the machine.
Something doesn't work, back to the office, adjust the model, send out the code and go again.

This right here!

I will never understand how/why shops use the .nc as a "master" and not the CAM file.
I save basically zero .nc files.
 
Even better, what if there's a revision to a part so you have to move a hole or make a wall thinner or whatever, now you have to repost the program and then what? Go through all those changes again at the control that have already been done? Or manually add the new changes to the gcode? lol yikes!
I'm nutty about being able to hit the 'post' button and having good code come out, ready to run. Especially on a repeat job.

Bleh. Sounds bad. You have my sympathy.

This right here!

I will never understand how/why shops use the.NC as a "master" and not the CAM file.
I save basically zero .nc files.

I'm in this boat.

What do you do for rev changes using the NC file as master? Cut 'n paste crap every time? I prefer to just modify cam file and repost. Done.



Also sounds like some guys in this thread have multiple different NC files floating around. Some on server, some on machines, maybe some "hard copies" in binders? (although that guy hasn't replied yet) If people are editing at machines, what happens when you have a mis-match? Rev change doesn't get applied second time and the customer gets a down-rev part? Yikes...


How about if you want to run a program on a different machine/control? I'd prefer to just click 'post' and have perfect code with all the original edits there. Can't do that so easily with a "NC Master file".

In my book, editing at the control to use for next time is nothing but a waste of time and adding more potential for error.
 








 
Back
Top