quote: I would like to see "Ok", "Cancel", "Apply", and "Help" buttons. After using X since Alpha releases, I've come to the conclusion I don;t like the icons. I gave them the old College try but, I like Words. I'm a word guy, not an icon guy. That's why I have only the View Icons up in my Mastercam X since yesterday. Much cleaner, not like a cartoon, and Alt+ is fine with me. Almost like the older versions for key strokes. Now to work on my hotkeys. +999,999 I couldn't agree more. I was hoping there would be actual toolpath improvements (hole making, finding the depth of holes in a solid, importing the feature tree with the solid for people using Solidworks so MC can use the info for the Solid and Auto drill type functions). I am running my V9.1, tried X for a while but had too many bugs and setup / configuration issues. Just my $.02 Bob

quote: If I understand correctly, you're trying to minimize the amount of "programmer input" by presetting speed, feed, DOC, dwell, no dwell, coolant, no coolant, stepover, max length, etc, etc, .... for each type of cut? That's exactly it. I use tool libraries that have all the cutting parameters (speed, feed, DOC, stepover, finish allowance, canned cycle, coolant (splash, through, air blow)) defined in the tool description. If someone else is not familiar with these things it is a lot easier to end up with known good settings for all cutting parameters instead of relying on people to calculate the correct values . . . you know how that goes . . . I know let's drill some Invar at 10k at 80 IPM!

quote: I agree, I know you can spot drill with a chamfer tool but you can't chamfer with a spot drill. Oops . . . my bad, at least now in 9.2 you can use a spot drill, countersink, or chamfer mill to chamfer. I seem to remember in the past that you couldn't chamfer using a spot drill? Or maybe it was that you couldn't chamfer if the tool was defined as a countersink. In any case at least it is being addressed, I have probably 1500 programs at least that have this "condition".

quote: I haven't played with X much yet but I have V9 files with 4 tools with the same tool number (deep/shallow roughing, finishing sides/floors) and almost all my files will have at least one set of duplicate tooling. If you use just one tool and change the parameters manually you run into the problem of 1. another programmer clicking on the tool to look at the parameters and changing cutting data, 2. slower programming speed caused by having to look up the different cutting data for a certain process and entering them, 3. typos from entering the info manually, ect... IMHO this is a big problem if X can't keep from forcing tool changes. I agree, I know you can spot drill with a chamfer tool but you can't chamfer with a spot drill. Having the right speed, feed and dwell is critical for the spot drill, the chamfer tool is just another contouring tool. This has always been one thing that I think is is huge PITA, if you have a lot of operations with a variety of very specific speeds and feeds, depth of cut, finish allowance if you then change the tool number it changes all of the cutting parameters to what is defined with the new tool. Just my $.02

quote: I changed the source code. It was a bug. So will this be addressed as a service pack? I'm glad you found the problem! I haven't been using X much yet since we are very busy but noticed this deal right away. Thanks for looking into this, Bob

quote: The message is back (except when running batch). What did you have to do to get the prompt to return?

Ray how did you get that prompt to appear? This is exactly what I was referring to. I have 1000's of programs with this same scenario so I need to find a fix once I start using X ful time. Thanks, Bob

These are all good points, here is the reason I use two different tools . . . I use a tool libraray with all of the speeds, feeds and cycles defined with the tool. In this case the spot drill has a feed of 20IPM, a G82 spot drill cycle as well as a 30 milisecond dwell (5 revolutions of the tool when it hits the Z target). The chamfer tool has a feed of 70IPM and obviously no dwell. The one problem that occurrs when other people program is they will just use the chamfer tool for everything which would work if they would look at the feed, dwell etc but that never happens, so we end up with programs spot drilling at 70IPM with no dwell at all, not cool. I still haven't heard back from MC as to how to control this. As many here have said in all prior versions when you go to post and it asks about duplicate tool numbers you just tel it no and it is edit free. Thanks for the info, Bob

