We use Winzip here. With the latest versions, you can setup a job to run with one click. Choose what you want backed up and setup the job so the backup is stored generically. IOW, any zip program can retrieve info from the backup. I got tired of special backup formats that change everytime a company updates their software. I then take the backup archive and copy it to whereever I want. External hard drives that are kept in a fireproof safe at work, and another that is at my house. I do NOT trust 'the cloud' except for non critical information. I know that someday, somewhere I will probably lose some information, but using this approach for the last twenty years I have survived all of murphy's attempts at screwing me over.

Oh yeah, one other thing. For the 'cutting method', pick SPIRAL. Really smooth toolpath.

Yep, blend is a great toolpath. I use it 90% of the time, due to the fact that most of my toolpaths contain hundreds of surfaces. One thing not mentioned yet is to try to keep the inside and outside chains starting at the same radial position. By that I mean I always try to start my chains at the 90° position (12 o'clock), even if it mean breaking a chain there. I think this gives a smoother surface, unless I miss my guess. (at least, it looks better as it's being created.

Although it's always best to give as much info as the operator will need, sometimes it's just not possible. Some people are either too dense or just don't care. For instance, a while back, (long while) I gave an Operator a sheet with a very critical bit of information written rather large in red and circled in green. He 'missed' it. The next time I gave him a setup sheet, the important info was written in red and circled with every color of pen and pencil I could find. I think something like 15 different colors, taking up about 1/3 of the entire sheet. .....yea, he 'missed' it. What ya gonna do. :-)

MLS - WE use mostly parallel, scallop, flowline or blend toolpaths. They are for high precision punch faces with typically over 300 surfaces, and we need a .0005 stepover for the small .010ø ball cutters. some of these cover a 2" by 4" surface area maybe .050 deep. Much variation, many tiny letters, all rounded, tiny corner radii down to .005. Takes maybe 15 hours to cut.

Yep, the 70 meg path took something like 10-15 minutes. I actually save that compressed in a zip file for later use also. Which is why I don't need the toolpath data in the MCX file. Chances are that If I need to regen it again sometime in the future, I'll have to change cutter sizes slightly. The toolpath definition itself will be valid, but the actual NC code MAY have to be different because the teensy, tiny ball cutter I'm using (.010ø) may be .011ø or .0095ø the next time. I just never know for sure until the time comes. Bottom line is I don't need to have the nci data stored with the source code, so being the anal person that I am, I don't want to take up the space. :-)

Andre: Tried looking at those settings. no Joy there. Thanks, though. MLS: Yea, tried that in the past. As you thought, it doesn't get rid of all the nci data though. gcode: Yep, been zipping all our source files for years, stored by an internal code number and cross-referenced 8 ways to sunday with a custom program I wrote in a past life:-) Even so, that 10 meg file can really be less than a meg, so I still like to store as little as possible, even with today's rediculously large drives. Just a personal thing with me I guess. I think you're right in that there is no way to do what I want in one step. I am going to take this up with CNC software to see what they have to say. Maybe it'll be in a future release as an option?? Thanks all for the suggestions. If I find an answer, I'll pass it along. Don

Maybe I didn't say that right. I have programs that have very small stepovers (.0005 per pass on a scallop path for instance). These are very intricate electrode programs for punch faces. If you define the toolpath and regen it in preparation for posting, the data generated (that I thought was called nci data) on these programs can exceed 50 megabytes in size. You can see this when you look at the toolpath size in the operation manager. If I then save the file (the MCX file) the resulting disk file will be huge. For example, on a typical program I just checked, after defining the toolpath and regening it, the toolpath size (in operation manager) is 73,618K. thats 73meg, basically. If I save the file and look at the properties on disk, it is 75,271K bytes in size (75 meg). If I then load the file back into Mastercam and immediately save it, the resulting file on disk is 1653Kbytes (about 2 meg). This is because the toolpath hasn't been regenerated and the operation manager shows the toolpath size as zero K (0 Kbytes) when I save it to disk. What I am trying to accomplish is this final result without having to reload the file and resave it. It seems to be an extra step one shouldn't have to do. The final result is a file with all toolpaths defined and ready to regenerate later if necessary, but a small size for archival storage.

for the life of me, I can't figure out how to save the MCX file WITHOUT all the toolpath (nci) data. I do want to save the toolpaths, naturally, but not the nci data. Makes for way too large files. I can save the file, reload it and save it again (without regening the toolpath) to get the MCX file without the nci data, but that's an extra step that shouldn't be necessary. I know storage is cheap, but there just isn't any need for storing a 50MB file when it only needs to be 2MB. Is this just that way MCX3 works, or is there some switch to turn off that I haven't found yet?? Using ver. MCX3 mu1

Microsoft Standard Wireless Optical Mouse Intellipoint 5.2 Dell Precision 380 Win XP Pro SP3 nVidia FX1400 video card Mastercam 9.1 and X3 MU1 All works fine, both in 9.1 and X3 I had tried a Microsoft Explorer 2.0 mouse that had problems even with the same driver, but the standard one works well. I know that may not make any sense, but that's my story and I'm sticking to it.

Daniel, Something to consider. Get a part that neither of you have seen before. Something that would take maybe 1/2 hour to an hour to complete. Have you both start at the same time. Hopefully, you finish first with X3. :-) anyway, assuming that happens, maybe you could then show this guy WHY you finished first because of the better tools available with MCX? Just a thought. I know it's kind of a backdoor way to get thru to him/her, but it might prove useful. Perhaps even better would be a part that could ONLY be completed with MCX, assuming there is a beast.

