Thanks for the info. I'm not sure if this will have kinematics though since its a 3 axis machine with a compound rotary on it.

My shop is buying a new okuma mill with a compound rotary on it. I've programmed a mill/turn machine with a positional B axis (the tool turret rotated). My question when programming for this compound rotary is do I have to use a different work offset at the machine for each B angle. In other words. I set a x,y,z zero at the machine when the part is at 0 degrees. Then i want to rotate the part on its side to 90 degrees. Is my only option to create a new x and z zero at the machine or is there some way in mastercam to account for this? I'm guessing you would have to know the distance from the pivot point to your z zero? I don't have the multi axis or the 5 axis addon at this time. Not sure if i need them. Thanks for the help.

Below is the section where I need to change it. I'm not sure exactly how though. I'm assuming gcode$ is a nill value so it skips all of the if statements for the prapidout. If you could give me some direction I would greatly appreciate it. pncoutput #Movement output if subreps & subout$ = 0, subout$ = 3 #Subrep pcom_moveb comment$ if coolant$ <> 0 & coolant$ <> sav_coolant, [ pbld, n$, sm09, e$ sav_coolant = coolant$ ] if coolant$ = 1, sm09 = sm09_0 if coolant$ = 2, sm09 = sm09_1 if coolant$ = 3, sm09 = sm09_2 if cool_zmove = yes$ & (nextop$=1003 | (nextop$=1011 & t$<>abs(nexttool))), coolant$ = zero pcan if cuttype = zero, ppos_cax_lin #Toolplane rotary positioning if gcode$ = zero, prapidout if gcode$ = one, plinout if gcode$ > one & gcode$ < four, pcirout if mr_rt_actv, #Restore absolute/incremental for G51/G68 [ absinc$ = sav_absinc mr_rt_actv = zero ] pcom_movea

This is for an Okuma. Forgot to mention what machine it was for.

If I have two points selected in a drilling cycle it posts like this. G56H2Z3. M08 Z.1 G94 G71Z.1 G73Z-.625R.1Q.05F10.M54 X-3.595Y.4682 G80 M3 Z3. M09 If i have one point selected it looks like this G56H2Z3. M08 G94 G71Z3. G73Z-.625R.1Q.05F10.M54 G80 M3 M09 The machine crashed on the secound cycle. Since it did not retract in Z. Any ideas? Using X9 and mpmaster 11.0.06347.

I tried changing/looked at the options in there. No luck though. I think this must be a bug since I can only get it to do this in canned cycle toolpaths.

When I change a tool number and offset in mastercam 2017 the tool will update correctly for the toolpath I am in. However in any other operations the tool number changes but the offset does not!. Is there an option somewhere to fix this? I tried this in a Milling operation and it asks the question like the old version of mastercam if you want to update all other toolpaths. *edit. It apparently only does it when you have a canned rough cycle and a canned finish cycle.

I'm trying to setup our mill post to work with the rotary table at work. I think I have the components setup correctly in the machine definition, however when I go to the machine axis combinations page I am unable to select both axis A and B together. It will only let me select one or the other. I loaded up a default 5 axis machine and went to the axis combination page and it Lists Axes Z,B,Y,X, and A. But if I uncheck A or B then I am unable to reselect both A and B. It will only let me choose one like in the machine definition I am trying to change. The default 5 axis machine I chose was 5 - AXIS TABLE - HEAD VERTICAL. Not sure what I am doing wrong but I'm guessing I'm missing something simple?

I think I could have got this down to only using one buffer with a little bit of extra code. And there is probably more elegant coding solutions to what I did, but this project was a pretty long struggle and I'm just happy it works.

