2d adaptive

[ktrneill]

my 2d adaptive tool pathing is taking an incredible length of time to process a simple tool path cuts, fix it cause im about to burn this cuts hole down. CPU load is 100% when its processing the tool path. All other tool pathing and processes are fine.

Edited by
Discussion_Admin

[HughesTooling]

I'll ask for this to be moved to the CAM forum where you might get some help. Will help if you add more details.

[LibertyMachine]

Could you export and share your file?

File > Export > Save to local folder. Return to thread and attach the .f3d file

[ktrneill]

Heres the file, seems to work OK on a different PC, and different account. Both PC's are identical spec.

[ktrneill]

Couple screen shots 

[LibertyMachine]

That file has many 2D adaptive toolpaths. Which one were you (your computer) struggling to compute?

[ktrneill]

All 2D Adaptive was slow but more so with stock contour on to contain tool pathing.

[ktrneill]

Currently working on this other file and having the same problems, even on a different PC and account @Dillon-Grant too. Look at Side Plate 2 OP2B setup

[LibertyMachine]

Yeah, there's something going on here.

@jeff.pek is there someone that could take a look at this? It's locking up on me at 80%. Full CPU usage...

(EDIT) It took 598 seconds to calculate that feature out, with stock turned off

[jeff.pek]

Thanks for the report. Will get it investigated.

  Jeff

[ktrneill]

Thanks Boss

[HughesTooling]

Edit. Sorry misread the setup from your post.

[HughesTooling]

Just tested the correct op and shows 80% and CPU at 100%, edited and turned off stay down and it generates in a few seconds. What I could see for the 80% staydown setting the tool path doesn't look that different.

@jeff.pekI would like to mention a bug if you edit an adaptive op while it's generating. Try generating the problem op, wait 20 seconds or so then edit the op and set staydown to least. The op will generate in a few seconds but the CPU will stay at 100%, it looks like the first calculation isn't stopped by the edit. This seems to only be a problem with an op that takes a long time to generate, editing an op that completes in 10s or so doesn't have a problem.

 Edit, want to add that when this happens you have to close Fusion to kill what ever is going on.

Mark

[xander.luciano]

@HughesTooling Looks like you're on the right path there.

If you pull up the task manager, you can actually see the previous operation still trying to generate even after the edited toolpath has finished generating. Deleting the toolpath doesn't stop the process either, but you can at least manually abort the process(es) from there without having to close Fusion.

[HughesTooling]

Thanks @xander.luciano never thought about using the taskmanager. I hadn't really found a use for it before.

Mark

[martin.dunschen]

Hi All

As @HughesTooling already confirmed, there seems to be an issue with the stay-down linking in the example. I will create a ticket for the issue and report back here. With the staydown level set to 80% the method will try to find a staydown link and compares this with the length of a retract move. The higher the staydown level the higher is the absolute acceptable length of the staydown-move in comparison to the retract move. If this is not the case, or the staydown link cannot be found, we use the retract move.

Looks like it should have been able to find staydown moves here, but if it does not find these (or if they would be too long) it falls back to retract moves, hence the toolpath can look the same or similar to the one with selecting 'least' in the staydown level.

Thanks for reporting this problem.

Martin

[fonsecr]

Ticket CAM-9088.