BK do you have two tools defined with the same tool #? Or, do you have one tool defined and you are using it as both a chamfer mill and a spot drill? That's exactly what I am doing. I have a 3/8" x 90 degree carbide spot drill that is tool #2. It has it's own speed, feed and spot drill cycle. I also have a 3/8" x 90 that is also #2 that is defined as a chamfer mill. It has different feed rates obviously. V9 used to ask when posting, X doesn't and I haven't found a setting to control it yet. Sent a z2g to MC QC but haven't heard back. Bob

Okay I know it's a lame topic, what I need to know is how to get MC to quit forcing a toolchange on a tool that is used as a spot drill as well as a chamfer tool. The tool has the same physical tool # but I haven't found a way to make it stop trying to do a toolchange when it goes from spot drilling to chamfering. In all prior versions you would always get the question when you were going to post . . . Multiple tools using the same number, generate a tool change in the NCI? You'd tell it no and you would have code the way it should be . . . spot drill, chamfer, spot . . . I have sent a z2g file to MC QC but haven't heard anything yet. I apologize if this is a newb question. We are busy and I haven't had much time to use X yet. Thanks in advance, Bob

I've had a lot better luck with SW 2005 files using the "Save as" from SW and selecting the "X_T" format. If you don't have access to SW 2005 or these are customers files this won't be of any help. Also I have had some SW files that you could not put a 3d toolpath on. SW would say that there were no errors or gaps but MC would barf when trying to generate a surface machining toolpath. Good luck

Hey Glenn, That fixed it! Thanks so much for the info. I tried creating some weird rotated Tplane values and it posts exactly what it should. Thanks again for the tip! Bob

Update, I tried using the MPfan post and created some rotated Tplanes. When I posted code, it had the correct (45.) value for this plane but on a 30 degree plane it also outputs 30.001? Pretty strange, I am going to setup a test program with several rotated planes to see if I can determine what is happening with the index values.

I'm using the MPmaster post. I was just wondering where it might be picking up the value. I'll try some other posts to see if I can find one that doesn't do this. Thanks for the tips, if I can't nail this down I will send it to MC and see what they find. Bob

Great subject line, huh? I have a question for people using Mcam for rotary axis work. If I want to create tool plane that is rotated from a standard (say Top plane for example) I make sure the Top plane is active, select the Tplane button and then pick rotate. If I give it a rotate the "Y" up 30 degrees I will then save that work plane to use when making toolpaths. The question I have is that my posted code values are always off by .001 degrees (I know, who cares) but it seems odd that is always off by that same amount. I mean it will post an "A" value of 30.001? Is there a post setting I am missing or has anyone else had this same situation. Thanks in advance, Bob

I assign an unused key to functions you want to use on the Spaceball, then right click in the menu and do the new comand deal, works great. I use it for bounding box, cplanes etc.

Sorry I haven't been on the board in a while. This is exactly what I am looking for. I will check the ftp post folder for the mp_srtp post. Thanks for the info, Bob

I am looking for a way to have all of my posts include a small program at the end of the posted code that would just be used to load each tool that was used in the program, then have an M0 so the operator could load the tool if necessary and then cycle start the deal to load all of the tools in the program. Just looking for advice here and was wondering if anyone is using anything like this. Thanks in advance, Bob

The "Front" plane in SolidWorks is every other cad/cam systems "Top" plane. If you use this when creating the model you will have better luck. I agree with JG, if you make a local coordinate system on your model in SW, then do a "File", "Save As" and pick the Parasolids X_T format. Then look for an "Opions" button, pick that and you will see a "Output Coordinate System" dialog box. Select your new coordinate system and you're good to go. When you bring the file into MC it will have the correct orientation and the part origin will be where you set it in SW. Hope this helps, Bob

Hey Glenn, Thanks for the info, Huntington Beach, I grew up in Torrance, used to go to Ascot Park for all the dirt track racing stuff. I'l try the MPFan and see what I get. Also on your sample I have the force tool change after the 1st instance and again after the 2nd. Contour Man Entry Contour force tool change Man Entry Contour force tool change (this is the one where it doesn't output the work offset, height offset, ect. Thanks, BK

You can probably do a search and find more info but I found it here. If you have a MC file open, go the the Operations Manager, hold down the Ctrl and Shift keys and then double right click on the gray area on the right side of the operations list. You will then get a screen with some options like clean and dirty operations, etc. Select one and then OK and it will dump a bunch of the NCI info into the editor. You can then take a look at a lot of things, none of what mean much to me but I can see what is missing and affecting my code.

