Tips to establishing a world class programming department?

[Jespertech]

After years of grinding it out on the floor the powers that be have blessed me with the opportunity to wrangle in our programming cowboys, slap a "department" tag on them and refine this into a high functioning "world class" programming department.... Yippy. 

My hope with this post is to get examples of well-rounded programming departments that you all have been a part of.

What made them successful?  what made them fail?

Is there specific training offered that can help improve the utilization of machine definitions, tool/holder libraries and setup sheets that will keep these boys in their (Mcam) seats. and not have to run in every job that gets posted to the floor.

I have already reached out to my local reseller and will be discussing options with them on Monday but seeing as how I owe most of my programming success to this forum. I wanted to get real advice from you guys as well. 

 Thanks for the time. 

[cncappsjames]

Make sure everyone in the department uses the same posts. There's multiple ways to handle that and which way works best depends on your IT Infrastructure.

Create a method for setup guys to put program change orders in.. amd when practical MAKE THE CHANGES. This way setup guys feel some ownership in the process and heads off the need for han-edits at the machine.

Figure out each guy's strengths and weaknesses. If you can, 80% of the time give them projects that will challenge them and 20% of the time give them something they can crush.

Work from common tool libraries and use common workholding whenever/wherever possible. Make sure you've got your holders in the tool library too.

Reward excellence, not only programmers that put out quality programs, but that try new things AND SHARE with their peers. There's no room for the guys that keep stuff to themselves anymore. Those days are gone. We can't keep hurting ourselves because some guy's fragile ego can't handle competition.

 

Just a few thoughts off the top of my head.

