Fusion 360 Manufacture Simulation Creating Gouges for no Reason

[alex5Q7M5]

I have a Fusion 360 file I am creating as a surfacing test for a small endmill. Earlier this week, I completed the CAM and everything in the simulation worked as expected - however, today upon opening I get an error I am not sure how to fix. Seemingly out of nowhere, the final finishing operations started gouging the top of the part, detecting a toolholder collision. The problem is, the toolholder is not touching the part at all. It's almost like Fusion thinks the toolholder is larger than it is, I have switched holders and remodeled the tool however and the problem still persists. 

The odd thing is, the longer I make the tool stickout, the larger the gouge becomes - the opposite of what should happen. As you can see in the pictures, the pink area shows the gouge. This is just as the toolpath starts, and you can see the toolholder is not touching the part at all.

[seth.madore · Accepted solution]

I am not seeing that in your file. I do see one gouge early on, which is a false alarm really, but that's it:

[alex5Q7M5]

This must just be an issue on my machine, opening the file I uploaded to this post still gives me the gouge. System and Fusion restarts have not fixed the issue either

[Anonymous]

Confirmed, only collision I see is in first roughing tool path, but if "Stay- Down Level" is changed to "Most", there is no collision in entire file. 

[HughesTooling]

@seth.madore  The collision shown above is caused by smoothing. From what I can tell the linking is done before smoothing, smoothing\arc fitting is moving the end point of the toolpath slightly so the retract is no longer vertical and it is going into the job.

I've brought this up several times but not sure support understood, perhaps you can explain it to them.

@alex5Q7M5  A note on smoothing, smoothing works best if you have a tight tolerance and a smoothing tolerance that's bigger. I usually go for 2 to 10x bigger depending on the tolerance. See attached file, I copied your adaptive and changed from 0.004 and 0.001 (Total tolerance 0.005) to 0.001 and 0.003 and the code size dropped from 126.5kb to 83kb. Collision goes away as well.

Mark

[Anonymous]

I fully agree with your analogy but keeping tool down totally eliminates the problem, that was my point, unless there is valid reason for retracting tool after each Z level, such as ..... ?? 

[seth.madore]

@HughesTooling  yeah, there is a long list of small bugs that I really need to document and submit. This is one of them... thanks for poking me 🙂

[seth.madore]

---

@Anonymous wrote:

I fully agree with your analogy but keeping tool down totally eliminates the problem, that was my point, unless there is valid reason for retracting tool after each Z level, such as ..... ?? 

---

Having Stay Down set to "Most" will drastically increase the cycle time of the part in many cases, at it spends more time feeding around at the high feedrate, rather than just rapid up, over and back down. On top of that, it also increases the program size. The folks on Fanuc and other standard controls tend not to like that. Haas, Okuma and Brother certainly don't have that issue...

[Anonymous]

OK, from mill guru to a lathe guy with potential ............, I was under impression that stroking up and down to start new pass in same place was bad idea, probably was if tool was starting new pass at same place every time, I missed that.

Now why all those options from "least" to "most" ?,  is it so that tool path can be optimized when possible or is it just clutter no one needs?

[seth.madore]

A lot of that setting depends on your machine, the part, and the material. If you command a small lift height and a conservative "Stay Down" percent (40% is my choice), it will clear the part on it's "stay down" move, but then for the larger moves, it will rapid up, over and down. 3D Adaptive does insert a small linear move that serves as a slow down, as that does use the lead-in feedrate and not full rapid

[seth.madore]

---

@HughesTooling wrote:

@seth.madore  The collision shown above is caused by smoothing. From what I can tell the linking is done before smoothing, smoothing\arc fitting is moving the end point of the toolpath slightly so the retract is no longer vertical and it is going into the job.

I've brought this up several times but not sure support understood, perhaps you can explain it to them.

Mark

---

I have logged this as CAM-14969. I will continue to add jobs to the bug list as they crop up. Thanks for your patience 🙂