Okay post gurus, I have a program that is doing some chamfering (of the part hopefully) and then I am using TP Manual Entry for an M0 with some text notes. The tool does some more work and then I have another Manual Entry with an M0. The problem I am having is that on the op after the manual entry I am checking the "Change NCI" Force Tool Change option. It works correctly on the first stop but after the 2nd M0 I am not getting all of the work offset, height offset info, etc. Never had this problem before but this is the 1st time to use a tool, then stop, same tool work some more, then stop. I tried the Ctrl Shift Double Click Top Secret deal and can see that the NCI file is missing something on the 2nd startup of the tool after the Manual Entry. Can somebody tell me how to get this to work correctly? It seems that the "Force Tool Change" deal is not getting reset somehow. This post is base on the MPMASTER post with a few minor tweaks to make it Fadal friendly. Any ideas would be most appreciated. Thanks in advance, Bob

Try going to your Windows Start Menu, "Programs", "MasterCam 9.1", and pick the CNC Reg icon. You will see a "Persistent Column Width Keys" deal. I don't remember for sure but I think I hit the "Reset" option on mine when it was doing that. Seemed to fix it. HTH

Well Ron it looks like you win todays grand prize . . . whatever that is! Okay first off in defense of my post hacking skills (NOT), the ifcoolflg is what was really throwing me. It does not exist in the post at all, (I'm mean I'm not saying Ive never fumble fingered something in a post). Now for the good news, by removing the # from the "if coolflg = 1, pcooloff" the post works perfect! Thanks again for the tip and to all for the info! Bob

Tim, Thanks for the tip, I got tired of pasting code and then geting HTML errors, here is the section of the post . . code: ptlchg0 # Null tool change toolcount = toolcount + 1 #Index! prvtp = rbuf(3,toolcountp) #Index! if toolcountn <= tooltotal, nexttool = rbuf(4,toolcountn) else, nexttool = first_tool if tlplnno <> prvtp, n, pinc, "G28", "Z0" if tlplnno <> prvtp, pindex #Index! if opcode = three, ptlchg0drl #if opcode <> three & mi4<>prv_mi4, xabs = nextx #if opcode <> three & mi4<>prv_mi4, yabs = nexty #if opcode <> three & mi4<>prv_mi4, zabs = zr #if opcode <> three & mi4<>prv_mi4 & z <> zabs, n, *sg00, *zabs, e #if opcode <> three & mi4<>prv_mi4, n, *sg00, pabs, pwcs, *xabs, *yabs, e spaces=0 comment spaces=spaces_sav if op_id<>last_op_id, pstock #Stock! n, speed n, smcool if tplnout = one, ptplane last_op_id = op_id ptlchg # Tool change if numsub>0, n, "Z4.", e #Added for safe clear between vises n, "M99", e if numsub>0, " " subout = 0 mi4 = mi4org toolcount = toolcount + 1 #Index! tcount = tcount + 1 if toolcountn <= tooltotal, nexttool = rbuf(4,toolcountn) else, nexttool = first_tool if numsub>0, n = nsav # if prv_opcode <> 3, n, "G8 P0", e !opcode n, "M5" #if coolflg = 1, pcooloff n, pinc, "G28", "Z0", pcooloff if absinc = one, n, "G28", "Y0" n, "M1", e #if workofs<=0, workofs=54 #WCS! #if workofs=92, pg92_sof #WCS! #if mi4 <= three & mi4 > zero, pg92_out pinit # if numsub>0, " " n, *t, e n, "M6", ptoolcomm #Tool! n, "G0 G17 G20 G40 G49 G80 G90 G98", e #if stagetool = one, n, *next_tool spaces=0 if output_z = 1, preadbuf5 if output_z = 1, n, " (", "MAX | ", *max_depth, ")" if output_z = 1, n, " (", "MIN | ", *min_depth, ")" comment spaces=spaces_sav if tplnout = one, ptplane startflg = one nobrk_sav = nobrk nobrk = one pstock #Stock! pindex #Index! last_op_id = op_id