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.