File size stability

[MrFish]

At what file size do people find that mastercam just becomes too un-stable and it is better to start dividing into seperate toolpathing files.

i.e a file for roughing, semi finishing , finishing etc.

 

Mostly talking mould files that end up with large numbers of toolpaths and stock files that quickly produce files in excess of 300mb.

[Redfire427]

I've had fairly good success up to around 100MB, but then after that, it can be full of adventure.

 

Carmen

[MrFish]

I've had fairly good success up to around 100MB, but then after that, it can be full of adventure.

 

Carmen

 

Thanks for reply. I am struggling with a 300MB file at the moment. Think the stock models are choking it up. Unfortunate as I like the extra refinement it achieves with the rest mill toolpathes.

[Jaz]

I have had no problems with stability in large files. But anything over about 200 Mb gets really sluggish, with long waits for things to get done.

[gcode]

I'm running Win7x64 with 32gig or ram and a Intel SSD for the OS drive.

This machine has been very stable and responsive with big files.

I've been using stock model a lot and files get huge in a hurry.

I rarely make files that would get to 300 meg with just toolpaths though.

[kdgrills]

~300MB files are pretty typical for us, nothing but the usual Mcam issues.

Generally over 1GB & things start to get interesting.

 

The cavity insert I recently finished ended up at 1.4GB for rough / semi

and 1.2GB for finishing, I think the core was 2.1GB. Takes 10 minutes

or so just to open the files. IIRC there were +60K surfaces in the cavity.

Once open things are sluggish, but workable.

 

I had to break my paths up into quadrants, otherwise I'd end up with

"memory" errors while generating. Every few paths I'd restart Mcam,

otherwise I'd end up with 0 byte NCI files.

 

I never physically ran out of RAM, just seems to be general Mcam "quirkiness".

UG handles the parts MUCH better, unfortunately we don't use manufacturing.

 

Running X5, FWIW.

[MrFish]

~300MB files are pretty typical for us, nothing but the usual Mcam issues.

Generally over 1GB & things start to get interesting.

 

The cavity insert I recently finished ended up at 1.4GB for rough / semi

and 1.2GB for finishing, I think the core was 2.1GB. Takes 10 minutes

or so just to open the files. IIRC there were +60K surfaces in the cavity.

Once open things are sluggish, but workable.

 

I had to break my paths up into quadrants, otherwise I'd end up with

"memory" errors while generating. Every few paths I'd restart Mcam,

otherwise I'd end up with 0 byte NCI files.

 

I never physically ran out of RAM, just seems to be general Mcam "quirkiness".

UG handles the parts MUCH better, unfortunately we don't use manufacturing.

 

Running X5, FWIW.

 

You must have the paitence of a saint to work like that !! I am getting frustrated with the "quirkiness" at 300MB file size and have started to devide files up from that size. Currently up to 3 files for the cavity I'm programming.

[kdgrills]

You must have the paitence of a saint to work like that !! I am getting frustrated with the "quirkiness" at 300MB file size and have started to devide files up from that size. Currently up to 3 files for the cavity I'm programming.

 

Heh, that cavity insert was over 300MB before I put any toolpath on it.

I hate splitting stuff up, but sometimes ya gotta do what ya gotta do.

[Aaron Eberhard]

kdgrills - I can't believe you're working on 1Gb+ files without using the latest version... Ouch! The (computer) hardware usage is way better in X6, and better yet on X7. Take it for a test drive, I think you'll like it.

[kdgrills]

kdgrills - I can't believe you're working on 1Gb+ files without using the latest version... Ouch! The (computer) hardware usage is way better in X6, and better yet on X7. Take it for a test drive, I think you'll like it.

 

You'll get no argument from me.

 

For various internal reasons we're stuck at X5. Mostly because we're an old (+100 years) stodgy company,

a lot of people here don't like change. If I wasn't here prodding them they'd probably still be running V9.

 

I downloaded X7 to play with, turns out our maintenance expired last August. Oh well.

[Aaron Eberhard]

You'll get no argument from me.

 

For various internal reasons we're stuck at X5. Mostly because we're an old (+100 years) stodgy company,

a lot of people here don't like change. If I wasn't here prodding them they'd probably still be running V9.

 

I downloaded X7 to play with, turns out our maintenance expired last August. Oh well.

 

It may be better for you that maintenance expired. "A luxury, once sampled, becomes necessity" it is said... And it would quickly become necessity for me if I were working with stuff like that.

[Roger Peterson]

This is a tough question as it all depends on your pc and wether or not your working with solids or surfaces. There is some general slowness just from working with solids instead of surfaces. Other than that I've been on pc's that handle 500mb files better than another pc with a 20mb file. I would agree in not splitting things up, if your typical files are slow and hard to work with you just need a higher end pc. Stock models add up, you may be better off creating the stock model then saving it as a stl file so you can delete the stock model. Hopefully we'll get a "compressed stock model" in the future to help with this.

