incredibly slow calculation time for all toolpaths

[spriceK8FYA]

We are having issues with the calculation times for  seemingly all toolpaths. Our IT department has worked relentlessly to upgrade our equipment and to make sure that we are using our digital resources to their fullest potential.  Unfortunately, there has been no improvement in the calculation speed. I figured that maybe someone here might have a solution or some guidance.

Here is an email I got from IT:

I can confirm that after calculating any toolpath, saving and closing the file, then reopening the same or any other file and calculating another toolpath, a SIGNIFICANT amount of time is added to the operation. I have confirmed and documented a minimum of 23.61% all the way to 94.84% decrease in calculation speed when following this standard process. These results seem to be consistent regardless toolpath strategy used.

The only way to reliably remove this extreme decrease in speed is to save the file, completely close Powermill, re-open Powermill, open the file and run your calculation each time you need to calculate a new toolpath. This seems unreasonable.

Can you help me get this in front of an Autodesk Powermill engineer so we can report this bug and potentially learn of a workaround?  

[emilie.a]

@spriceK8FYA 
 We have some improvements in the pipeline for next year that should help with this situation, but they need to go through our regular Quality processes before we release them.
I'll try and remember to get back in touch with you when they're released to check whether it improves your experience.

[TK.421]

What are your computer specs? What version of PowerMill are you running? Are you able to zip & upload a project here for others to download and test it? 

@iamcdn79 wrote a macro on this thread that you should run and compare the results with others on there. Without giving more information, there could be any number of reasons you're having issues.

[glen_h]

@emilie.a 

We've never heard that before!

[Nateamus]

@emilie.a, The OP is referencing a very specific "bug" I found where the speed degrades with subsequent toolpath calculations in the same session.

For the cleanest results, make sure nothing unnecessary is running outside the OS and PowerMill. Here is the scenario:

Step 1: Close everything you're running and open a fresh instance of PowerMill 2024 Standard or Ultimate, it doesn't seem to matter.

Step 1a: Open a file and calculate a toolpath (Toolpath A). Time the calculation.

Step 1b: Completely close PowerMill.

Step 2: Open the same version of PowerMill as in Step 1.

Step 2a: Open the same or different file and calculate a completely different toolpath (Toolpath B). Time the calculation.

Step 2b: Completely close PowerMill.

Now you have two baseline calculation times from which you can test this “bug”.

Step 3: Start fresh again by opening PowerMill. Same version (for those who run both Std and Ult).

Step 3a: Clone/Calculate either Toolpath A or Toolpath B from above and time the calculation. Your time should be reasonably close to your baseline time (my testing is quite consistent at <1% variance.). Save and close the file or use it if it also contains your second toolpath. This bug doesn’t seem to care if it’s the same file or not.

Step 3b: Keeping PowerMill open, navigate to the second toolpath and clone/calculate it, timing the calculation.

This second calculation will be significantly slower than its baseline time. My testing shows a speed degradation of around 23%. The insidious thing is that this degradation increases with each subsequent calculation. I have personally stacked to over 400% slower speeds when moving from calc to calc without closing PowerMill.

The workaround for some could be to close and reopen PowerMill after every calc. You WILL see significant performance gains. The problem is when dealing with the size of files we do, these gains are erased by the time it takes to open the file.

This happens to be independent of hardware. My testing shows that these findings are valid regardless of CPU/RAM/GPU performance. My fastest test unit running an Intel core i9-13900KS degrades by the same rough percentage whether overclocked or not, P-cores, E-cores, Hyperthread or no. Doesn’t matter. Strategy/Toolpath type doesn’t seem to matter either.

@emilie.a  Can you test or get this regimen in front of a support engineer so they can confirm? I'd love any thoughts from the community as well. Hubristically, it feels like some basic caching hygiene in a patch could make quick work of this issue if it's validated.

Thank you everyone, for your time!

NAB

[glen_h]

