Hey guys/gals I am wondering how you and your CMM are used. aside from CMM operator, what titles do you carry? many? Engineer? Programmer? Metrologist?
My current title is 'CMM Programmer'. It's a sweet gig. I program offline 95% of the time, the other 5% is on the CMMs verifying the programs I wrote for the first time. There are 2 other CMM Programmers here as well. The CMMs are operated most of the time by full time CMM Operators. We make low quantity runs of aerospace parts, so most programs will only be needed a handful of times. The only downside to this setup is that there only a few CMMs and a lot work going through them. When I write a program I need it to be right the first time, there are no opportunities to test and tweak things at the CMM.
I have worked other places with different titles and different responsibilities in addition to CMM programming. I have worked at high volume repetitive work type places where I programmed the CMMs so that anyone in the shop could operate them to measure their parts. That worked better than I would have thought. It was lots of work to dummy-proof things and fix things here and there, but empowering the machinist to measure their own parts really improved part quality, turnaround, and interdepartmental moral.
I have also had jobs that are full time at the CMM both programming and operating. It can be nice for learning, but unless it is at a small company I don't think it is a good way of structuring things. It can really turn an individual into a resentful bottleneck. Though, I have heard of companies that make it work by just having a surplus of both CMMs and programmers. Each programmer is basically the 'owner/operator' of an assigned machine. I imagine that system could work really well in a lot of ways, especially when growing talent. Also, it keeps things interesting. Just programming or just operating all the time can get kinda dull.
I don't think there is one best way to structure the tasks of CMM programming and operating. It depends on the type of parts being measured, the quantity involved, how they are manufactured, lead time, etc.
My current title is 'CMM Programmer'. It's a sweet gig. I program offline 95% of the time, the other 5% is on the CMMs verifying the programs I wrote for the first time. There are 2 other CMM Programmers here as well. The CMMs are operated most of the time by full time CMM Operators. We make low quantity runs of aerospace parts, so most programs will only be needed a handful of times. The only downside to this setup is that there only a few CMMs and a lot work going through them. When I write a program I need it to be right the first time, there are no opportunities to test and tweak things at the CMM.
I have worked other places with different titles and different responsibilities in addition to CMM programming. I have worked at high volume repetitive work type places where I programmed the CMMs so that anyone in the shop could operate them to measure their parts. That worked better than I would have thought. It was lots of work to dummy-proof things and fix things here and there, but empowering the machinist to measure their own parts really improved part quality, turnaround, and interdepartmental moral.
I have also had jobs that are full time at the CMM both programming and operating. It can be nice for learning, but unless it is at a small company I don't think it is a good way of structuring things. It can really turn an individual into a resentful bottleneck. Though, I have heard of companies that make it work by just having a surplus of both CMMs and programmers. Each programmer is basically the 'owner/operator' of an assigned machine. I imagine that system could work really well in a lot of ways, especially when growing talent. Also, it keeps things interesting. Just programming or just operating all the time can get kinda dull.
I don't think there is one best way to structure the tasks of CMM programming and operating. It depends on the type of parts being measured, the quantity involved, how they are manufactured, lead time, etc.
