hexagon logo

CMM Operator Training

How do you train your operators? Any advise is welcome. Don't be a turd.

We have been intermittently slow at work so I have been building basically a curriculum to train new operators (we are expecting to hire people at the beginning of the year).

My "Curriculum" is basically just notes on how to run the CMM, but with some pictures and a few step by step guides. I have used one of my hand mic guys as a path finder/Guiney pig and it seems like every time I get done with a training section there are so many things that I have left out that he immediately stumbles over.

Idk I am pretty good at explaining things in person but putting them down on paper is a bit harder.


  • I tried something similar, with the tests. Problem was, our training system was set up to where a score of less than 80% was a failure nd required corrective actions and such. You either passed an assessment or there was an issue with the training that had to be addressed. We started writing multiple choice questions with obvious answers i.e.:

    What are the key parts of an alignment:
    A) Level, rotate, and origin
    B) Wash, rinse, repeat
    C) Only management is allowed to alignment
    D) All the above

    Best part was, management couldn't figure out how people never knew anything but passed training tests with 100%.


    LOL!
    I thought about going to a test based system but I think I would really want the tests to be more like practice than an actual test.


  • LOL!
    thought about going to a test based system but I think I would really want the tests to be more like practice than an actual test.


    I never liked tests. It always made people nervous. I would give my trainees a simple Go/NoGo gage and have them measure it or write a program to measure it. Then I would start giving them simple parts. It made them think, it allowed me to see how they wrote code, and created a more fluid way of learning. Now, everyone I trained had experience checking parts to a print without a CMM. So once I explained features, it turned into more or less knowing what needed to be done and just showing how to do it with the software. I also use non technical terms at first and work in the technical as we progress i.e.: In the beginning, how are you looking at the part, from which direction, when you are measuring that? Later on, what workplane are you in when you are dimensioning those features?
  • I've found that if you are going to write a procedure/ training manual etc. that you have to assume the person reading it is a complete idiot who will take anything you write and twist it beyond recognition

    Best thing that happened to me as far as writing technical stuff was a woman named Kathy. She took everything I wrote and applied it as literally as she could. If there was a way to misread something she could do it. She wasn't trying to mess me up, that's just the way her mind worked. I got to the point where anything I wrote I had her read it and do the task. If it passed the Kathy test, no one could mess it up.

    You have to be very aware of your knowledge and the assumed knowledge of your reader. If you write for something well below what you think someone should know to do the job, it will usually come out right.


  • I never liked tests. It always made people nervous. I would give my trainees a simple Go/NoGo gage and have them measure it or write a program to measure it. Then I would start giving them simple parts. It made them think, it allowed me to see how they wrote code, and created a more fluid way of learning. Now, everyone I trained had experience checking parts to a print without a CMM. So once I explained features, it turned into more or less knowing what needed to be done and just showing how to do it with the software. I also use non technical terms at first and work in the technical as we progress i.e.: In the beginning, how are you looking at the part, from which direction, when you are measuring that? Later on, what workplane are you in when you are dimensioning those features?


    Sounds like a great approach. Especially the part about "...once I explained features, it turned into more or less knowing what needed to be done and just showing how to do it with the software". It is easy for someone getting started to worry too much about the process more than the goals and objectives. I always hated that part of learning many things in school. The teachers would drill and drill on how to do something long before they explained why you would do it in the first place.

    Once you have a general idea of what you want to accomplish and the steps you would take to get there, then you can worry about the best way to go about it. Plus in this day and age, you can look up a lot of technical stuff on your own. Maybe even on a online forum!


  • Sounds like a great approach. Especially the part about "...once I explained features, it turned into more or less knowing what needed to be done and just showing how to do it with the software". It is easy for someone getting started to worry too much about the process more than the goals and objectives. I always hated that part of learning many things in school. The teachers would drill and drill on how to do something long before they explained why you would do it in the first place.

    Once you have a general idea of what you want to accomplish and the steps you would take to get there, then you can worry about the best way to go about it. Plus in this day and age, you can look up a lot of technical stuff on your own. Maybe even on a online forum!


    Look at the big picture first then zoom in. That's how I do things.
  • Well put! [plus more words to make at least 10 chars]
  • Cris_C Thanks. Every now and then I'm good with words.
  • I like relating it to a chef-created menu. It's constantly evolving as the chef hones his/her skills. Plus, different cuisines apply to the needs of different restaurants (products).
  • Where I currently am, we have a very small product library, and have massive volume. I am basically the only person who programs. All other folks touching the CMM's only need to know enough to find the routine on the hard drive, open it, load parts onto fixture, place on color-coded magnetic fixture posts, and hit execute.

    I have one WKI, that's BASIC CMM Operations:
    how to power on/off.
    how to make sure machine is active,
    what each button does on jogbox,
    how to recover from a stall/crash,
    how to clean/tighten probe and make sure probe is active,
    How to calibrate probe after a crash,
    how to find and execute routines

    I make sure I cover all of the command input options (keyboard (ex :CTL+Q starts a routine), visual buttons on screen (the triangle execute button), and optional jogbox or file menu method, so at least one way sticks.