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