Thanks everyone, I have a few things to try now.

The burr is at the lead in. Higby is going to be our next move. We have found it is about 50/50 chance of working. Some times it works some times it doesn't. I'm wondering if shifting the second pass in Z a small amount might help, any body tried that?

I am posting this hoping that someone has a remedy for this. We are cutting a M25 X 1.5 I.D. thread and are getting a hair like hanging burr that is not acceptable to our customer. I have thread milled many a thread over the years and have noticed the hair like burr but it has never been an issue. We have tried climb and conventional cutting with the same result. This is for a part running on our transfer machine, doing  R&D on that is a bit difficult.

Thanks

Thanks everyone, I figured it would be a post thing. I was not sure if there was a function in mastercam to do that. I can not mess with what goes out to the machine too much, the setup guys here are limited and need to see the code a certain way. I will hit the post forum and see if there is any fairly simple ways to solve my problem.

Thanks for your suggestion. Unfortunately that is our problem we use the macro variables on every program that we run. I need to be able to post inch or metric, if I have to have 2 separate post processors I guess that is what I will have to do. It just means that if there is a post mod made that I will need to do It twice.

Yes they do but I do not think that solves my issue.

So all of my work in Mastercam is in Metric units. Most of the machines I am posting to are Metric machines. There is a few instances where I need to post to a machine that is setup for inches. I do not want to have 2 copies of the same Mastercam file. How would it be best handled posting from a single MC file to both Metric and Imperial?

Thanks Jeff, everything worked well. I matched up your stuff to my MP documentation and it is making some sense to me.

I owe you a beer. If you are ever in the Chicagoland area I would be happy to buy you one.

Many thanks.

Where do I go to learn all this stuff?

So If I have this correct, in the tool change section I run "pget_tool_parameters", this loads the all parameters I need for the current tool. Next I call "padd_tool_to_stack", this loads the parameters in the stack if the tool does not repeat. Calling the write sections seem pretty straight forward.

I will dive into this and see how it goes.

Thanks

Ok, after looking at it a bit more I see what you are doing with pheader$ and peof$. I don't quite understand the logic in the "padd_tool_to_stack" section but if it prevents duplicate tools from being loaded I will just grab what you have and use it.

When it comes to the skills I have in my tool box, post mods. are not my best asset. I stumble thru them till I get what I need and then I am done. I seem to only spend time on this when I change jobs, once the posts are set I don't exercise that skill for years.  

I frequent this forum often, usually just lurking and learning. There are a group of very knowledgeable people on here that are very helpful and have made this forum a big asset for both me and the Mastercam community, you are obviously one of them.

Thanks again for your time Jeff.

Thanks Jeff, you seem to be operating a bit above my head but let me see if I have what you posted figured out. You are loading a stack (what ever that is), of the tool info, in the parameter read post block. I would guess that I could then output that info later in the post as needed. It looks like there is some logic written to prevent the same tool to be loaded twice, if so perfect, that is the key to what I am trying to do.

I will spend some time looking thru my post document stuff and see if I can figure a bit of this out.

Thanks again

I am running outside if conventional post flow here a bit. I have a couple of buffers loaded with the tool and op info I need. This gives me a counter that I use to re-output the info as I need after the code for the specific operations are run. My peof$ section is quite large as I need to loop thru my operation sequence a few times at the end of posting to get what I need. Again I use the buffers as counters for the loops and extract what I need from them.

The path I started down is where I am trying to load another buffer (b4) as I am looping thru one of my main ones (b2). I am trying to evaluate the new buffer (b4) to see if there are any duplicates. It does not seem to be working.

Below is the code, maybe something will jump out to you as wrong.

      "(TOOL CHANGER LOAD PROGRAM)", e$     
        rc2 = 1
        rc3 = 1
        while rc2 <= size2, #while read counter, less or equal, to "last row number"
         [
         rc4 =1
         tl_skip = 0  
         b3_speed = rbuf(3, rc3) #read each row, starting with 1.
         str_temp = sopen_prn + drs_str(2, b3_speed) + " " + drs_str(2, b3_prog) + " " + drs_str(2, b3_numb) + " " + drs_str(2, b3_tcp) + " " + drs_str(2, b3_rl1) + " " + drs_str(2, b3_rl2) + " " + drs_str(2, b3_rl3) + " " + drs_str(2, b3_rl4) + " " + drs_str(2, b3_ptang) + " " + drs_str(2, b3_op) + " " + drs_str(2, b3_dir) + " " + drs_str(2, b3_chktl) + " " + drs_str(2, b3_qty) + " " + drs_str(2, b3_pitch) + " " + drs_str(2, b3_full) + sclose_prn
#         str_temp, e$        
         *rc2, e$
         if rc2 = 1,#First time thru it skips the check
          [
           b4_tool = b3_tool
           b4_tool = wbuf(4, wc4)#loads first position of buffer 4 with tool number
           sb2_str = rbuf(2, rc2) #read each row, starting with 1. 'rc2' auto-increments!        
           brk_str = strstr(" ", sb2_str)
           str_temp = brksps(brk_str+1, sb2_str)  #Tool Number and comment
           brk_str = strstr(" ", str_temp)
           sb2_str = brksps(brk_str+1, str_temp)
           stool_cmnt = "#3006=(LOAD " + str_temp + ")"
           if b3_tool = 1, ld_tool = 19
           if b3_tool = 2, ld_tool = 20
           if b3_tool = 3, ld_tool = 21
           if b3_tool > 3, ld_tool = b3_tool - 3
           "G100", *ld_tool, e$
           stool_cmnt, e$
           "G100", *b3_tool, e$
           if rc3 = 2, "G65P3501Z0", e$
           "G65P3010Z0", e$
          ]
          else,#After the first loop, checking buffer 4 for duplicates.
          [
           *rc4, e$
           *size4, e$
           while rc4 <= size4,#-----------------This is what does not seem to be working.
            [
             b4_tool = rbuf(4, rc4) #read each row, starting with 1.
             *b4_tool, e$
             if b4_tool = b3_tool, tl_skip = 1
            ]
           b4_tool = b3_tool
           b4_tool = wbuf(4, wc4)         
           sb2_str = rbuf(2, rc2) #read each row, starting with 1. 'rc2' auto-increments!        
           brk_str = strstr(" ", sb2_str)
           str_temp = brksps(brk_str+1, sb2_str)  #Tool Number and comment
           brk_str = strstr(" ", str_temp)
           sb2_str = brksps(brk_str+1, str_temp)
           stool_cmnt = "#3006=(LOAD " + str_temp + ")"
           if b3_tool = 1, ld_tool = 19
           if b3_tool = 2, ld_tool = 20
           if b3_tool = 3, ld_tool = 21
           if b3_tool > 3, ld_tool = b3_tool - 3
           if tl_skip = 0,
           [
            "G100", *ld_tool, e$
            stool_cmnt, e$
            "G100", *b3_tool, e$
            if rc3 = 2, "G65P3501Z0", e$
            "G65P3010Z0", e$
           ]
          ]
         ]
      "M30", e$

