How to determine if current operation is thread milling?

[Eric Rawls]

I'd like to give the operator an easy way to verify that the programmed thread pitch is correct. The plan is to insert a comment when thread milling.

 

We can snag the pitch parameter via prmcode$ 12194, but that's all we've got so far.

 

How would we identify that the current operation is thread milling to ensure that the pitch comment is only output when applicable?

[SlaveCam]

From MP post reference: tool_op value for thread milling should be 100

[Eric Rawls]

Woohoo! I looked through the reference, but wasn't smart enough to find it. somethingsilly.gif

 

Thanks a lot.

[lowcountrycamo]

I would love to see how you work this out.

[Eric Rawls]

Well, here's what I came up with:

# --------------------------------------------------------------------------
# Toolchange / NC output Variable Formats
# --------------------------------------------------------------------------
fmt      13 threadPitch #Thread pitch from thread mill cycle, 5 place decimal
fmt      2  majorDia    #Major diameter of thread, 4 place decimal


...


psof$            #Start of file for non-zero tool number
      ...
      pbld, ptoolcomment, e$
      if tool_op$ = 100,
        [
        sav_spc = spaces$
        spaces$ = 0
        pbld, n$, "(PROGRAM MAJOR DIAMETER IS ", *majorDia, ")", e$
        pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$
        spaces$ = sav_spc
        ]


...


ptlchg0$         #Call from NCI null tool change (tool number repeats)                        
      ...
      comment$
      if tool_op$ = 100,
        [
        sav_spc = spaces$
        spaces$ = 0
        pbld, n$, "(PROGRAM MAJOR DIAMETER IS ", *majorDia, ")", e$
        pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$
        spaces$ = sav_spc
        ]


...


ptlchg$          #Tool change     
      ...
      pbld, ptoolcomment, e$
      if tool_op$ = 100,
        [
        sav_spc = spaces$
        spaces$ = 0
        pbld, n$, "(PROGRAM MAJOR DIAMETER IS ", *majorDia, ")", e$
        pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$
        spaces$ = sav_spc
        ]


...


pparameter$     #Read operation parameters
      ...
      if prmcode$ = 12194, threadPitch = rpar(sparameter$, 1) #Thread pitch from thread mill cycle
      if prmcode$ = 12203, majorDia = rpar(sparameter$, 1)   #Major diameter of thread

 

There is one major flaw in this which renders it impractical. That prmcode$ variable will be whatever is in the textbox under "Cut Parameters" --> "Major thread diameter" in the thread milling operation. So this only works if you choose a point for thread milling and enter the diameter manually. If you choose an arc or circle entity the textbox will be grayed out and the post will output whatever number is in that grayed out box. For this to work as desired there would have to be a way to determine whether the major thread diameter was derived from arc geometry or manually entered, and then get the major diameter from the arc if that is what determined the diameter. As far as I can tell, there is no way to make that determination in the post, and even if we could, I don't know if there is a way to get the diameter of the arc that was chosen for the toolpath. I searched around but couldn't find the answers to fill that need.

I don't like drawing points, and I already have a handy little program that scans code for me, so I came up with an alternative soution.

What I finally did was output the thread pitch using prmcode$ 12194 (it is always the correct value) and I output a comment that tells the tool diameter: 

        pbld, n$, "(PROGRAM THREAD TOOL DIAMETER IS ", *tldia$, ")", e$

I have a little baby program that I call my "post-post". It processes the G-code after the Mastercam post to make further customizations. (I have it set as my editor in Mastercam, and after it processes the code it sends it to my actual editor.) When it sees that "THREAD TOOL DIAMETER" comment it begins scanning for I, J, and R codes when the modal G2 or G3 is in effect for that tool. Using the greatest radius found from I, J, or R and adding that to the tool diameter, it replaces that "THREAD TOOL DIAMETER" comment with a "THREAD MAJOR DIAMETER" comment.

I would be happy to share my github repo for that program if anyone should ask, but one must be aware that it is very much customized to my personal code format (the home returns that our machines use, the locations for comments in the code, etc., etc.) It was not built to work for anyone else. You would pretty much need to use my machine definition, control definition, and .pst files to see the thing work as it is intended. The .pst files are built to work with custom macro programs in the machines also, so not all of the canned cycle features would be available without those macros. So this is a can of worms. I'm only telling how I finally solved it because lowcountrycamo wanted to see how I worked this out. Be careful what you wish for. funnyemoticon.gif

 

Tl;dr: The code shown above does work, but only if you select points for your thread mill cycles (not arc center, but an actual point).

[SlaveCam]

Too bad it's not possible to read the arcs during preparatory processing, then you wouldn't be needing your "baby program". Or can you?

[Eric Rawls]

Hey, I think you're onto something! That "baby program" is a can of worms, as I said (and the tldia$ method had a bug in it). Let's cut out the post-post processing and try your suggestion.

I've got this cycle time calculator that I got from "Peter - NCS Ltd." in this post. (It's really nice, by the way.) It uses the radius of arc moves (arcrad$) in the pncoutput #Movement output block. I believe we could use that to handle this situation.

