Mastercam's System Resource Utilization

[ad1187]

Something that's always perplexed me and that I've never been able to get a straight answer to, is why Mastercam doesn't use all of the system's resources when it's number crunching? It seems like I'm frequently waiting on Mastercam to generate toolpaths, post process, run machine simulation, etc., but if I glance at the system's performance the CPU utilization is rarely over 50%, memory is almost never over 15%, and the GPU only maxes out if I have a complex model that I rotate in the graphics window. 

I ask because we're trying to cut back our time spent on programming. If we could decrease Mastercam's processing time it would have a huge impact on how long it takes us to program parts (we do a lot of surfacing and multiaxis toolpaths). If it was as simple as upgrading our computer's hardware I'd gladly do it, but it doesn't seem like this would make any difference if Mastercam isn't working our current hardware to its full potential.

 

So, in summary I guess I have three questions:

1. Am I missing something fundamental in my understanding of how Mastercam uses the system's resources?

2. Is this consistent with what everyone else is seeing on their PCs?

3. Is there anything I can do (or hardware that I can buy) to substantially reduce Mastercam's processing times? 

 

Thanks in advance for any help!

 

• Mastercam 2018 running on Windows 10
• Intel i7-7700 CPU @ 3.6GHz
• 32GB of RAM
• Nvidia GeForce GT730

 

 

[lowcountrycamo]

Most of the crunching is done by the gpu correct? Is that an industrial card like quadro? There is a difference.   If it is, excuse me 

[pullo]

Intel i7 5 GHz (460 Euro in Finland) should give you a huge boost , I'm thinking -40%-50% in path calculation time reduction . Plz check out the Benchmark 3.0 test , so you can 

compare how you are doing.