[#Rekd™]

Create a standard for levels such as doing them in intervals of 10. Possibly having fixtures on a dedicated level in all files if possible. Have a dedicated level for Notes on the part/ job and programming so anyone that opens the file can view these. 

Implement the use of View Sheets to easily pick views and or levels.

If there isn’t anything currently in use create a logical file storage structure system for storing and accessing files. Try to have all files for each part or job contained in the same folder whenever possible. Have a revision naming policy so everyone follows the same process.

Develop a verification process that everyone will follow when G-Code is created. 

Insist on having comments added in every tool path. 
 

I have HSM Advisor for speeds and feeds. We use a lot of Helical Solutions/ Harvey tools, their machining advisor is excellent. 
 

 

 

 

 

[sharles]

Four years ago we had our posts updated, had our reseller make us custom machine simulation models of our machines and we spent 6 months drawing all our tools, holders and extensions into the stand-alone tool library that we all share on our server. And we added Varco Reports to give a printout how to build every tool needed for a job. That took us out of the 'fingers-crossed' mode of programming and into a confidence of knowing our toolpaths would work as long as long as we follow our procedures to Verify and Machine Simulate everything.

I still wish our employer would support more training and standardization in our department, but at least I no longer 'hope' my programs will work.

[Jobnt]

On 7/15/2023 at 7:46 PM, cncappsjames said:

Create a method for setup guys to put program change orders in.. amd when practical MAKE THE CHANGES.

Yup. Nothing worse than having two (or twenty) different versions of NC files and Mastercam files. When a change is made on the floor it has to be made upstairs too. 

[SuperHoneyBadger]

On 7/15/2023 at 10:46 PM, cncappsjames said:

Create a method for setup guys to put program change orders in..

We have a standardized grid sheet made up with tool#, N#, XYZ Δ's, speed, feed and notes. If they change something to make the program run more smoothly, I'm all for it, just LET ME KNOW BOYS.

On 7/16/2023 at 7:59 AM, #Rekd™ said:

Create a standard for levels such as doing them in intervals of 10. Possibly having fixtures on a dedicated level in all files if possible. Have a dedicated level for Notes on the part/ job and programming so anyone that opens the file can view these. 

Implement the use of View Sheets to easily pick views and or levels.

Levels and view sheets are a MUST, big +1. I like to keep a consistent system for myself, and if we were to train any additional programmers, I would insist they use the templates I have set up when starting new parts so that our levels and setup sheets would align.

There are a huge amount of older NC files here that I didn't program, and have never seen. When they get ordered, I take the time to reorganize/comb through so I can help with any issues on the fly. I hate that feeling of someone breathing down my neck while I decipher some whackadoodle toolpath that hasn't been posted since X6, and just snapped a 3/4" 2FL. So I check them first now, as time allows.

[Aaron Eberhard]

Equally important (perhaps more?) to tool libraries is operations libraries.  They're one of the biggest programming time & part quality improvement tools available if you learn to really leverage them.   The problem is that it's a bit tedious to get them set up.  

The most successful shops I know have a programmer whose responsibility it is to manage those libraries.   That's part of their job.  Plan on it eating up 100% of their time for the first month or two, then 10-20% of their time per month for the next few months as things are smoothed out.  It will also require monthly maintenance. 

BUT

If you do it correctly, you will be establishing processes and procedures that that ensure that every time a, say, 1/4-20 hole is tapped into 320 SS at your company, it's done the same way, with the same tools, at the same feeds & speeds.    It will take the programming time for an individual programmer to do those three ops (or whatever) from 20 minutes to 1.   Every time they program those holes.   It will allow you to bring a new guy up to speed by pointing out how to import/export, so there won't be a quality drop on stupid things while he's brought up to speed.

This will also reduce the tedious parts of being a programmer.   No one is ever excited to program a 1/4-20 hole.  You've done it thousands of times.  So why not remove most of the work and (almost!) all of the simple little screw ups that come with creating toolpaths over and over again?

Feel free to give me a shout via email or message and I can explain a bit more in detail if you'd like.

[sharles]

1 hour ago, Jobnt said:

Yup. Nothing worse than having two (or twenty) different versions of NC files and Mastercam files. When a change is made on the floor it has to be made upstairs too. 

For us as a pattern shop, and most of our jobs are unique, I hate it when we get a repeat job, and the toolpaths don't work...or the toolpaths do something wrong...and it's like why didn't we know about it the first time????

[Jobnt]

52 minutes ago, Aaron Eberhard said:

Equally important (perhaps more?) to tool libraries is operations libraries.  They're one of the biggest programming time & part quality improvement tools available if you learn to really leverage them.   The problem is that it's a bit tedious to get them set up.  

The most successful shops I know have a programmer whose responsibility it is to manage those libraries.   That's part of their job.  Plan on it eating up 100% of their time for the first month or two, then 10-20% of their time per month for the next few months as things are smoothed out.  It will also require monthly maintenance. 

BUT

If you do it correctly, you will be establishing processes and procedures that that ensure that every time a, say, 1/4-20 hole is tapped into 320 SS at your company, it's done the same way, with the same tools, at the same feeds & speeds.    It will take the programming time for an individual programmer to do those three ops (or whatever) from 20 minutes to 1.   Every time they program those holes.   It will allow you to bring a new guy up to speed by pointing out how to import/export, so there won't be a quality drop on stupid things while he's brought up to speed.

This will also reduce the tedious parts of being a programmer.   No one is ever excited to program a 1/4-20 hole.  You've done it thousands of times.  So why not remove most of the work and (almost!) all of the simple little screw ups that come with creating toolpaths over and over again?

Feel free to give me a shout via email or message and I can explain a bit more in detail if you'd like.

Excellent point. 

Do you use tool's speed/feed/doc etc or the material's?

 

[sharles]

1 hour ago, Aaron Eberhard said:

Equally important (perhaps more?) to tool libraries is operations libraries.  They're one of the biggest programming time & part quality improvement tools available if you learn to really leverage them.   The problem is that it's a bit tedious to get them set up.  

The most successful shops I know have a programmer whose responsibility it is to manage those libraries.   That's part of their job.  Plan on it eating up 100% of their time for the first month or two, then 10-20% of their time per month for the next few months as things are smoothed out.  It will also require monthly maintenance. 

BUT

If you do it correctly, you will be establishing processes and procedures that that ensure that every time a, say, 1/4-20 hole is tapped into 320 SS at your company, it's done the same way, with the same tools, at the same feeds & speeds.    It will take the programming time for an individual programmer to do those three ops (or whatever) from 20 minutes to 1.   Every time they program those holes.   It will allow you to bring a new guy up to speed by pointing out how to import/export, so there won't be a quality drop on stupid things while he's brought up to speed.

This will also reduce the tedious parts of being a programmer.   No one is ever excited to program a 1/4-20 hole.  You've done it thousands of times.  So why not remove most of the work and (almost!) all of the simple little screw ups that come with creating toolpaths over and over again?

Feel free to give me a shout via email or message and I can explain a bit more in detail if you'd like.

That's something I've struggled with as a pattern shop. I do tons of importing from previous, similar jobs, but setting up a library of operations when every single job is slightly different even when doing similar parts for the same customer....it would probably be worth our time because we at least wouldn't start from scratch, though I'm not the CAM supervisor and so it's not really my call...

[Bill Craven]

One of the thiings that I implemented at a shop many, mnay years ago was: The Accounting department couldn't close a job until the programmer brought them the finish Mastercam files (Z2G so they had the post that they used), setup documentation, and the finish programs downloaded from the machine.  Then those filles were saved to a secure server with prints, run times, etc.

Too many times we had repeat jobs and the original programmers couldn't find the original programs (that they were storing on floppies in their toolboxes) and we had to go back to square one.  Or if they did find the Mastercam file, it was not the latest one and the NC files had been modified extensivley at the machine becasue their posts were not error free.

 

At another shop, I  implemented saving Mastercam feature operations as seperate Mastercam files that were used as example files that had worked well and saved to a special library on the server.  Similar to maintaining operation libraries.  But this was easier for the programmers to review and then incorporate into their new programs.

 

One shop I went into had a sign in the office as a joke:  "We are too busy to get organized"  But it was true for them and they suffered for it.

[Aaron Eberhard]

16 minutes ago, sharles said:

That's something I've struggled with as a pattern shop. I do tons of importing from previous, similar jobs, but setting up a library of operations when every single job is slightly different even when doing similar parts for the same customer....it would probably be worth our time because we at least wouldn't start from scratch, though I'm not the CAM supervisor and so it's not really my call...

I think there's a lot of people in your boat, where you (the programmer) have to actually remember what file # you last worked with this material, then find the file, then remember which operation was the one that worked well, etc..   That's the real power of being organized into ops libraries.  

Even if the jobs are slightly different, you're often going to reach for the same .500 .03R endmill to rough aluminum less than X deep, right?  That should be an operation available to all programmers to import.

To use a real world example, I did a bit of a "back of the envelope" time study with one of the companies I was helping out.  This was a prototype/low-production kinda place, rarely more than 50 of any one piece, most were 1 or 2.   We took of couple of their average parts (one aluminum, one steel, one titanium) and figured out three different roughing op cut times, using a .5", ..625", and .75" roughing endmill.    We ended up figuring out that for their average part (which fit in a 12"x6"x3" volume), the cycle time difference between using a .625 or .75" cutter was often offset by additional semi-finish/rough passes to remove additional material left. 