I figured it out! What I did was use three buffers. Buffers 1 and 2 contained the exact same information of the tool number and the diameter offset number. After running that information through a few "while" and "if" statements I wrote the tool numbers and diameters to a line in buffer 3. Only tools that have a different tool number or the same tool number with a different diameter offset are put into buffer 3. No duplicates! Below is the code I put into the variables section #Variables added for tool table, wdg edit, 2-14-2016 sizecntw : 1 #variable for checking if post has compared all rows of information between buffers 1 and 2 chkdubw1 : 0 #variables for dublicate checking chkdubw2 : 0 b1_1 : 0 #buffer one b1_2 : 0 rc1 : 1 wc1 : 1 size1 : 0 fbuf 1 0 2 0 0 b2_1 : 0 #buffer two b2_2 : 0 rc2 : 1 wc2 : 1 size2 : 0 fbuf 2 0 2 0 0 b3_1 : 0 #buffer three b3_2 : 0 rc3 : 1 wc3 : 1 size3 : 0 fbuf 3 0 2 0 0 </pre> Below is the code I put into the psof$ section #Section below for tool table, wdg edit, 2-14-2016 ------------------------------- b1_1 = rbuf(1,rc1) #this section puts first tool info into buffer 3 b3_1 = b1_1 b3_2 = b1_2 b3_1 = wbuf(3,wc3) size2 = rbuf(2,0) #gets size of buffer 2 rc1=1 rc2=1 while rc2 <= size2, #while statement that starts the loop for checking for duplicates [ b1_1 = rbuf(1,rc1) #section reads loads values from tables 1 and two b2_1 = rbuf(2,rc2) if b1_1 <> b2_1, #checks tool number from buffer one against buffer two [ chkdubw1 = b2_1 #section loads values from table two into the dublicate checking variables chkdubw2 = b2_2 rc3=1 #resests read counter to 3 before going into the next while statment size3 = rbuf(3,0) #reads size of buffer 3 while rc3 <= size3, #gets size of buffer 3 [ b3_1=rbuf(3,rc3) #loads values from buffer three into variables if chkdubw1=b3_1 & chkdubw2=b3_2, #Here it checks if the values of chkdubw1 and 2 are already in buffer 3 [ chkdubw1=0 # if the values have already been entered into table 3 then it sets chkdubw1 to zero. ] ] if chkdubw1<>0, #If chkdubw1 is not equal to zero then it writes those values into table 3 [ chkdubw1 = wbuf(3,wc3) ] ] if b1_1 = b2_1 & b1_2 <> b2_2, #here it checks tool number and the tool diameter offset number...More of the same as above. [ chkdubw1 = b2_1 chkdubw2 = b2_2 rc3=1 size3 = rbuf(3,0) while rc3 <= size3, [ b3_1=rbuf(3,rc3) if chkdubw1=b3_1 & chkdubw2=b3_2, [ chkdubw1=0 ] ] if chkdubw1<>0, [ chkdubw1 = wbuf(3,wc3) ] ] if rc2 = size2 & sizecntw <> size2*size2, #This is how I make it loop so that each line from buffers 1 and 2 are evauluated against each other [ sizecntw=sizecntw + 1 #adds +1 to the size count. rc2=sizecntw #resets the read counter for buffer 2 to the same as the sizecntw...coul have made it equal to 1 but didn't need to since those values had already been evaulated. ] else, [ rc1=rc1-1 #keeps the read counter for buffer 1 and the same value until it has evualuated all rows of buffer 2 ] ] #section below outputs the tool table by reading the information in buffer 3 rc3=1 size3 = rbuf(3,0) #gets size of buffer 3 while rc3 <= size3, [ b3_1=rbuf(3,rc3) tnote = b3_1 toffnote = b3_2 scomm_str, *tnote, ptspace, " - ", plistcomm, " - ", *toffnote, phspace, " - ", scomm_end, e$ ] *size3, e$ #end of tool table section------------------------------- Below is the code I put into the pwrtt$ section #section below adds values to buffers 1 and 2, wdg edit 2-14-2016 b1_1 = abs(t$) b1_2 = tloffno$ b1_1 = wbuf(1, wc1) #writes info into buffer 1 b2_1 = abs(t$) b2_2 = tloffno$ b2_1 = wbuf(2, wc2) #writes info into buffer 2

In the drilling operation are you using entities and selecting a circle/arc? If you are try selecting the problem arc and hit F4 to bring up the properties. In the properties dialogue hit the "flip view" button in the very top right (its the button with the arrows pointing in either direction). I used to have this problem when programming for a mill/turn machine. The arcs have a z direction (best way I can explain it) and using the flip view button makes it drill in the correct direction. Good luck!

