Yes, I can post a file. I will have to find out how to post the file though, or do you know how to do it?

Hello, Where I work we do a lot of 6061 aluminum barstock. I started working there two months ago, so am still getting the feel for what problems are holding up production, where improvements need to be made. One thing I have been seeing frequently is while turning the 6061 getting birdsnest around tools, that either stop the automatic machines (barfed, dual spindle lathes) from running unattended after hours, or on the 2 axis lathes having birdsnest cause accuracy/finish problems that make it so that a cycle can't be completed without operator intervention. One thing the setup guys will do at the machine is add a "chip break" into the turning or boring. AKA turn .100" to .200", then back off .015, turn some more...etc. I was asking my boss if I should be writing the programs to do that out of the box and he said don't worry about it because it isn't always needed and the guys will take care of it if it is needed. But it did get me thinking- Is there a way to accomplish something like this, without manually creating the toolpaths, in MasterCam? I have done things like this frequently for boring, where I break the geometry every so often, and then do a toolpath for each segment to rough. Or any other suggestions on how to get the chips to break? The boss said he has spent a bunch of time in the past with different insert shapes/chipbreakers/feeds/doc etc and some stuff just doesn't want to break. One thing I was thinking about on the live tool lathes is drilling some holes in the face, so that there is always an interrupted cut while turning. Anybody doing anything like that with success to break chips? I appreciate any input anybody has on chipbreaking. Thanks, Brian

The thing is, I use a point toolpath to get the machining results I want. I lay out the pecks along the angle and select the points. Right now I would like to learn how to get the tool rotated in MCAM so it looks right when you backplot or verify it.

Hello, We have some parts that have an angled hole that is drilled with a form tool and tapped. Right now I just get the drill points out of the CAD and program manually. Is there a way to have an angled head on a cross drilling tool in MasterCam lathe? I will dig into if it possible, but didn't want to spin my wheels going nowhere if it isn't possible. The MCAM help said angled heads could be used with Mill & Router, but didn't list Lathe. Would milling toolpaths on a Lathe fall under the "mill" category? Thanks, Brian

I change the tool offset # in the tool manager, but it doesn't stick. I have to enter the tool offset# each time in the toolpath parameters page for each toolpath. Just to check, you mean that you are using the same T # with a different offset #?

Thanks for the reply. I kind of figured that is what the answer was going to be, but was *hoping* there was an easier solution Another question I have today - If you have your program for both the sub and main spindles and POCO done, and you want to change the sub spindle chucking diameter and gripping position, what is the easiest way to do that without mucking everything up? If there isn't an easy way I can just draw in where I know the chuck jaws will be and have that level turned on when I backplot.

Hello, Programming dual spindle lathes we use a quad tool holder that holds 2 tools for each spindle. A rougher and finisher for both sides. So the rougher on the main spindle is T303, the finisher on the main is T333, and the rougher on the sub is T323 and the finisher for the sub is T343. In MasterCam I will bring my tool in and in the "define tool" and give it tool #3 with, say for example, offset 33. Then after I green check out of that back to the toolpath box, the tool will be T303! Every toolpath I create with a different offset numbered tool I need to enter the offset in on the toolpath parameters page. Is there any way to get MCAM to take the offsets in the define tool page and not change them? I don't have this problem with normal tools, just ones using the same tool number. Thanks, Brian

Mike@Dive Lab - The problem is when it does more than one hole around a cylinder. Verify shows a straight line move to the next drill position instead of the stock being indexed.

That was easy. Thanks. I was hunting everywhere and didn't even notice that. Thanks.

Hello, I have some holes in the face of a part and the face is tapered. I want to deburr it with a ballnose endmill using a 3d contour chamfer toolpath. When I go to select my geometry for the deburr I get the message, "The selected entity is not parallel to the Cplane(plane mask is enabled)" I did a search in the help function for "plane mask", but didn't find anything. This must be a setting somewhere? How do I turn off the plane mask so I can select 3d chains? Thanks, Brian

Hello, Drilling holes around the outside of a part on a live tool lathe, so that the drill is perpendicular to the centerline of the turned part. My clearance for rotating the C axis is .200 above the part. In verify mode though, it shows a straight line move from one drill clearance point to the next, which is not how it will happen in the machine. I know the code that is output is good. The tool is above the part and the C axis indexes. Is there a setting somewhere that controls how verify behaves with this toolpath type? I don't wan't to have to change the program from what I want, so that verify will not show gouges. Thanks, Brian