I'm going to fiddle with it, see what I can come up with, and post the results here.

 

Edit: Removed some comments about not being able to handle situation of cutting 2 different thread diameters without a toolchange. It will be handled in the code when I post the results.

[Eric Rawls]

Ok, here's what we've got now. If anyone wants to use this method, just ignore the code in my earlier post and start fresh with this code.

# --------------------------------------------------------------------------
# Common User-defined Variable Initializations (not switches!)
# --------------------------------------------------------------------------
boolthreadml : 0     #Boolean to be used when thread milling


...


# --------------------------------------------------------------------------
# Toolchange / NC output Variable Formats
# --------------------------------------------------------------------------
fmt      13 threadPitch #Thread pitch from thread mill cycle
fmt      2  threadDia   #Thread major diameter
fmt      2  mytlDia     #To store tool diameter


...


psof$            #Start of file for non-zero tool number

      ...

      pbld, ptoolcomment, e$
      if tool_op$ = 100,
        [
        boolthreadml = 1  #Set boolean to show that we are thread milling
        threadDia = 0
        mytldia = tldia$
        sav_spc = spaces$
        spaces$ = 0
        pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$
        spaces$ = sav_spc
       ]
      else, boolthreadml = 0


...


ptlchg0$         #Call from NCI null tool change (tool number repeats)                        
      if boolthreadml = 1,  #If the previous operation with this tool was thread milling:
        [
        boolthreadml = 0
        sav_spc = spaces$
        spaces$ = 0
        threadDia = mytldia + threadDia
        pbld, n$, "(PROGRAM THREAD MAJOR DIAMETER IS ", *threadDia, ")", e$
        spaces$ = sav_spc
        ]

      ...

      comment$
      if tool_op$ = 100,
        [
        boolthreadml = 1
        threadDia = 0
        mytldia = tldia$
        sav_spc = spaces$
        spaces$ = 0
        pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$
        spaces$ = sav_spc
        ]
      else, boolthreadml = 0


...


ptlchg$          #Tool change  

      ...

      pbld, ptoolcomment, e$
      if tool_op$ = 100,
        [
        boolthreadml = 1
        threadDia = 0
        mytldia = tldia$
        sav_spc = spaces$
        spaces$ = 0
        pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$
        spaces$ = sav_spc
        ]
      else, boolthreadml = 0


...


pretract        #End of tool path, toolchange
      if boolthreadml = 1,
        [
        boolthreadml = 0
        sav_spc = spaces$
        spaces$ = 0
        threadDia = mytldia + threadDia
        pbld, n$, "(PROGRAM THREAD MAJOR DIAMETER IS ", *threadDia, ")", e$
        spaces$ = sav_spc
        ]


...


pncoutput       #Movement output
      if boolthreadml = 1,
        [
        if gcode$ = two | gcode$ = three,
          [
          if arcrad$ * 2 > threadDia, threadDia = arcrad$ * 2
          ]
        ]


...


pparameter$     #Read operation parameters
      if prmcode$ = 12194, threadPitch = rpar(sparameter$, 1) #Thread pitch from thread mill cycle

 

This will output the pitch and diameter comments at the end of each thread milling operation. It will show the correct diameter regardless of whether the operation was created by selecting a point or an arc. It would be neater if the comments were inserted at the start of the operation. There is probably a hacky way to do that, but I'm happy with it the way that it is.

I'm going to call this a success. Thank you, SlaveCam for helping me understand how to do this.

 

**************************** Edited on 4/9/2017 ****************************

There was a flaw in the logic. If two different thread mill tools were used in succession, the comment would output the thread pitch for the 2nd thread twice (didn't give the correct comment for the first thread). It is fixed now. With the current code it will output the thread pitch at the start of the toolpath and then output the thread diameter at the end of the toolpath. That is the only way I see to get the correct comments in the code. This has been tested with using the same thread mill to do two different threads without a tool change and also doing different threads with tool changes in between. It is working well from what I have seen. It's a bit inconvenient to have the comments separated throughout the code, but it is still easier than back-figuring the g-code with a calculator to verify the program.

[Eric Rawls]

Heads up: The code above has been modified. If anyone had used that code before 4/9/2017 there would be a bug that would output the wrong thread pitch comment if two different thread mill tools were used to cut two different thread pitches with no other tools being used in between. The code above has been edited to reflect the corrections.

[geirsj]

Hi!, thanks for giving this example, i have looked for it to get the threadmill dia so i can check against my access database if the value has changed since last run of program.

this got me a little further down the road of understanding it.

I do the math manually for now, this at least add it as a comment before toolchange to compare. I get 2 comment blocks for the tool after putting it in my post if i have other tools than threadmill!, so i guess i just start over and see if it helps, took a copy and played with your code, again thank you.

I also see this example can be used as method or strategy for some other operations i have, like circle mill spot face and calculate the diameters and input them in a comment.

[geirsj]

Hi again!

i got this solution working for me and would like to share if it could be used for your issue.

I liked your strategy also and will use that for other issues for my post, this i have here gives you the details at a glance in the start of the tool change, HTH.