When doing less than 20 of those parts, none of the scenarios saved more time using a larger cutter than it would take to look up/order/purchase/assemble/program/etc. a newer/different tool.   

What those guys ended up doing was choosing a few broadly usable cutters (.25, .375, .5, .75 if I recall correctly), and established a library of ops using those to rough.  We figured out that they would save ~80-90% of their programming time doing this, and the cycle times were only really at worse 5-10% longer that using the "perfect" tool, but would most likely end up being net faster, because no one accidentally set the stepover to 13% when it was supposed to be 17% for that material.  The programmers were fully allowed to use others as needed, but the expectation was that there had to be a justifiable reason to spend the additional time.  

[sharles]

40 minutes ago, Aaron Eberhard said:

I think there's a lot of people in your boat, where you (the programmer) have to actually remember what file # you last worked with this material, then find the file, then remember which operation was the one that worked well, etc..   That's the real power of being organized into ops libraries.  

Even if the jobs are slightly different, you're often going to reach for the same .500 .03R endmill to rough aluminum less than X deep, right?  That should be an operation available to all programmers to import.

To use a real world example, I did a bit of a "back of the envelope" time study with one of the companies I was helping out.  This was a prototype/low-production kinda place, rarely more than 50 of any one piece, most were 1 or 2.   We took of couple of their average parts (one aluminum, one steel, one titanium) and figured out three different roughing op cut times, using a .5", ..625", and .75" roughing endmill.    We ended up figuring out that for their average part (which fit in a 12"x6"x3" volume), the cycle time difference between using a .625 or .75" cutter was often offset by additional semi-finish/rough passes to remove additional material left. 

