Programming Tip - Helix Bore "depth cuts" - Faster solution?

[ThickChips]

Hello all,

 

I find myself commonly using the aforementioned approach and it is a bit cumbersome and bulky. I was hoping to get a tip on how to better approach this to manage the program better. 

The application is boring with a feed mill to a reasonable depth ( 1.6x D). And in this process, the tool must be retracted after various depths above the work so the operator can evacuate chips from the bore (blind bore). Otherwise, its a bad day. The toolpath i'm using is a helix bore and to achieve these "depth cuts" I simply copy the toolpath x number of times and adjust top of stock and depth. 

But of course, if this needs changed, all of them need changed and its a rather cumbersome method. I know there are some toolpath transform/copy functions but maybe its as simple as using a different toolpath type.  Is there a better approach you would recommend? 

 

Thanks a lot

HELIX-BORE-DEPTHS.mcam

[crazy^millman]

32 minutes ago, ThickChips said:

Hello all,

 

I find myself commonly using the aforementioned approach and it is a bit cumbersome and bulky. I was hoping to get a tip on how to better approach this to manage the program better. 

The application is boring with a feed mill to a reasonable depth ( 1.6x D). And in this process, the tool must be retracted after various depths above the work so the operator can evacuate chips from the bore (blind bore). Otherwise, its a bad day. The toolpath i'm using is a helix bore and to achieve these "depth cuts" I simply copy the toolpath x number of times and adjust top of stock and depth. 

But of course, if this needs changed, all of them need changed and its a rather cumbersome method. I know there are some toolpath transform/copy functions but maybe its as simple as using a different toolpath type.  Is there a better approach you would recommend? 

 

Thanks a lot

HELIX-BORE-DEPTHS.mcam 544.34 kB · 0 downloads

OPTi-rough with Tool Inspection was my thought, but I tired and the transition moves don't respect it. Interested to hear with others have to say about this one.

[AHarrison1]

Are you not able to hook up an airline to blow down the tool for chip evac?

[ThickChips]

@AHarrison1

Potentially but unsure if that would be effective at deeper depths

[Aaron Eberhard]

I think for this specific motion output 1", pause w/M00 or whatever, resume, that you're on the right path with transform.

HELIX-BORE-DEPTHS transform.mcam

[ThickChips]

@Aaron Eberhard

Could you provide an MCAM file for version 2022? I can't open. Thanks a lot 

[Aaron Eberhard]

17 minutes ago, ThickChips said:

@Aaron Eberhard

Could you provide an MCAM file for version 2022? I can't open. Thanks a lot 

Apologies.. I thought I did.  I accidentally opened your file in 2023. 

The "trick" to making this work is to ensure that transform outputs the ops in the order you want by hitting "group NCI output by" > Operation Order.  Otherwise, it would output Bore Bore Bore Comment Comment Comment.

HELIX-BORE-DEPTHS 2022 transform.mcam

[Rstewart]

When that posts out it's not calling up the spindle after the M00, some machines may not work like that.  You can fix this by checking "force tool change" in the first op.  This will send Z home though...

[crazy^millman]

17 minutes ago, Rstewart said:

When that posts out it's not calling up the spindle after the M00, some machines may not work like that.  You can fix this by checking "force tool change" in the first op.  This will send Z home though...

Unless you have a mi or mr trigger to not do that.

[Rstewart]

9 hours ago, crazy^millman said:

Unless you have a mi or mr trigger to not do that.

 

Ron,

could you elaborate a lil more?  I understand the misc int are customizable, but how exactly would that work?  I may would like to incorporate something like that in our post.

[crazy^millman]

You go into the Tool change logic and put a if statement into the section of the post that is the toolchange. This post uses ptlchng_com for it and I added the following logic. All of this was because this was the way the customer had done i for 20+ years and the union refused to run programs unless the toolchange code matched exactly. Even the Tool list and headers had to be exactly like what there were use to seeing. If not they would refuse to run the code.

