Resource Utilization: CAM

[Steinwerks]

This is a very simple request, and it relates almost exclusively to CAM toolpath processing/generation. I want the CAM aspect to utilize more of my processing power. I have eight cores, but the CAM kernal is only running 13% load while everything else (and it's not much while I'm trying out adaptive clearing toolpaths) runs like nothing is going on at all.

I'd really like the ability to ramp up the system power I've got that Fusion uses, if not only for toolpaths, then for everything. 75% CPU load still leaves me with two cores, but I also suspect that at that level it'd generate even heavy duty paths rather quickly. Otherwise things are great, and it beats the pants off of waiting almost an hour for Mastercam to do the "same" calculations.

[roambotics_scott]

Sounds single threaded (1/8 = .125 which is pretty close to .13 🙂

I'm sure there are lots of opportunities for parallelization but it seems like in most cases toolpath generation could be easilly decomposed in the time domain (especially if you don't mind a tiny bit of reduncy in the cutting paths).

[Helmi74]

I'm not that sure about cam and toolpath generation (maybe Anthony or one of the other CAM guys will jump in later) but in regards to Fusion360 generally lots of stuff is handled serverside and i thought i heard that this is also true for CAM in Fusion360. Basically this is the sense of cloud computing. Don't know about the complexity of your toolpaths but the few i did so far were generated quite quickly so i don't have a real need of more power here.

Where local power of Fusion360 comes into place is for displaying live views in the design or doing quick raytracing - all other renderings also happen in the cloud AFAIK.

[Steinwerks]

This is true, I do not know if toolpaths are handled locally or not. I will say that once you get into large adaptive clearing areas with multiple features and one or more rest machining operations, this can take some time. As I said in my original post, it's still far better than Mastercam working off of practically the same geometry by at least an order of magnitude (granted it's X6 on a dual core, but still...).

Just making suggestions where I see useful improvement possibilities.

[jeff.pek]

Generally, the toolpath generation should already be using all available cores. I'd be interested to see the model/operation(s) where you're seeing this partial utilization.

Thanks,

  Jeff

[anthony.graves]

Have to run out for a bit but my reply will take a little time to type up. Just wanted you to know that I'll be back to get you some more insight into how we process toolpaths.

Anthony Graves

Product Manager, CAM

[anthony.graves]

Ok, back.

The Autodesk CAM / HSM CAM Kernel is multicore/64-bit. All of our toolpath strategies and our Simulation are designed to utilize the maximum number of cores (now supporting 36 physical cores/72 threads) available on a single workstation. Our desktop products (HSMWorks and Inventor HSM) also include something called Distributed CAM, which allows us to distribute toolpath calculations across a LAN to leverage available cores on additional computers/workstations with the use of a small service that is loaded in the background. So, why 13%? Adaptive Clearing.

Unlike all of our other toolpath strategies, Adaptive Clearing, our high efficiency roughing strategy, uses an advanced technique that constantly evaluates what stock is being removed and what stock is remaining. This means that we are often only able to use a single core or less than the full number of cores on a workstation. The results you achieve with Adaptive are pretty amazing; reduced cycle time, reduced wear of your tooling, and reduced wear on the machine.

If you are programming for production, the calculation time is insignificant (written off). If you are doing primatic parts or even 3D parts the calculation times are often measured in minutes (often less than 10, depending on the part) so it's never really an issue. Where calculation times get irritating (despite all the benefits of the resulting toolpath) is when you have parts with features such as near vertical walls or large numbers of pockets with uneven floors or near vertical walls that require a lot of calculation. Remeber, we're tracking the stock and calculating the optimal tool path while calculating engagement. So, all that to say this - we are constantly looking at ways to optimize calculation speeds and leverage as much computing power as possible. We have some great ideas we are planning to implement next year that will help reduce calcuation time further. Stay tuned.

By the way, great observation and great feedback.

Anthony Graves

Product Manager, CAM

cam.autodesk.com

cam.autodesk.de

[Steinwerks]

Wow, this was a while ago! The part in question I actually wound up programming in Mastercam in multiple postings due to the memory limit of the machine I was using. Due to a very rigid machine and very limited spindle speed, a traditional roughing pass with about 90% stepover was utilized. I can share the project with you Anthony if you wish, but there was nothing used in Fusion in the end.

[Steinwerks]

Oh, and I should add that although the camkernel spiked to 18% a few times, it was normally operating at 13% still across only four of the eight cores present.

[jeff.pek]

This is something that we are continuously working to improve, so watch for additional core utilization as new releases are made available.

  Jeff

[anthony.graves]

atomkinder67 - just reaching out to see if what your experience has been lately. Outside of Adaptive, are you still seeing utlization numbers low like before? If so, shoot me an email at anthony.graves@autodesk.com with your phone/mobile number. I'd like to reach out and do a GoToMeeting to do some tests.

Thanks,

Anthony Graves

Product Manager, CAM

[al.whatmough]

This is something that is ongoing.

Certain parts of toolpaths do need to be solved sequentially.  So, they can not be multi-threaded.

That is certainly the case with adaptive clearing.

With that said, we have made significant improvements to adaptive over the pas 2 years .

Please don't take the implemented status to think that we are done making inprovments.

This is an ongoing task.