I'm not an expert at post editing so its hard for me to look through your post and decipher it. I appreciate the help through. Let me try to bounce an idea of you and maybe you can point me in the right direction. My idea was to first "find" the total number of op_id$ 's and make a variable called total_op_id. Then looking at the code below... ; if toolcountn <= tooltotal, nexttool = rbuf(4,toolcountn) #else, nexttool = first_tool$ ; Change it to if op_id$ <= total_op_id ; I'm not sure how to get around double posting of tools other than using an if statement that checks the tool number and and tool diameter. Which won't work if the tools are not programmed next to each other in mastercam. My knowledge is really lacking on buffers and preparatory post blocks. Is there a way to get the total op numbers?

As the title implies I want to get the tool table to list all the tools and include different diameter offsets. Current output below. (T1 - 1/8 SPOTDRILL - H1 - D1 - D0.1250")(T2 - 1/2 FLAT ENDMILL - H2 - D2 - D0.5000") Desired output below. (T1 - 1/8 SPOTDRILL - H1 - D1 - D0.1250")(T2 - 1/2 FLAT ENDMILL - H2 - D2 - D0.5000")(T2 - 1/2 FLAT ENDMILL - H2 - D5 - D0.5000") As you can see the above output shows that tool 2 is using diameter offset 2 and diameter offset 5. Eventually I want to have the post output the VTOFD command for Okumas so when running the progam on the machine it will automatically fill in the cutter comp value, which I think I can figure out as soon as I get the above resolved. Below is what my tool table currently looks like. Any help is greatly appreciated! --------------------------------------------------------------------------# Tooltable Output# --------------------------------------------------------------------------pwrtt$ # Write tool table, scans entire file, null tools are negative if rotaxis$ > 0 | rotary_type$ > 0 | mill5$ <> 0, [ sav_rot_on_x = rot_on_x output_z = no$ ] if vmc = 0 & tlplnno$ <> 2, sav_rot_on_x = rot_on_x if vmc = 1 & tlplnno$ > 1, sav_rot_on_x = rot_on_x #sav_rot_on_x = rot_on_x #Uncomment this line to output rotary axis value even when it's not used if tool_table = 1, ptooltable if tool_table = 2, ppredtool if tool_table = 3, pmetatool if t$ >= zero, tcnt = tcnt + one ptravel pwritbuf5ptooltable # Write tool table, scans entire file, null tools are negative tester tnote = t$ toffnote = tloffno$ tlngnote = tlngno$ spaces$=0 if t$ >= zero, [ scomm_str, *t$, ptspace, " - ", plistcomm, " - ", *tlngno$, phspace, " - ", *tloffno$, pdspace, " - ", *tldia$, punit, pdiamspc, " - ", *tcr$, punit, scomm_end, e$ #if tcr$>0, scomm_str, *t$, ptspace, " - ", plistcomm, " - ", *tlngno$, phspace, " - ", *tloffno$, pdspace, " - ", *tldia$, punit, pdiamspc, scomm_end, e$ #if tcr$=0, ]

Looks like that is the case. I'm ruffing it out with the grooving tool also. I just took off the roughing before I posted the file.

Was working on a file today and I noticed at the end of the grooving finish path that it rapids into the part. After messing around with mastercam trying to get it to not rapid into the part I ended up trying to change the 1st pass direction. After I did this it does not crash into the part anymore. Attached is the file that shows the rapid move going into the part. Just wanted to know why so I can avoid crashes in the future. Thanks! T.MCX-6

I was already finished with the job when I posted this question. Like I said above I post it out and then change the angle, x, y, and c numbers. And I'm not an expert at Mastercam or at Post editing. Especially post editing. But I like to learn and the best way to learn is by doing. Hopefully I will be able to edit it. I think I have a good plan to change all of the numbers except I'm not sure about how to change it in the drilling canned cycle. Haven't had time to start working on it yet. I've had very very little training on post editing. Its all trial and error. The other reason I like to do my own post edits is I found it to be a pain to send it out. The last time I tried it the post came back worse than it already was. And half of the edits I asked for were not done.

Ya, this was it. Thanks again for your help.

I won't wait until Dave gets back. I'll do it myself

All the angled holes for this part are not at Y zero. And the holes that are at Y+ I can do at 6.5 degrees. But I run into the x axis limit when I go to Y negative so I have to rotate the turret to -6.5 degrees and stay on the Y+ side. I think I can edit my post easily enough to get it to work for me. Just use a misc integer as suggested above.

Thanks for the help. I looked under my misc integers and there wasn't any option for my problem. Looks like I'll have to do some more post editing Not sure what the multi-axis drillpaths are or where they would be. I'm not sure I can use those though since we do not have the Multi-axis addon for our Mastercam.Also with this part I run into the X axis limit. I have to program half of the holes at 6.5 and the other half at -6.5(I don't have as much travel in X when I'm at Y negative). Not sure what the "MT product" is. I'm assuming its some sort of virtual machine? Haven't done too much with X7. The verify seems to crash alot for me.

Attached is the file I am working on. I'm running an Okuma Multus B400. TT.MCX-5

I'm trying to figure out how to get mastercam to post out a negative angle on my drill toolpaths. I'm running a mill/turn machine. I have some holes I need to drill at 6.5 degrees. I want to drill them at a -6.5 degrees on the machine. I can get mastercam to post out the program correctly for 6.5 degrees, just don't know how to force it to drill at -6.5. Right now I'm posting it out at 6.5 degrees and changing it to a negative and also changing my c,x, and y values so it drills in the correct place...surely there is an easier way?

No, I only use stock when I have to. Today I was programing for our mill turn machine with two spindles. I had a pickoff operation in it so I had to setup stock and jaws. But unfortunatly I still had the same problem. I don't remember exactly what I did to cause it since I had a lunch break in between programming, but I think the problem was caused by my mill operations. So I moved a mill op around (which doesn't make your lathe operations dirty) and my canned cycle was suppose to start with "G1 Z.1 X10" and the first line was "G1 Z0". I also had problems with operations on my sub spindle. Was having trouble getting it to post the correct code for the sub spindle. Had to do something to make my operations dirty (just regenerating didn't work) then regenerate them to get it to post correctly. Also had one of my operations have the correct code for the sub spindle but my rapid moves were at minus z. Had to make the operation dirty to get it to post correctly. My stock was a little bit funny in that program since my boring bar wiped out all of my stock on the 4th operation. I don't know why and I didn't take the time to find out. The boring bar didn't crash when I ran the progam. Although I didn't hang the bar out far enough...fortunately caught it before it crashed. Apparently this is not true. We have another computer at the shop and I was able to recreate this problem on that computer and it does not have the update for X5. So I guess it has always been this way and I've never noticed it in the last 3 years programming. Although I only tested it with our post for our fanuc lathe. I did not try to recreate the problems I'm having with out mill/turn post. I'm going to call the company who we bought our post from (I don't know who) and see if i can get him to come out to help.

I haven't done alot of testing on what all can cause it, but I know it happens when I move an operation. ie. I create a operation and then move it up in the program. Not sure what else causes it, though i'm sure I could make it happen with other methods. I was able to create 4 operations and not move them around and it posted just fine. I haven't tried to post an old program yet. This post was copied from my old computer and it didn't have this problem. EDIT: Used other computer in shop without mastercam update and was able to recreate the problem. X5 with the update installed (MU1). I don't think that my old computer had the update. I could try uninstalling the update but it seems unlikely that is the problem. Would upgrading to x6/x7 possibly fix this? Yes and no. The network backups all of the data on my desktop and my documents (annoying) and when I look at my documents it starts with a //server/..... But I think a copy is also saved on the hard drive of my computer. So...? The only other thing that I can think of that is different is the old computer was running xp and the new one is Win7 64. When i get back to work tomorrow I will try using one of the default posts that comes with mastercam and see if I can reproduce the error. Maybe that will narrow it down to a mastercam problem or my post.

I ended up finding an option under one of the settings that disabled multithreading. I think (crosses fingers) it has fixed the problem. Unfortunatly I found a new one Made another post here http://www.emastercam.com/board/index.php?showtopic=72312