What's new
What's new

Who should choose tool holders

N.Mariniak

Plastic
Joined
Oct 10, 2018
We are small company and I am up to the task of changing how things were done in the past.

Up to now the lathe guys did the programming on the machine and chose their tools/holders. The plan is that a CAM programmer would write programs on CamWorks for all 4 guys so they have more time running parts instead of writing code.

I think he should also choose the correct insert radius and grade, and select the appropriate tool holder.

This is where the dilemma comes. Some think he should select only the insert and the lathe guys should select the holder. But I think if he selected the correct holder and tested it against collisions why should the lathe guys do the same job again.

Please, tell me what do you the think.
 
If you are going to have someone program offline then they should be responsible for everything. There is no reason to have some guy sitting at a desk chaining geometry all day if the speeds and feeds they are inputting are incorrect. The programmer should be talking to the guys on the shop floor for input to their best practices since up to this point they have been the ones dealing with the parts.
 
As Hazzert says, the programmer has to be driving the processes.

It's undoubtedly not a welcome change for the machinists on the floor and they may feel their value being diminished, but they'll have to get over it.

If your programmer is just choosing inserts and not holders then there could be a mismatch leading to over/undercutting causing scrap or a collision from clearances not being vetted.

The direction you're going is the best plan as shops grow. It's just very difficult to get everyone out of the job shop mindset.

Sent from my SM-G965U using Tapatalk
 
Yes, the programmer should pick the holders as well BUT with the input of the machinists. I have seen an arrogant programmer who was not a team player. He was despised (and not near as good as he thought he was). While I agree that "they'll have to get over it", you'll have to remember that you're part of a team. I recommend treading lightly and convincing rather than dictating.
 
Yes, the programmer should pick the holders as well BUT with the input of the machinists. I have seen an arrogant programmer who was not a team player. He was despised (and not near as good as he thought he was). While I agree that "they'll have to get over it", you'll have to remember that you're part of a team. I recommend treading lightly and convincing rather than dictating.

Yes...and moving one of the older, more experienced lathe operators
up to be the programmer in the office, could go a long way
to this end.
 
The company I'm working for(for now) is trying to do this same thing , only the "programmer" is the young ,know nothing but has it all figured out guy(2years but refuses to do hard jobs) and I've had to continuously re-write the few programs he had to do for me ,thus cut machining times considerably( 2min off a 4-5min program sort of thing), thus far I've been able to keep doing my own mostly on an old computer with MC , not the new software they only trained the young guy on . Moral of the story , does no good to have a separate programmer if not using those with actual experience , then it'll be a good system . It's actually costing them a 27 year veteran machinist , going out on my own now .


.
 
I've never understood the concept of having a "dedicated" "programmer" that doesn't go out
and set the machines up and prove the program out, and tweak it all in, and optimize it.

Kind of like a chef that doesn't taste what they are cooking.
 
I've never understood the concept of having a "dedicated" "programmer" that doesn't go out
and set the machines up and prove the program out, and tweak it all in, and optimize it.

Kind of like a chef that doesn't taste what they are cooking.
Even in a 2 to 3 man shop, there are many of my programs I've never seen run. My main guy knows what I'm after, knows what it should look and sound like, and will come in the office and ask, "What were you thinking!?" if I pull a real boner, or have me come out and watch it if he doesn't know how to communicate what he is seeing that could be done better.

I still go out to the shop and check shit out, but that's mainly because I need to get my fat ass out of the chair once in awhile.
 
I've never understood the concept of having a "dedicated" "programmer" that doesn't go out
and set the machines up and prove the program out, and tweak it all in, and optimize it.

Kind of like a chef that doesn't taste what they are cooking.

A couple of years ago I would likely have agreed with you, but lately I've been doing more and more of just programming and hand off. When you program and run enough of the same kind of thing you get muscle memory for it, I can program a cut and see it running in my head. You have to know the other guy like the back of your hand, know how to communicate with him and know how he thinks.

Stuff that I'm less familiar with I will always run myself first.
 
Even in a 2 to 3 man shop, there are many of my programs I've never seen run. My main guy knows what I'm after, knows what it should look and sound like, and will come in the office and ask, "What were you thinking!?" if I pull a real boner, or have me come out and watch it if he doesn't know how to communicate what he is seeing that could be done better.

I still go out to the shop and check shit out, but that's mainly because I need to get my fat ass out of the chair once in awhile.

Pretty much this. We do mostly 1 or low quantity parts. If I setup every job I would just be running every job. Anything sketchy I will go hang with the guy running it to make any adjustments on the fly but I generally go by the adage “no news is good news” as far as my programs go and try and keep everything as consistent as possible across similar part styles.
 
I don't see how you can program at all without knowing what holders will be used. How do you set speeds and feeds? How do you calculate deflections? How do you know you won't crash into tooling? If the guy programming doesn't know that stuff, why is he programming at all?

But my stuff tends to be smaller than most. Maybe you can just assume absurd stickouts and very conservative speeds and call it a day. I have certainly seen that.

Once you move programming off the floor the guys on the floor are now operators. That's fine, a good operator is worth a lot. But if you're doing that, realize that is what you are doing and don't go half measures.
 
I've never understood the concept of having a "dedicated" "programmer" that doesn't go out
and set the machines up and prove the program out, and tweak it all in, and optimize it.

Kind of like a chef that doesn't taste what they are cooking.

I've been in the position of being the chef not allowed to taste my own cooking. At my previous job I would get yelled at if I went out on the shop floor to see how something was running or talk to the operators. Had to program blind, with all methodology changes coming though and largely dictated by the boss's son. Place got bought soon after I left, boss's son got a job elsewhere as a machine salesman.
 
Yikes. Well, IMO and from the business I have worked with...
There should always be good communication between programmers and operators. To dismiss dedicated roles because an employee is inexperienced, a bad communicator, lazy or whatever the case, is not a good enough reason to bail on an efficient, industry standard roles in a manufacturing environment. Those are personnel issues; not structure issues. I have seen those problems with small companies that are growing and it's always important to have the right person for the task at hand and it's not that difficult to employ the right people. I love this industry but i think we can all agree this isn't exactly rocket science.

Garage shops need to have people in multiple roles but as a business grows it is necessary to define dedicated roles. A long time ago we had machine/manufacturing engineer have us try operators programming at their machines because he had numerous success stories to back it up. Back then we had one person at each machine and we gave it a try but it turned out that model was not a fit for our type of work. It was an utter failure because spindle time dropped drastically. We have had dedicated programmers for a long time now and the operator to machine ratio is about 1:3.5, spindle on-time is the best we've have ever had and we are outputting more than double the work we used to but with half the personel. Do we have room for improvement? Always. When the process starts to come off the rails it is always because of a lack of communication between programmers and operators or it is the operators deviating from established best practices which are outlined as standard procedures. As for the programmers we never, ever use anyone not suited for for it nor without experience and the only time we hired a fresh programmer was to fill a position programming simple, prismatic work.
 








 
Back
Top