Axela, I had a look at this and you cannot create a taper (in the DOC tab) while you have RAMP selected. I will have a look at the threadmill and see how that would work. Tks guys -Randy teh sad he doesnt have surfaces

Hey all, I want to create tapered helix bore. One that follows the same rules as a helix bore, by remaining in constant contact at all time while the continuing along the Z axis (in this cae). But I want to throw the twist of tapering it at the same time. I havent looked into it alot but am wondering if anyone has done this and how. Tks!

I have just tried to change my file in the Mill/Tools folder to a custom defined 'mill head'. I used this file in X2 (didnt get around to it for X3) and it worked great. Gave me a great view of clearance angles and so on. I bring this file into X4, save in the appropriate spot and I get no change. Restart MC and still nota. Did something get altered that this no longer works or am I doing somethign wrong?

I have had this problem since MU1 PC2 came out. I had no issues with PC1 (beta) then I all my verify stuff went black. IT's upgraded my video drivers this morning to no avail. That was an ATI FireGL v5100 (128mb ram!). So, they swapped it out for an Nvidia Quadro FX 1800 (768mb ram =] ) and my verify is perfect again. I know this was an expensive way to fix somethign that IMHO shouldnt have glitched to start with, but! it did fix it. And that makes me happy. Version is 6.14.0011.8208 for my video drivers, btw. Just thot I would let you all know.

Thanks guys, I think I can get it to work with what you have said.

Thanks, but that didnt do anything.

I am wanting to modify my drill output to do something that may initially sound silly. I have modified the post block as such code: pdrill$ #Canned Drill Cycle - G81 pdrlcommonb if drl_prm1$, pdrlcst$ else, [ result = mr4$ + mr5$ + mr6$ + mr7$ + mr8$ + mr9$ if result > 1, result = mprint("ERROR - MULTIPLE MACHINES SELECTED IN MISC REAL SECTION. PLEASE CHECK AND REPOST") pcan1, pbld, n$, *sgdrill, pdrlxy, pfzout, pcout, pindexdrl, prdrlout, [if dwell$, *dwell$], *feed, strcantext, e$ #removed *sgdrlref, 09.21.09 RDM ] pcom_movea What I have done here, is when the user selects the custom drill cycles it will jump to pdrlcst$ and not run the standard G81 anymore. This works very well. The problem is if I have 8 holes (for example) selected it will output the pdrlcst$ post block but then after that it will post out all the X and Y positions. How can I modify this further so that it no longer gives me X & Y positions? Tks!

Thank you! I knew I'd seen it somewhere before

I know this has been covered before...maybe even by myself. But, I am running the X4 Lathe MPLmaster and its posting an E during threading. How can I change this? I back tracked and cant seem to find a place where it convers the F to an E... /sigh

Hey, Wondering if I am the only who is not seeing the 'R' (retract) box in X4 Lathe, Canned Groove toolpath. When I post out I get G75 R0. G75 ...... Upon further looking, I dont see a box that I can specify a retract in. Maybe I am blind? Please enlighten as needed

Hey G, Thanks, JP beat ya to it tho, just in an email instead of on here.

Either way would work for what I am doing. Just a message to the person programming. This is what I did. code: result = mr4$ + mr5$ + mr6$ + mr7$ + mr8$ + mr9$ if result > 1, result = mprint("ERROR - MULTIPLE MACHINES SELECTED IN MISC REAL SECTION. PLEASE CHECK AND REPOST") if mr4$=1, #Daewoo DMV 6025s - V66 So, it will still post out the proper code, but it creates a pop up that stops the posting operation until you hit OK. Not a fool proof way to do it, but it works for what I need. Thanks guys!

I have 6 Misc. Reals that I am working with in my post, but I dont want more then one or these 6 to be active at any given time. Is there any kind of 'statement' that can be used to check all six and make sure only one of them is equal to 1 and the rest are zero (in this case) and if it finds multiple "1's" then to error out?

Huh, good save Tim. Wonder why they would have differnt fs2 statements in different posts... Oh well! Works great now, TKS!!

I am setting up a couple of user defined variables in the X4 MPMaster per the following fmt D 21 bcd47 bcd47 = drl_prm1$ I get an error when posting 25 Sep 2009 09:28:29 AM - <2> - PST LINE (970) - The format statement number is not defined (default to 1) Why is this? Works fine in my other posts (older ones tho)