All you really need is the if mi3$ = 1 section before whatever calls the tool in your post. IF mi3$ is being used then look for a different mi or mr to use this type of logic. I added the mi9$ with the ability to use 2 different values once mi3$ was activated. I could have as many variations of this output as I needed. On a different machine we had 14 different ways you could call a tool depending on the type of tool being used. I had to reverse engineer every single one of them NC Code because there was no SOP, just years of tribal knowledge. Even on the newer machines it was a fight. I had to do all of this or Mastercam would have been dismissed as inferior software compared to NX. Didn't matter to the union if the part was correct or even faster. I seen them refuse to run a program because my dyslexia kicked in and I swapped some letter on a tool description.

      if mi3$ = 1, #I had to use a ForceTool change to get G43 output for the Shim Check and Fail Safe Pin.
        [
        if mi9$ = 1, #WE NEED CONTROL FOR THE M05 M09 OUTPUT.
          [
          pbld, pn, sm05, pe
          pbld, pn, sm09, pe
          pbld, pn, sg00, sg91, sg28, "Z0.0", pe
          ]
        if mi9$ = 2,  #WE NEED CONTROL FOR JUST G91 G28 LINE OUTPUT.
          [
          pbld, pn, sg00, sg91, sg28, "Z0.0", pe
          ]
        tmacnumber = t$
        pbld, pn, *tmacnumber, pe
        pbld, pn, "T#10", *sm06, pe
        doghouse = 1
        ]
      else,
        [
        ptoolcall
        ptoolcallar
        ]

Before is was just using ptoolcall

I needed to add a bunch of logic to mimic what NX was doing for 20+ years at this company so I added the ptoolcallar and that is this section of code.

ptoolcallar       #Tool Call for Areojet Rocketdyne for Doghouse Process on Makino to touch off tools to tooleye.
        pn, *sg91, *sg28, "Z0.0", pe  #added to mimic what AR does RDB 12-14-18
        pn, *sg90, pwcs, pe     #added to mimic what AR does RDB 12-14-18
        pn, *sg00, *sg90, *sg53, "X-15. Y-25.", pe  #This is to support Tool Eye Postion on machine Hard Coded Vaules
        pn, *sm00, pe #added to mimic what AR does RDB 12-14-18
        pn, ptoolcomm, pe
        pn, ptoolcomment, pe #Added to mimic AR 12-14-18
        pbld, pn, sm01, pe #Added to mimic AR 12-14-18
        pbld, pn, scomm_str, "DOG HOUSE OPERATION", scomm_end, pe
        pbld, pn, sg00, sg91, sg28, "Z0.0", pe
        pbld, pn, ptiltunlock, protunlock, pe #Added to follow process at AR RDB 12-14-18
        pbld, pn, sg91, sg28, ptiltrothome, pe #Added to follow process at AR RDB 12-14-19
        pbld, pn, sg90, pe
        pbld, pn, pwcs, pe
        tmacnumber = t$
        pbld, pn, *tmacnumber, pe
        pbld, pn, *toolmacnum, *sm06, pe
        pbld, pn, *sm14, pe
        pbld, pn, *strg659612, *heightmacnum, pe
        pbld, pn, *sm18, pe
        pbld, pn, *toolmacnum, *sm06, pe
        pbld, pn, sm01, pe
        pn, sg00, sg91, sg28, "Z0.0", pe
        pn, sg90, pwcs, pe
        pn, sm01, pe
        tlngno$ = 1 #Tool Height Offset will always eqaul one since they are using tool life management

I had to add the following format statements also.

fmt  "#10=" 4 tmacnumber #Added to do Macro Tool Call Process created for Makino at AR
fmt  "T#" 4 toolmacnum #Added to do Macro Tool Call Process created for Makio at AR
fmt  "H#" 4 heightmacnum #Added to do Macro Height Call process created for Makino at AR

Then create initialization value I wanted them to use.

toolmacnum  : 10
heightmacnum  : 10

doghouse  : 0

sm14           : "M14"   #Not Sure
sm18           : "M18"   #Not Sure

strg659612     : "G65 P9612" #Dog House Tool Touch off Macro

[ThickChips]

Aaron,

Wow, love it. Thanks a lot for the solution! This should be so much more manageable!