I am curious. For those of you experiencing this issue...are your Powermill project folders parked on a drive on your PC, or are they parked on a network drive?

[spriceK8FYA]

Network for us

[metalurgicaprogreso]

Network for us as well

[TK.421]

Sounds like it may be a network problem. I run all my stuff on my desktop and cut/paste back to network after i'm done. i have no speed issues (other than the standard stuff...).

[iamcdn79]

Same

[spriceK8FYA]

The problem with that for me would be that we are given a space allowance and we are dealing with extremely large files so I dont think that would work. Unless we are granted more space. I will have to look into that. Sounds promising.

[spriceK8FYA]

Here is the results of the benchmark macro. This is using Powermill Ultimate 2024.

[metalurgicaprogreso]

I find this situation completely unacceptable. We are now forced to use powermill locally (disconnected from the network) and that create a HUGE risk that the machine shop could execute an out of date toolpath. This has got to be fixed urgently.

[metalurgicaprogreso]

It look like autodesk is looking for ways to make powermill worse, instead of advancing the software. They should get their act together.

[TK.421]

sounds like you guys need to implement some quality procedures to ensure that doesn't happen. There's a reason a lot of us do things locally on our pc and have zero issues like this. i do the same thing for our inspection software, and to some degree, my solidworks (can i say that word on this forum?) projects. Our network sucks, and if it's bogged down with other users and all the other network tasks, it runs really slow...

don't get me wrong, i'm all about blaming the software, but in this case i don't think that's the issue

[metalurgicaprogreso]

Dear @TK.421 

There are two comments I would like to make in regards to your previous post because I was not clear enough in my previous post:

1- We have the quality procedures.

2- Our network works flawlessly. It is 2.5 gbit network and storage is handled by an nvme ssd server (we can discuss network configs in another thread).

What is happening here is that due to a bug in the software we are forced to break procedure and work locally, which is a completely unacceptable situation in an era of networked communications and cloud computing. It so 1980s.

If powermill worked correctly, we would not need to break our existing and perfectly implemented procedures to bypass a bug.

There is absolutely no reason why we should be working locally. None.

I am not complaining about mistakes made. I am complaining about inefficiencies generated by the extra control burden imposed by software glitches. Maybe you would want to analyze this issue through that lense.

[TK.421]

@metalurgicaprogreso thank you for enlightening me with your response. for 20 years i've worked at a small shop with 20 total employees so i'm sure our network technology is not at the same level as yours. i do understand, and don't disagree that working locally at this day in age should be a thing of the past, especially when you have a flawless network. perhaps that is something my company can strive toward in the future, as it is a pain to go to/from network with projects. 

[metalurgicaprogreso]

Dear @TK.421 

Our company is a small shop as well. All I was trying to highlight is that there is no fault in our networking. My apologies if it came out the wrong way. The issue here is that software behaves differently under circumstances in which it should not behave differently. Think about how much easier it would be if you could work without issues on your network files. That is the point I am trying to make.

I could not start using Pmill 2024 up until last week (it was released on May 10th 2023) because it would not even create a simple drilling strategy without overshooting the hole depth, and we have been struggling with this networking issue for some time now. All these issues make me say that Autodesk needs to get this software back on track.

[TK.421]

@metalurgicaprogreso Not at all, I didn’t take it that way. It’s always good to try to understand, with more depth, someone’s point of view. 

as for Autodesk improving the software, I would not hold my breath. I have a feeling fusion will be taking over in the not-so-distant future. 

[Nateamus]

Network or local, the bug exists for both.

I think the reason it hasn't been uncovered is because it's very rare for someone to run a calc, then run the same calc again without tweaks. We have found that if you make even one change, to tolerance, say, it seems to wipe the cache and improve the speed for the next calculation.

For the broader discussion of network vs local, our engineers are global so we'll always be networked. Are the folks that are networked experiencing the issues just when opening or saving a network file? Once opened, all the work should be being done on the local computer you're on, not over the network. Can someone verify this?