Well, here is my parameter page code: N1( 23/32 FLAT ENDMILL ) M06 G91 Y-25. #3006 = 1 (CHECK INSERTS) G90 G54 X.3508 Y0. B90. S2125 M03 G98 G43 H1 Z2. M07 Z.25 G01 G41 D1 X0. F34. <-----GOOD G03 X.7016 R.3508 X-.7016 Z.21 R.7016 X.7016 Z.17 R.7016 X-.7016 Z.13 R.7016 X.7016 Z.09 R.7016 X-.7016 Z.05 R.7016 X.7016 Z.01 R.7016 X-.7016 Z-.03 R.7016 X.7016 Z-.07 R.7016 X-.7016 Z-.11 R.7016 X.7016 Z-.15 R.7016 X-.7016 Z-.19 R.7016 X.7016 Z-.23 R.7016 X0. Y.7016 Z-.25 R.7016 Y-.7016 R.7016 F10.2 Y.7016 R.7016 G40 Y0. R.3508 <------- NOT SO GOOD G00 Z.25 Z2. M09 G91 G28 X0. Y0. Z0. M05 G90 M60 M30 Dunno why mine is different...

I do have it set to Perp Entry (sound wrong said that way...lol). If I try (just for trying) to output without Perp Entry with wear on I get the big alarm pop up that Cuttercomp is being applied on an arc move. Thus, it applies cutter comp OFF on the arc in and arc out. The way I have it, it is comping improperly only on the out move.

I am looking at the new X4 Mpmaster.pst file. Running a helix bore (or similar) with wear comp on, the output to turn on G41 is good. But the output to turn it off (G40) is not so good. It runs the G40 on an Arc move, which is no good for the mills we use here. code: .... Y.7016 R.7016 G40 Y0. R.3508 <-------- No Good G00 Z.25 .... So, in trying to get the arc onto a seperate line causes a whole heap of issues in the post because the same callout, sccomp, is used for both G41/42 and G40. So if that gets moved/modified it affects both ends of the cutter comp system. The code below shows how it turns it on from the MPMaster. code: pccdia #Cutter Compensation #Force Dxx# if prv_cc_pos$ <> cc_pos$ & cc_pos$, prv_tloffno$ = c9k sccomp if cc_pos$, tloffno$ Any ideas of how to move this to a less conflicting line? Either one by itself, or one with a G1/G0?

I am looking at the 'new' X4 MPMaster horizontal post at work today and wondering to myself how the comment$ is put together. Seemingly it has no noticable ties to anything within the post, other then appearing a few times thruout as just a line on its own. So, if you go into the Ops Manager/Files and turn on Output Machine Name/Group Name/Group Comment, whala! They post out from comment$. If you leave them on and #comment$ they go away. Magic? Maybe. How are they controlled thru this variable? That is my question.

Ya, I got it all tuned up and running thru the post well enough, but the 'non graphical' part of it I dont really care for. Makes the parts look...incomplete. Due with whats avaialable I suppose, right? Tks for the help Gentlemen!

Martin, That is a good idea. The only drawback to that might be that it will not graphically show you what has been done within Mastercam. Is it possible to have my cake and eat it too? (But that will work for now, tks!)

James, What I am specifically looking to do is create a new Gcode within my post. I program for a Mazak Intergex e500. We do ALOT of work with highfeed cutters on this machine. Until now I have been using Helix Bore and just using the code posted out my MCX. The other day I took the time to look into G130 (Tornado tapping, which is the same idea as a helix bore). I can generate the same response from the machine in one line of code that is currently taking up literally thousands of lines (my typical program is around 10,000 lines long or so because of the high feed cycles). I run multiple size holes, all straight and the application would be ideal to eliminate these huge files and chop them down in ... well, quite small ones. So all the info that is contained within the helix bore operation is extremely useful, and all relevant to the G130 that I wish to produce from it. The only hang up is the G130 requires a D (diameter of hole) to be output with it. What you were asking about multipasses doesnt really apply for the situation I am thinking for. With said highfeed cutters I would either be solid boring (from solid machining the hole out with the highfeed cutter) or having a pre-drilled hole and opening it up to finish size (ish). This hopefully clears up my intent, but still leaves me with the same drawback of that D value.

If I wanted to take info from line 1052 of the NCI file and have it post out with my Gcode, how can I accomplish this, if its possible..?

Eric/James, would all that info not be handled by mastercam already tho? I am not very good with NCI stuff, which a new post from me will pop up here in the next few minutes...anyways, would the NCI not need to record the diameter of said circle so that it could calculate the arc of a circle mill (for example) minus the cutter size? Output from MC is something like this; G3 R1.5 (while using a 1" endmill, lets say) Somewhere in there it has to know that it is cutting a 4" cicle for it to be able to give me an R of 1.5...Yes? No? Same as Eric, just thinking out loud here. And sadly, I dont have any MI's or MR's available It would be an easy fix.

Bump?