That is if you want a solution to your problem , otherwise it is what it is .(I hate this line as something being said twice does not make anybody wiser , but it's the best non-cynical one  I have  )

Gracjan

[Tinyfxds]

Does Mastercam support multi core processing?  I know that some software limits the number of cores they use for crunching.  So in some cases maybe a dual/quad core would be better than a processor with 6-8 cores?  We have the same problem with Cimmatron right now.  Toolpaths take a long time to crunch but the software itself only uses one core to do the processing.  We have 8-core processors so we aren't really maximizing our computers resources. 

[pullo]

I opened the Benchmark 3.0 file and let it rip . Almost all cores lit up .  So recalculating will access several cores .  But  a single  new toolpath  being created dividing it's chores to 

several cores, I don't think so , but that is just an opinion.  I'll let somebody else, better informed chime in on this .

 

Gracjan

[jeff]

20 hours ago, ad1187 said:

 

• Mastercam 2018 running on Windows 10
• Intel i7-7700 CPU @ 3.6GHz
• 32GB of RAM
• Nvidia GeForce GT730

 

 

Your video card is.... sub par to say the least.

If you're doing small wireframe files it may be ok. But once you start manipulating any file with some meat, it's gonna struggle big time.

[Colin Gilchrist]

4 hours ago, Tinyfxds said:

Does Mastercam support multi core processing?  I know that some software limits the number of cores they use for crunching.  So in some cases maybe a dual/quad core would be better than a processor with 6-8 cores?  We have the same problem with Cimmatron right now.  Toolpaths take a long time to crunch but the software itself only uses one core to do the processing.  We have 8-core processors so we aren't really maximizing our computers resources. 

Yes, and No.

The "newer" HST Paths, and Dynamic Paths, are Multi-Threaded. Many of the "legacy" paths in Mastercam are single-threaded only. I hear that is changing for 2019, but haven't explored this yet.

The more that you can transition your work flow over to using the new HST paths, the more you'll be able to harness the power of Multi-Threading, which you can control/see inside the Multi-Threading Manager. (Allows you to change the "process priority" to "high", which should boost calculation time by 10-40%, depending on your hardware specs.)

Read up on the "Benchmark Thread". You'll get some good recommendations on Processors, RAM, and Video Cards that work together to make the best Mastercam system possible.

The first question I would ask is: what is your percentage of available RAM that your system is set to use? (Look in your Configuration Dialog) I recommend setting this to between 70-80% of available RAM.

 

 

[ad1187]

Thanks for all the replies. Below is a series of screenshots (taken in order) showing the resource monitor while regenerating the operations in the benchmark file. The CPU usage looks like it spikes to 100% when it starts processing a new toolpath, but then rapidly drops to 50% or below. Along with this the memory usage is never above 20% and it looks like the GPU isn't getting worked at all. Can this be right?

1 hour ago, Colin Gilchrist said:

Read up on the "Benchmark Thread". You'll get some good recommendations on Processors, RAM, and Video Cards that work together to make the best Mastercam system possible.

The first question I would ask is: what is your percentage of available RAM that your system is set to use? (Look in your Configuration Dialog) I recommend setting this to between 70-80% of available RAM.

 

 

I took a look at this (configuration>toolpaths>memory buffering). It's set to 95% of physical memory. I've also read through the benchmark thread. My computer comes in at 4:48 which doesn't seem too bad in comparison.  

Suppose I upgrade to the best processor and video card money can buy. Will Mastercam still only work the processor to its full potential a fraction of the time (or not at all in the case of the GPU)? If this is the case it seems any improvement wouldn't be very significant.

Am I crazy for thinking that Mastercam is the performance bottleneck here, and not the hardware?  

 

[crazy^millman]

In the Multi Thread manager are you right clicking on the process and kicking them up to high? I see major reduction doing that. Before anyone asks no there is no way to force it to stay high and yes the user must do this for every operation and yes it is a pain and yes I(we) have requested it going back to X9 and no I have no idea when it will get added to the software ad yes I will argue with anyone that says it doesn't make a difference because I have tested it numerous times and have well over 100 different people who back me on that making a nice difference. Sorry not directed at you just a general answer to many that may read this and have questions that hopefully I just covered.

[ad1187]

35 minutes ago, C^Millman said:

In the Multi Thread manager are you right clicking on the process and kicking them up to high? I see major reduction doing that. Before anyone asks no there is no way to force it to stay high and yes the user must do this for every operation and yes it is a pain and yes I(we) have requested it going back to X9 and no I have no idea when it will get added to the software ad yes I will argue with anyone that says it doesn't make a difference because I have tested it numerous times and have well over 100 different people who back me on that making a nice difference. Sorry not directed at you just a general answer to many that may read this and have questions that hopefully I just covered.

 

Just gave this a try and I'm seeing roughly the same result;  ~5 minutes from start to finish. I took screenshots of the CPU usage again and compared them with the screenshots I took when the operations were set to normal priority. The graph profiles look almost identical with only a few minor differences.  

[Matthew Hajicek - Singularity]

For the last few builds I've based my CPU choice on this benchmark:

https://www.cpubenchmark.net/singleThread.html

Using that I've built workstations ranging from $2600 to $3600 new that have had top end Mastercam benchmark scores and stayed performing well for years.  That said I like the "legacy" surfacing paths, and use a lot of stock models, so single-thread or just a few threads at a time for a lot of it.  I do use the "Optirough" stuff, but usually don't have to wait very long for it.

Let's try a thought experiment.  Say we have 100 gallons of work to do.  You can choose one CPU with four pipes of 5 gallons per minute or another with 8 pipes of 3 gallons per minute.  The one with 8 pipes has more throughput when all pipes can be used (24GPM vs 20GPM), but if a task is thread-limited to four, two, or one pipe at a time it's slower.  20 vs 12, 10 vs 6, and 5 vs 3 respectively.  If you consider that thread-limited tasks are going to take more time regardless of your processor, the time saved by slightly speeding up the tasks that are already fast is much less than that saved by speeding up the slower tasks by going the other way.  If we have 25 gallons of 8-thread, 25 gallons of 4-thread, 25 gallons of 2-thread and 25 gallons of 1-thread, these should be your numbers:

8 pipes of 3GPM each:

1.04 minutes, 2.08 minutes, 4.17 minutes, plus 8.33 minutes = 15.62 minutes total.

4 pipes of 5GPM each:

1.25 minutes, 1.25 minutes, 2.5 minutes, plus 5.0 minutes = 10 minutes total.

[ad1187]

Thanks Matthew. That's the best explanation I've heard yet. I might give the highest ranked single thread processor a try.

Does anyone have any sense for what role, if any, the graphics card plays when Mastercam is number crunching? From what I'm seeing it looks like it does absolutely nothing. Like I said in my original post the only time I can get the GPU to spike to 100% usage  is when rotating a model in the graphics screen. If I were to upgrade the video card would I see any improvement in processing time?  

[Matthew Hajicek - Singularity]

To the best of my knowledge the GPU is only used for rendering, so won't affect crunch time unless the GPU is slow enough to make the CPU work harder.

[pullo]

GPUs are used for number crunching  mainly in Bit coin mining, for us it's just spinning a shaded  representation of the parts either smoothly or not .  To prove this , just do the Benchmark 3.0  with the window minimized or not (i.e. no Grahics  to calculate ). there should be no time difference.   This is not the best example for proving this point, as maybe turning on/off  hardware acceleration would be a more of a difference maker ....

Gracjan

[CristiP]

recently I programmed some big parts 80% made by NURBS surfaces. "Legacy" toolpaths took a lot of time to calculate the toolpath but the HST were 70% faster.