hexagon logo

Thread Clocking and Lead In Chamfer Strategy Guidance

Roughly determining the ID thread clocking to locate the thread start for maximum surface area for lead in chamfer diameter measurement. Basically, measuring the countersink of at most 1/3 the circumference of an internal thread entrance. I need to know the thread clocking to even make an attempt.

I understand this is one of those "could you, but should you?" questions, but please humor me, our customer has requested that we try. The threads are small, 5/16s and 1/4in, the countersink diameter doesn't even exceed the major diameter. I think at minimum, one might be able to measure the countersink angle and the radius of the countersink edge to the center of the thread minor with two lines and an intersection point. It doesn't help matters much that nobody actually models threads this small.

Imagine if this was the ONLY thing the program needed to do was this ONE task, to measure the clocking of a small thread.

My guess is, step one would be to locate the minor diameter of the thread and translate my alignment to the intersection of the thread to the surrounding surface. Then come down some distance and use a self-centering 2D vector point to nest my stylus ball between two adjacent thread minor crests. So then I would have a depth measurement from that point to the surface. I would think one could divide that distance by the pitch of the thread to get an integer number and a fractional remainder. If my point was directly below the thread start, the division would result in a clean integer with no remainder. If there is a remainder, then in theory one could relate that remainder to 360° circumference to estimate the thread clocking.

We aren't going to use thread gauges, pins, or tru-pos. The only tools we have at our disposal are the thread, the surface, and the stylus.


Am I on the right track? has anyone tried this before? Are there any productive suggestions? Stylus diameter? self-centering points? scanning?
  • , that makes sense. I can imagine that finding the crest of the thread is easier than finding the low point between the threads. Also, interesting point about the rolled threads. I haven't had to measure rolled threads on a CMM before, but I have seen them have that two minor peaks on the crest thing you are talking about. I'll keep that in mind if it ever comes up.
  • When you solve your controller problems and you have scanning capability again, it's fairly easy to clock to a thread.

    Here are the steps:
    1. Measure the hole and set your X/Y origin to the hole and your Z origin to the surface of the hole. Preferably use a helical strategy.
    2. Scan a line on one side of the hole. For example, when your hole is at X0;Y0, scan a line in the Y+ work plane at the X+ far side of the hole from bottom to top (or the other way). It doesn't matter how long the line is, but you have to stay on the thread.
    3. Determine the high-point of the line in the X- direction. This point will be one the thread tips. It doesn't matter which one it is.
    4. Assign the Z-height of this point to a variable.
    5. The thread pitch is known to you. Divide the Z-value by the pitch height and assign the remainder (the modulo) to a variable.
      You can do this directly by using a modulo division:

      ASSIGN/Remainder=abs(ZValue)%Pitch

    6. If the line you scanned is at the same angle position where the theoretical thread start is, the remainder will be zero. If the thread start is at another angle, the remainder will be greater than zero.
    7. Calculate the clocking angle this way:

      ASSIGN/ClockingAngle=360/Pitch*Remainder

    8. If you want to rotate the X-axis of your coordinate system back to the theoretical thread start, use the clocking angle as a positive value for a right-hand thread and the negative value for a left-hand thread.
    9. Once you know, where the thread start is, you can go about the measurement of the thread any way you like. You could make a helical scan on the thread from two pitch heights down to zero height and find the point where the radius of the minor thread changes drastically, that should be the depth of the chamfer.
  • If you are looking for the diameter of the chamfer, circle scan just below the surface, look at the scan and see where the "bump" is, minindex radially or something, then scan over the edge in four places or three around the chamfer where it intersects the surface and construct a circle from the intersection points..?? quick and dirty, don't know any application where this would be worth wasting so much coding time on.
    Any examples you guys? This is all very interesting and I always learn something new...
    This is how I do it today for tapped holes, I have a global with the x1c head and the FDC controller, thread scanning is buggy...I believe I have had the best results from a properly wire brushed hole. NO BURRS or obviously your numbers will never repeat.
  • I was so slammed this weekend I didn't get a chance to investigate our hardware configurations or work on this problem at all. three consecutive 14hour days.


    I think we have X1H probe bodies, I don't know what controller we have, we have CAD++. One interesting clue might be that our stylus calibrations error out whenever we try unchecking the TRAX calibration box.


    That sounds like a great idea. It also sounds familiar, see my initial post. Thank you though. The line and point matrix idea might get me out of my bind with the self-centering points crashing my software.


    Lol, our CMMs sh!t the bed HARD scanning chamfers. The probe spirals into the bore as it scans, slipping down the chamfer at about 0.015" per inch of travel. I've had better luck scanning a line across the surface and falling into the bore, then using LINESEGMENTEND to grab the last point before the chamfer. I have found this isnt very accurate at all, but ill admit I haven't understood it fully.
  • Also, Cris_C also had the idea to identify the thread with a matrix function.

  • That sounds like a great idea. It also sounds familiar, see my initial post. Thank you though. The line and point matrix idea might get me out of my bind with the self-centering points crashing my software.

    D'oh… Next time I read to the end, I promise! Astonished