Whew! OK, I guess I exagerated on the 200 times a day. Sheesh. Jay, thanks for the ifo on the Dell. Right now we have a Dell precision 380 with 4 gigs, and an FX1400 quadro card. Maybe time to upgrade. JM2C, I'll try the getting rid of the splash screen. Thanks for the tip. Hardmill, thanks for the links. Again, maybe it's time to upgrade a bit.

OK, I admit that I still use V9. I use the new functions in X3 when I need to, but most of the stuff isn't of any value to me for what we do here. The main reason I haven't moved completely to X3 is the startup time. Version 9 starts in about 2 seconds, and X3 takes up to 20 seconds to start. I realize I can leave it running all the time, but I don't like to do that. I am in and out of MC9 200 times a day. If I had to wait each time for more than a second or to for it to start I'd go nuts. (more time than you want to spend listening for me to justify this) Yea, there are solutions to this, but a new $4,000 computer isn't one of them for me. The real solution is to have MCX optimized for startup time. This is not just a problem with MCX, but with most software. Too much time spent getting the program out the door and not enough time spent making it right. It will never change, unfortunatly.

About the screen capture: This only works if you have Autocad or some other solids program, but if you do it works really well. We use Autocad 2000 as well as Mastercam. Save from MC as an autocad .DWG. Load into Acad, and render as a high res tiff file. The advantages are you can roll the solid around anyway you like in Acad and save multiple views. I suppose this would work in any solids program, but we have Acad. There may be another way strictly in MC, but I don't know of it. others may. p.s. you can convert the tiffs to jpgs afterwards. (much smaller files)

You could try "create surfaces", but my experience is there will be some missed spots. If you are getting this while importing a STEP file, try asking your customer to send a parasolid. We just went through this with one of our customer, and while step files had this problem, parasolids came through fine.

Being a small shop, I get to see about half of the stuff I program actually run. Mostly, I could see any of it if I need to, but with wire EDMs, Jig Grinders, Gear grinders, and CNC Mills to program for, I don't always get the chance. I have run all those machines in the past, and still do run all of them occasionally, as the need arises. Like this week, the operator for the wire EDMs is on vacation, so I'll be in charge of making sure the secondary op knows what's going on. It'll be a fun week :-)