When doing less than 20 of those parts, none of the scenarios saved more time using a larger cutter than it would take to look up/order/purchase/assemble/program/etc. a newer/different tool.   

What those guys ended up doing was choosing a few broadly usable cutters (.25, .375, .5, .75 if I recall correctly), and established a library of ops using those to rough.  We figured out that they would save ~80-90% of their programming time doing this, and the cycle times were only really at worse 5-10% longer that using the "perfect" tool, but would most likely end up being net faster, because no one accidentally set the stepover to 13% when it was supposed to be 17% for that material.  The programmers were fully allowed to use others as needed, but the expectation was that there had to be a justifiable reason to spend the additional time.  

My supervisor is going to semi retire at the end of this year. He doesn't use mastercam and he's always resisted standardizing things for some reason, but this is definitely something to keep in mind whether I or someone else takes over after he steps back a little. I know I and my one, fellow mastercam user at my shop would love to see more standardization of things; not only to cut down mistakes but to stop the bellyaching of the operators who complain that each of us cam guys does things a little differently even though we all get to the same destination: a good, finished part.

[Newbeeee™]

To add to the excellent advice.... i'll add "standardisation of doing things".

That's from dealing with Customers (incoming) electronic data (Network folder by Customer>Part Number AND ISSUE) etc, to the way they  use Mcam and the way they 'gram.

Everyone does things differently - but as already pointed out - mandate same posts, tool library, file creation (level naming etc) etc - is VERY important.

Big white board of who is working on what project so everyone knows what's on the go and dates etc.

Then their workflow - such as firstly ORDER ANY SPECIAL CUTTERS FIRST SO YOU'RE NOT WAITING DUMASS  , prog, verify and file compare, run X+ to check datums + coolant etc, Post, run posted code through backplotter or Vericut or ?etc, then create setup sheet, fixture drawing etc etc so you're handing over something with confidence - a basic flow sheet of your agreed process for all to see WITH EVERYONE's buy-in is good IMHO.

And when people cut corners, you gotta pull them up.

LoL @ "world class" though   

[Aaron Eberhard]

Oh, one other thing to managing a good team..  Build in a half-hour "meeting" to hang out with some good coffee or other motivating thing every week or two, and make everyone share something they did or learned that was cool since the last time you got together.   It could be something simple ("I learned how to do X by reading the tips & tricks thread!") or some new workholding they learned about ("Hey, have you guys heard about Blue Photon?").  

A lot of stuff that us old guys take for granted can be nice little speed "tricks" for the team.

For example, literally last week I showed someone that in Windows explorer, if you're looking at a list of files, you can just start typing the file name you're looking for and it'll jump to it.   That's the sorta thing that will save him 4 or 5 minutes a day.  It adds up.