bd41612 - Thank you, the "thdfirst$=thddepth$/(sqrt(thdncuts$))", did indeed take me where I wanted to go. And the pthdext$ block calculation for thread height was commented out. Awesome, thanks! Now another question for my curiosity - In the MCAM Lathe thread parameters box, the thread height displayed is not the result of the "lead *.61343" calculation. What is up with that? MCAM has .02975, and the equation gives .0307.

Hi Guys, I have always used G32 for threading. Where I work now they want G76 canned cycles. The problem I am having is that if I put in MCAM that I want 7 threading passes, plus a finish pass. At the machine I am getting 11 threading passes, plus the finish. I think that the start depth number in the G76 cycle isn't getting output correctly. My output in the above example was Q69, which is a first cut depth of .0069. I found a formula in my CNC Programming Handbook, that shows what I am getting at the machine - that a first cut depth (Q) of .0069 will result in the 11 passes. I am coming up with the first cut depth should be .0101 or Q0101. Does anyone know where to change that in the post? Or even how to change it mathmatically? I did two different thread outputs as tests, and calculated what the first depth cut should be (seems to me at least) and it was not off by the same factor for both situations. And also, any insight into the inner working of G76 or how to get at the machine what I input in MCAM would be much appreciated. Thanks, Brian

The sav_rot_on_x was commented out. Removing the # and it works now like I would like. Thank You.

The force_wcs is set to "yes$". I looked in the ptlchg_com block. I put the pfcout in a few places and never got any B output still with the one plane. The post version is V16.00 P0 E1 W16.00 T1369940991 M16.00 I0 O1, and I am using MCAM X7. Here is the ptlchg_com postblock: I was wondering if the line that is "if plane$ < 0 | opcode$ = 3 | opcode$ = 16, plane$ = 0" has something to do with it, but don't undertand what that line is doing yet. ptlchg_com #Tool change common blocks pbld, " ", e$ pbld, " ", e$ pbld, " ", e$ if force_output | sof, [ result = force(ipr_type,ipr_type) result = force(absinc$,absinc$) result = force(plane$,plane$) ] pcom_moveb pcheckaxis #Check for valid rotary axis if sof, uninhibit_probe$ c_mmlt$ #Multiple tool subprogram call #ptoolcomment if sof & scomm_sav <> snull, [ spaces$ = 0 n$, pspc, scomm_str, *scomm_sav, scomm_end, e$ spaces$ = sav_spc ] if sof = 0, scomm_sav = snull comment$ pcomment3 pmisccheck pcan if stagetool >= zero, [ if omitseq$ = 1 & tseqno > 0, [ if tseqno = 2, n$ = t$ pbld, *n$, *t$, ptoolcomm, e$ ] else, pbld, n$, *t$, ptoolcomm, e$ ] spaces$=0 pbld, "M01", e$ pbld, "M98 P8000", e$ pbld, "M06", e$ if output_z = yes$, [ preadbuf5 if (opcode$ > 0 & opcode$ < 16) | opcode$ = 19, [ n$, pspc, scomm_str, "MAX - ", *max_depth, scomm_end, e$ n$, pspc, scomm_str, "MIN - ", *min_depth, scomm_end, e$ ] ] spaces$=sav_spc pstock if plane$ < 0 | opcode$ = 3 | opcode$ = 16, plane$ = 0 sav_absinc = absinc$ if wcstype > one, absinc$ = zero pindex if safe_index, [ if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$ pbld, n$, pgear, e$ pcan1, pbld, n$, *sgcode, sgplane, [if not(index), sgabsinc, pwcs], pfcout, strcantext, e$ if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$ if convert_rpd$ = one, [ gcode$ = one feed = maxfeedpm ipr_type = zero ] pbld, n$, sgcode, [if gcode$ = 1, sgfeed], pfxout, pfyout, pfcout, pfspindleout, [if gcode$ = 1, *feed], e$ ] else, [ if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$ pbld, n$, pgear, e$ if convert_rpd$ = one, [ gcode$ = one feed = maxfeedpm ipr_type = zero ] pcan1, pbld, n$, *sgcode, sgplane, [if not(index), sgabsinc, pwcs], [if gcode$ = 1, sgfeed], pfcout, pfxout, pfyout, pfspindleout, [if gcode$ = 1, *feed], strcantext, e$ if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$ ] phsm1_on #must remain before G43 pbld, n$, "G43", *tlngno$, pfzout, scoolant, next_tool$, e$ pcan2 #Added so M and G codes in canned text will output before phsm2_on phsm2_on #must remain after G43 sav_coolant = coolant$ if coolant$ = 1, sm09 = sm09_0 if coolant$ = 2, sm09 = sm09_1 if coolant$ = 3, sm09 = sm09_2 absinc$ = sav_absinc pcom_movea toolchng = zero c_msng$ #Single tool subprogram call plast