If your MCX file is a solid, you can save it as Autocad 2000 format (DWG) and it will show up as a solid in Acad, and should also in Solidworks. If your MCX file is surfaces, convert to a solid first. Surfaces don't come over into .DWG. Or, as already suggested you could use parasolid. I just tested this on one of my files, and Autocad 2000 can read the solid (DWG) from MCX fine. Just not surfaces.

I LOVE this thread! We have one NC mill operator that insists on having the program start at the back of the machine so the cutter doesn't pass over the top of the piece on it's way to the start point. Not a big deal, but he's a fanatic about it. For some reason he thinks that the cutter is somehow going to magically hit the piece during one of the starts, even though it's 2" above during the pass over. He will refuse to use any program that has the cutter passing over the top during start/stop. Same guy insists on cutter comp at the machine even when the part has ±.020 tolerance and we know what cutter he's going to use. About once a year he asks me if he can have cutter comp on a 3D surface program. I always answer "soon as you cough up about $200,000 for a new machine". Does make the day interesting, though.

We just use a mill post for wire here, also. Taper is just added into the NC code after posting. Only ever did one 4-axis job, years ago. Output 2 separate codes and I wrote a program to convert the XYIJ's and merge the programs together. It worked, but I wouldn't want to do it on a regular basis. If we ever get into that, I'll get MC wire. Bottom line, if you never do 4-axis, MC wire is unnecessary.

I have found that if you explode any polylines created in Acad, they come in clean into MC. I am having the opposite problem, though. The imported Acad file is better than the MC created one! (when entities are broken at intersection points) Strange

Hi all, I've uploaded two files into the MCX files directory at the FTP site. WITHMC.mcx WITHACAD.mcx Both are simple squares (centered) with a circle attached tangent to the middle of the bottom edge. One created entirely in Autocad 2000, one created entirely in MCX. The one created in Acad was imported into MCX and then the circle and bottom line broken at the intersection of the two. Look at the endpoints of those entities (withacad.mcx). MC reports the endpoints at X Zero, as they should be. The file created in MCX (withmc.mcx)and broken the same way shows the endpoints at X-.0001381. What the heck??? I have been having this problem since ver 8.1. It is driving me nuts. You would think that if the geometry was created in MC, it would be the most accurate way to do it, but noooo, the files created with ACAD and brought into MC breaks at the correct points. Has anyone else run into this??

I've used Zonealarm for years as a firewall at home, and AVG free for antivirus. Have recently gone to Zonalarm antivirus at work and at home. Firewall (excellent) and antivirus in one program. It does a great job with very, very minimum setup hassles. Another really nice FREE program is http://www.mlin.net/StartupMonitor.shtml It helps to find things BEFORE they become a problem. With that running, you will be amazed at the kind of crap that tries to install itself as a startup process.

Glad to help. For the future... If you get into gears more, there is a great little book that will help a lot. From "The Van Keuren Co." It's called Precision MEasuring Tools - Handbook #36 - Section II. I don't know whether it is still in print. Ours is so old the price listed in the book is $2.00

Mike, Back at cha. You have mail. Don

Mike, Yes, the one I drew has just standard OD & Root that would be for a standard gear. An Involute spline just has those clipped off. Involute is the same, you're just looking at a particular portion of it. The tooth form wouldn't change if you change OD or ROOT. You can just create the circle you want for the OD (major ø) and the ROOT (minorø) and trim off the part of the involute that falls outside those circles. On a gear, the OD and Root have nothing to do with the involute. (tooth sidewall) There are standards for the OD & ROOT, but a majority of gears are altered from those standards. I just made it that way so you could trim it to what you needed. The Involute is controlled by the Pitch ø, number of teeth, and either CTT or MOW. The CTT is altered plus or minus for clearance, based on the gear it is to mate with. There are a number of other considerations, but there are large books devoted to that. One thing to note for your parameters is that the MOW in your original post doesn't work with the CTT. Those two things are intimately tied together. One HAS to match proportionally with the other. You will want to check on that. Hope this helps. Don p.s. you can certainly email me the scan and I'll take a look at it.