[#Rekd™]

11 minutes ago, Aaron Eberhard said:

Build in a half-hour "meeting" to hang out with some good coffee or other motivating thing every week or two,

This is an example of continuous improvement.....have time for everyone to input ideas/ suggestions.

[Aaron Eberhard]

Just now, #Rekd™ said:

This is an example of continuous improvement.....have time for everyone to input ideas/ suggestions.

Yep, but I take it a bit further and expect everyone to find something interesting worth talking about for the team.  It gives everyone some skin in the game, plus an organized time to do it.  It's like the first step to making that shy person into an active contributor

[Aaron Eberhard]

I was thinking about this a bit more, and I realized I forgot the most important part that no one has talked about:

Managing up.

Obviously you'll have your work cut out for you getting all the grumpy guys who have been "doing it this way" "forever," but the biggest thing I see that hurts programming departments (well, really, any sort of mental/creative work departments) is unclear expectations from management.  Make sure that they understand that this isn't going to be a lightswitch.   You're not going from the wild west to civilization overnight.

Assume that if the guys have been doing it this way for the past 20 years (including you), it takes a while to turn the ship around and get everyone to accept that the new structure actually does make things a lot better in the long run.  And be prepared to let one or two of them go if they can't get their act together and work with the team after some time.  Bob Wolcott has outlined some great thoughts on this on here throughout the years.

You will be responsible for understanding management's viewpoint (i.e., $$$).  This is a capital investment.  It's like building a custom machine for your shop.  It's going to take potentially tens of thousands of dollars for each component of it and each part is useless until it's basically complete.

A guy paid $100k/yr (company pays a total of $150k/yr after benefits) has to work on building a comprehensive tool library for a big shop, that's a potentially a 4 week project.  That means that the company is going to be paying $12,500 in salary for that library.  And it's functionally useless until he's done.  He's also not programming while he's doing it.  The entire shop is losing that productivity (each employee should make at least 3x what their salary is to keep things sustainable), so the company is now $37,500 behind because you guys get a tool library.    Imagine if you paid $37,500 for a tool, and mistakes that tool could solve keep being made on the shop floor?  That's how management should be thinking about it if screw ups keep happening because someone isn't following the new paradigm.

I would outline a rough roadmap of your goals and plans with management, and make sure they understand that it will take real time from knowledgeable programmers that they will not be doing production programming because they're going to be focusing on (make a list of) managing tool libraries/ops libraries/configurations/whatever else.  Negotiate how much of the programmers' time you're allowed to devote to implementing the new libraries or whatever.  

You need to be a project manager now, not a programmer.   It's a real full-time job for a reason.   Take that list of what you're going to deliver to the company.  Break each component out as a line item.  Try to ballpark how long it will take in man-hours.   Now add that up.  I'll bet you end up with darn-near a full year of man hours.  As a note, 1600 is an acceptable ballpark for a yearly hour load, we always assumed that a great day for this sort of work was actually ~6 hours of productivity.  Meetings/planning/overhead will erode the common "2000 hours of work" a year.  This is now the hardest part of the job.   Is Johnny boy actually working properly on the tool library?  Is Jimmy properly using the new tool library, or is still randomly defining tools because "it's faster?"  Does he need more training?  Does something need to be changed to be easier to use?  Are you communicating milestones and progress correctly in a way your management understands?  Do you have any metrics you can look at about how your improvements are helping your turn around time/job reliability/tool life & management improvements/down-time reduction/etc.?

Good luck, you're now stuck in the middle.  The dreaded Middle Manager!

[Newbeeee™]

22 hours ago, Bill Craven said:

At another shop, I  implemented saving Mastercam feature operations as seperate Mastercam files that were used as example files that had worked well and saved to a special library on the server.  Similar to maintaining operation libraries.  But this was easier for the programmers to review and then incorporate into their new programs.

 

This!

IME, usually shops tend to specialise in a "type of work"....so when something different appears, it can be a head scratcher. Once it is 'grammed, save a copy of the part  (or more specifically the toolpaths used) naming the part "Multi-part Transform Rotate" (or whatever) - but something that you can easily find again in the future within the "examples directory".

I also have a notepad file of unusual tools - predominantly long and specials with all the (working) info and stickout speeds and feeds DOC's mtl etc. Only because our tool library wasn't as good as it should have been....

[Newbeeee™]

27 minutes ago, Aaron Eberhard said:

I was thinking about this a bit more, and I realized I forgot the most important part that no one has talked about:

Managing up.

Obviously you'll have your work cut out for you getting all the grumpy guys who have been "doing it this way" "forever," but the biggest thing I see that hurts programming departments (well, really, any sort of mental/creative work departments) is unclear expectations from management.  Make sure that they understand that this isn't going to be a lightswitch.   You're not going from the wild west to civilization overnight.

Assume that if the guys have been doing it this way for the past 20 years (including you), it takes a while to turn the ship around and get everyone to accept that the new structure actually does make things a lot better in the long run.  And be prepared to let one or two of them go if they can't get their act together and work with the team after some time.  Bob Wolcott has outlined some great thoughts on this on here throughout the years.

You will be responsible for understanding management's viewpoint (i.e., $$$).  This is a capital investment.  It's like building a custom machine for your shop.  It's going to take potentially tens of thousands of dollars for each component of it and each part is useless until it's basically complete.

A guy paid $100k/yr (company pays a total of $150k/yr after benefits) has to work on building a comprehensive tool library for a big shop, that's a potentially a 4 week project.  That means that the company is going to be paying $12,500 in salary for that library.  And it's functionally useless until he's done.  He's also not programming while he's doing it.  The mean's the entire shop is losing that productivity (each employee should make at least 3x what their salary is to keep things sustainable), so that means the company is now $37,500 behind because you guys get a tool library.    Imagine if you paid $37,500 for a tool, and mistakes that tool could solve keep being made on the shop floor?  That's how management should be thinking about it if screw ups keep happening because someone isn't following the new paradigm.

I would outline a rough roadmap of your goals and plans with management, and make sure they understand that it will take real time from knowledgeable programmers that they will not be doing production programming, because they're going to be focusing on (make a list of) managing tool libraries/ops libraries/configurations/whatever else.  Negotiate how much of the programmers' time you're allowed to devote to implementing the new libraries or whatever.  

You need to be a project manager now, not a programmer.   It's a real full-time job for a reason.   Take that list of what you're going to deliver to the company.  Break each component out as a line item.  Try to ballpark how long it will take in man-hours.   Now add that up.  I'll bet you end up with darn-near a full year of man hours.     This is now the hardest part of the job.   Is Johnny boy actually working properly on the tool library?  Is Jimmy properly using the new tool library, or is still randomly defining tools because "it's faster?"  Does he need more training?  Does something need to be changed to be easier to use?  Are you communicating milestones and progress correctly in a way your management understands?  Do you have any metrics you can look at about how your improvements are helping your turn around time/job reliability/tool life & management improvements/down-time reduction/etc.?

Good luck, you're now stuck in the middle.  The dreaded Middle Manager!

On top of this superb post, which underlines the fact that putting on the managers hat and big-spurred cowboy boots, is, the easy bit it would be worth discussing this with the accounts dept or "someone who knows" if any project investments and cost-kickbacks, are available? 

Because if you launch this out as a proper structured project, and time sheet it and cost it as a proper project, you may be eligible for the project cost to be written off against the company taxes. Which means it possibly won't cost anywhere near as much money, Aaron laid out. In the EU, there's free money thrown everywhere for things like this (training).... 

 

[Jobnt]

19 minutes ago, Newbeeee™ said:

Aaron laid out. In the EU, there's free money thrown everywhere for things like this (training).... 

It's here in Commiefornia too. We got tax breaks for developing new processes at the "old place". Once a year I would have to do a couple of worksheets with projects we did that challenged us where I would explain the project scope, the expected process, the hurdles and the new processes we developed to overcome the hurdles.

[Aaron Eberhard]

21 minutes ago, Newbeeee™ said:

On top of this superb post, which underlines the fact that putting on the managers hat and big-spurred cowboy boots, is, the easy bit it would be worth discussing this with the accounts dept or "someone who knows" if any project investments and cost-kickbacks, are available? 

Because if you launch this out as a proper structured project, and time sheet it and cost it as a proper project, you may be eligible for the project cost to be written off against the company taxes. Which means it possibly won't cost anywhere near as much money, Aaron laid out. In the EU, there's free money thrown everywhere for things like this (training).... 

 

Putting on the big hat and cowboy boots with spurs is just part of our daily routine over here   You wouldn't understand...

Seriously, good call on that.  Yes, there's all sorts of tax breaks/grants/etc. available over here for process improvements & organizational restructuring.   Look into your state's Manufacturing Extensions Program (MEP) if you guys haven't, they can likely get you in touch with the correct accountants if no one at your org knows who talk to.  For example, I've worked a bit with the CT & Mass groups (CTSTEP and MASSMEP). 

[Newbeeee™]

1 hour ago, Aaron Eberhard said:

Putting on the big hat and cowboy boots with spurs is just part of our daily routine over here   You wouldn't understand...

 

Oh I do and I'm so jealous  

Deep South and a Mustang would do me fine!

[Matthew Hajicek - Singularity]

As you revise and improve your programs, follow a revision naming / numbering system for both your Mastercam files and NC files.  You can record which NC file versions were used on which lots of parts, so if a problem with a part is later discovered, you know exactly which program made that part; you might have already fixed it in the next program revision.  This also helps you to backtrack if a program change doesn't work out as hoped.