Hello, I am using the Mpmaster post with a horizontal machine. If I don't have any rotations in the program, I am not getting a B axis output at the beginning of the tools. How do I change get it to have a B axis output all the time?

Hello, I just started using X7 a few weeks ago. When making fixtures and programming a new job I have always taken solids of my fixture with all the bolts and clamps and everything, and the stock solid, and used "save some" to save the whole thing as an .stl file. In X7 I did all this and select the file for the stock under the backplot/verify options. When I open verify, the stl file is displayed in the correct poition and orientation, but the tool is way out in space where it isn't actually. If I only highlight "workpiece" in the visibility options in verify, then the stl will show up in the correct relative orientation to the tool, but you can't actually see the stl being machined. If I take all the solids and boolean add them together and use that solid for the verify stock everything works with the verify. Except that boolean adding everything together is time consuming, plus not all the fixture components are actually touching each other as they are drawn in solids, so I can't add those solids to the conglomeration for the verify stock. Does anyone know how to get verify to work correctly with the stl? What am I missing?

Well, I got the post changed to the Pick off cut off almost all like I would like. There the section with the cutoff tool positioning that I can't find/figure out. I would like to pre- posistion the cutoff tool at X8. all the time and at the Z cutoff posistion, then do all the M-codes for part eject and spindle sync, grab the part in the main spindle, cutoff, retract to X8., then part off detect, de-sync the spindles, and send the subspindle home, then move the turret to the G53 tool change position. I attached my POCO code from MCAM with notes on where I wanted to change and was wondering if anyone could point me where to look in the post. Thanks. POCO SAMPLE CODE.txt

So, if you have the ability to use either the C axis or Y axis, which one do you think is better to use?

Cool, thanks for the info. I appreciate your help!

It is a 2d contour path, with C axis for the rotation type. I was wondering if the control interprets the F when there C present differently? Is it degrees per minute? I changed the feedrate in MCAM to 60IPM, and reposted to see what would change. And in the code it is the same F2000. feedrate. Ah, then I slowed it down and then the feedrates changed, so I am guessing that the rotary feedrate is limited to 2000 degrees per minute? Are feed rates for C axis lathes with milling normally in degrees per minute?

I used the Cview utility and reposted and got the M14 and G42. I am assuming that the output is correct. We will find out! Thanks for introducing me to the Cview utility. It does make sense that if you rotate your axial tool 180 for the subspindle that the live tool motor would need to spin the opposite direction. I made the change in the control definition for the rotary feed rates, but am still getting the F2000. feed rate. Do you know what else could be causing that, or maybe a switch in the post that the control definition didn't actually change? Thanks for the help.

I'll try that and take a look. Thanks!

Allright I have a couple more newbie questions I have an axial live tool on the subspindle. For the planes I have the WCS at top, and then copied the left plane and moved the zero, and used that for the T/C planes. I used a 2d mill contour path, with a C axis sub. The toolpath looks good in backplot and verify. But in the code I have an M14 for the rotary tool spindle on instead of an M13, and also a G42 instead of the G41. In backplot I verified I am climb milling, so I should have a G41, it seems like. Are my planes setup wrong, or how should I set up the planes? Something doesn't seem quite right. Also, I programmed a linear feed of 29 IPM, but the feed output in the code is F2000. for the cutting moves with the C axis. How are the C axis feed rates figured? Any insight into that would be appreciated. Thanks.

Oops. Actually the post and everything works fine. I confused myself with expecting to see the radius value as the X value for the milling - but we're on a lathe so it is doubled to the diameter. Duh:)! No harm no foul - thanks for the offers of help.