[Jayson Kramer]

can you share one of these large files I would like to see how it is on a few of my rigs?

[kdgrills]

can you share one of these large files I would like to see how it is on a few of my rigs?

 

I could, but then I'd have to kill you. ;-)

 

But seriously, my employer would frown on that, sorry.

[kdgrills]

It may be better for you that maintenance expired. "A luxury, once sampled, becomes necessity" it is said... And it would quickly become necessity for me if I were working with stuff like that.

 

After a little investigation, it turns out that we're actually current on maintenance.

Somebody just felt it wasn't important to distribute the hasp code files.

 

Migrating the previous configuration files now.

It'll be interesting to see how X7 handles these (large) files.

 

Unfortunately it'll be a LONG while before we ever implement a newer version.

Maybe all the bugs will be worked out by then. ;-)

[gcode]

After a little investigation, it turns out that we're actually current on maintenance.

Somebody just felt it wasn't important to distribute the hasp code files.

 

Migrating the previous configuration files now.

It'll be interesting to see how X7 handles these (large) files.

 

Unfortunately it'll be a LONG while before we ever implement a newer version.

Maybe all the bugs will be worked out by then. ;-)

 

If you're running XP x32 with 4 gig of ram, you're not going to see a huge difference.

The most improvement comes from being able to run Win7x64 and large amounts of ram.

[Thee Rickster ™]

Gcode, makes a good point.

64 bit and a killa vid card is IMO a necessity for todays cad cam packages

[kdgrills]

If you're running XP x32 with 4 gig of ram, you're not going to see a huge difference.

The most improvement comes from being able to run Win7x64 and large amounts of ram.

 

Win7x64, 12GB RAM, 3.2Ghz Xeon processor.

X7 on XP = no go

 

Edit:

 

Quad core, Quadro 2K video.

[gcode]

Gcode, makes a good point.

64 bit and a killa vid card is IMO a necessity for todays cad cam packages

 

Yup ..X7, a fast i7 proccessor, 32 gig of ram, a Quadro 4000 (or the new K4000) and a solid state hard drive.

the difference between that and an old X5 XPx32 system is night and day...

 

A good time on the benchmark file for a plain jane X5 XP rig was under 3 minutes.

This rig running X7 is well under a minute... and the overclocking crowd as seen the south side of 30 seconds.

 

If you figure $50 an hour overhead and you're running 1gig Mastercam files

I'll bet you spend A LOT of time waiting for your machine to finish doing things.

 

You ROI on a $3K i7 machine running X6 or 7 would be pretty quick.

[gcode]

X7 on XP = no go

 

try the x64 version of X6 MU1

[kdgrills]

A good time on the benchmark file <snippage>

 

What / where is the benchmark file?

[Thee Rickster ™]

Its in the 'important topics' thread pinned to the top of the main (this) forum home page

[kdgrills]

Been playing with a 1.4GB file in X5 & X7 for the last hour.

X5 takes 6 minutes to open it, X7 is at half that (3 minutes).

 

Both versions take ~30 seconds to shade. In X5 I can't

manipulate (rotate, etc.) the shaded model, in X7 it's

just a bit sluggish but I can manipulate it with no issues.

 

Haven't compared any toolpathing yet, hopefully I'll

see similar improvements.

 

I'm sure any further comments I have will be specific to

X7, so I'll move over to the X7 thread at this point.

[gcode]

Been playing with a 1.4GB file in X5 & X7 for the last hour.

X5 takes 6 minutes to open it, X7 is at half that (3 minutes).

 

Both versions take ~30 seconds to shade. In X5 I can't

manipulate (rotate, etc.) the shaded model, in X7 it's

just a bit sluggish but I can manipulate it with no issues.

 

Haven't compared any toolpathing yet, hopefully I'll

see similar improvements.

 

I'm sure any further comments I have will be specific to

X7, so I'll move over to the X7 thread at this point.

 

If you are using any high speed surfacing toolpaths,be sure to open the multithreading manager and

tell it to use all 4 of your proccessor's cores

[Aaron Eberhard]

Been playing with a 1.4GB file in X5 & X7 for the last hour.

X5 takes 6 minutes to open it, X7 is at half that (3 minutes).

 

Both versions take ~30 seconds to shade. In X5 I can't

manipulate (rotate, etc.) the shaded model, in X7 it's

just a bit sluggish but I can manipulate it with no issues.

 

Haven't compared any toolpathing yet, hopefully I'll

see similar improvements.

 

I'm sure any further comments I have will be specific to

X7, so I'll move over to the X7 thread at this point.

 

Sounds like you're on the right path! Just a quick question: Do you have a DECENT SSD running your rig? There's a lot of load/save time to be had with that over the old spinners