I need to have my post generate code for running tool touch off macros after the main code is run. I already have a buffer that loads up tool info at all the tool changes. My problem is that at times a tool might come out twice thus loading the buffer with the same tool twice. When I then loop thru the buffer and spit out tool touch off macros I get multiple callouts for the same tool. I would like to have the post only create code once for each tool. The goal is to have NC code that needs no editing. I am having difficulty wrapping my head around the logic needed for this.

I know how to make this happen at the machine. With macro B I can make it skip a repeat, I would much rather take care of it in the post as it would be much more seamless out on the floor.

Any thoughts would be great.

Yes, I am glad you posted this cause I thought I was doing something to cause this.

Thanks guys for all of the thoughts. Checking on this Monday morning so I will respond in order.

Pseudo code: 

Tool path:

O0002
( STEP DRILL G54 FRONT VISES)
G17
G0 G90 X40. Y0.
Z3.
G99 G73 X40. Y0. Z-31.17 R3. Q2.5 F2667.
G80
Z3.
G17
M99

O0102
( STEP DRILL G55 BACK VISES)
G17
G0 G90 X40. Y0.
Z3.
G99 G73 X-40. Y0. Z-31.17 R3. Q2.5 F2667.
G80
Z3.
G17
M99

The above examples are for the same operation, one for the front vise, one for the back. 2 separate programs, O0102 is rotated 180.

We reset the work offset like this.

G52 X-[#540*5]

and then just recall the sub.

No router, Brother D&T machines.

Coordinate rotation is defiantly an option. It will change slightly what they see on the floor but I might be able to get that to fly.

Thanks for the example. The way we handle it is front left is G54, back left is G55. As we bump along our grid the same 2 work offsets are updated in the program.

The setup guys were all born and raised here, this macro structure is all they know, they know it well though and can move thru a setup quite quickly and well.

I know there is more than one way to skin a cat with this and I am still the new guy here. After I gain a bit more of a foot hold I will introduce a few fresh ideas.

The other goal is if over the next year or so I can dial MasterCam in to their macros it will make it much easier for someone else to program efficiently.

I will look into the MPSubrep.

Thanks again

That is an option, the hiccup with that is the master macros that they run everything thru here. There is no changing that and rightfully so. The master programs are well thought out and the setup workflow that the floor guys have is pretty solid.

I would like to idiot proof the programming side as much as possible. They use G54 for the front, G55 for the back. The thought is, program one instance, give it a pitch and a qty using miscellaneous variables and the post just loads the master macro. Simple, just like I need it to be.

One of our standard setups here is a array of double Kurt hydraulic vises where parts are clamped on either side of the center jaw. A lot of the jobs are where the same operation is run on the front and back loads. Is there a fairly simple way to have a post output code both how it is programmed and then also rotated 180 for the back load. We run all of our machines using master Macro B programs with the tool paths loaded into them. I am trying to eliminate a lot of the cutting and pasting that we do now. It would be great if I could just program the one instance and the post would handle the rest.

Yup, that is it.

DUHHH!

Thanks

I am going thru some programs from a previous programmer and ran across something I have not seen before. Why are op folders 14 and 19 greyed out. They seem to post fine.

Thanks Doug, that is our initial thought. You and the rest of the ones that have responded are very helpful here. When any of you respond to a post I make sure I read it hoping to tap off as much of your guys knowledge as possible.

Thanks again everyone and enjoy your weekend fellas.

Chips should not be an issue, at least initially. As we do it now most of our product starts as saw cut extruded alum blanks. We stack as many into a fixture as we can and then run them on verticals. We would be wanting to bar feed some irregular shapes, do the work on one side, xfer to the other side and finish. Is bar feeding odd shapes rather doable?

I am sure though once we have a lathe on the floor turning work will start showing up.

Thanks guys, we run mostly alum. and the tolerances are usually not too tight. We are looking at these to get some lights out hrs with a bar feeder. Sounds like both of you are already doing what we would like to do.

I am out of my element when it comes to these machines. There is a chance we might have some work that would suit this type of equipment. We would need a thru bore of about 3.0 inches and would be using mostly live tooling. Who makes the ones we should be looking at?