Fusion cutting corners of stock not displayed in simulation, using excessive retracts when I try to do something about it.

[davidturnswood]

Greetings, 

Can someone tell me why Fusion won't show my cutting tool (1/4" straight mill) slashing through corners of my stock when it doesn't retract?  This would be a really useful thing to show in a simulation, and save me a lot of energy fooling around.   It took two diagonal paths through the corners, and perhaps would have taken some more.  I would upload my setup, but I have already changed settings again and so won't be able to reproduce it accurately.  

When I do raise my retracts I get very frequent retracts that waste a lot of time and put more miles on my robot.  Is there some reason the software can't avoid running the tool inside the area I am trying not to mill?  

What is especialy annoying is when I set the retracts to stay down and set lift heights to zero, Fusion says:

Warning: Lifting retract height to safe height.

Warning: Lifting clearance height to retract height.

Why would the software tell me it is retracting to a safe height when it seems to do no such thing?   I ran that iteration and it didn't retract at all.  

Is it really that hard to ask the path not to hit the parts of the stock I don't want to mill?  Is solidworks any better about this?   It is just so fiddly.  How can I ask it to move out of the way when it needs to, but not when it does not need to?     

I would really appreciate a visual of the cutting tool removing material everywhere it goes, including retracts, or non-retract linking.   

For now I'm going to try minimum retraction, preserve rapid movement, allow rapid retract, safe distance 8mm, max stay-down 800 mm, lift height zero.  Does that seem reasonable?   I am cutting to several depths using a pocket clearing strategy.  It's just so frustrating that there are SO many setting to play with here, and I think we all have the same goal - reduce and smooth our paths whilst avoiding hitting the stuff we didn't ask to cut.   

Specs:  I am running this through the grbl post to create an NC file, then using RoboDK to translate that path to a set of coordinates my Staubli Rx90 robot can understand.  It works surprisingly well - I just need Fusion to do it's thing 😉

Thanks!

David Earle

[seth.madore]

I know you mention not sharing your file since you've changed some settings, but.....it's not clear what went wrong. Can you open an older revision of the file and share that?

[davidturnswood]

I took care of it. I just wish it would show the linking and retract moves in the simulation when they eat into the stock. There are too many settings to adjust to have folks guess and then screw up expensive materials, or many hours of time. It's never really clear to me how best to optimize the retracts so they will clear the stock, but not cause an excessive amount of extra time and machine wear.

I don't have an older version of this file as I am really not into using the cloud for saving stuff.

Best,

David

[Joshua.Aigen]

Hi @davidturnswood, I'm just wondering if you are using the Robo DK plug-in for Fusion 360 or a stand alone version? I'm not familiar with Robo DK but I wonder if the plug-in could help improve this workflow.

[davidturnswood]

No, I don't have the RoboDk plugin, but highly doubt that would change anything. The paths I'm having problems with are created in Fusion, but they are complex enough that it can be very difficult to tell what is going on. That's why I am requesting accurate simulation that include the tool cutting through the model when retracts are not high enough (or not happening).

Thanks,

David

[seth.madore]

---

@davidturnswood wrote:
That's why I am requesting accurate simulation that include the tool cutting through the model when retracts are not high enough (or not happening).

Thanks,

David

---

But that's the thing; in all examples I've seen, as well as in my own programming, it does simulate these. Which is why I was hoping you'd be able to share an older version of the file.

[davidturnswood]

Seth,

I'll try and save more versions as I am working as I am sure I will replicate the problem again.  

I have had so many nicks to the pattern on top and bottom sides - about 5 per side / ten total.  

The pattern is attached to a 1/2" plywood match plate.  The top side of the pattern itself is about 16" by 8", by 2" tall (with a negative relief on the underside).   I'm using a 1/4" bit, and hoping to rough out efficiently with 20-30% overlap (pocket or adaptive), followed by two parallel passes at 1mm overlap, finished with some pencil paths using the flat, then ball point bit.  

The pocket strategy seems easy to compute, but wastes a lot of time cutting air and seems like it makes these nicks to the work more often.  The adaptive strategy I've had better luck with, but seem to take eons to calculate, even when I slice the model in to thirds or quarters.  

What sort of clearing stragety and settings would you recommend I try with this sort of object?  (Seems to be a problem primarily with clearing).   I could ask the tool to retract every single time it repositions, but that takes forever.  The strange thing is some of these attempts it seems most of the retracts that need to happen occur, but then one or two just come out of nowhere and the tool cuts straight across the work piece.  

It's quite frustrating, and I've recently gone to editing the coordinates prior to loading them into my machine in an attempt to remove some of these mishaps.  I went back to look at some of these simulations and the nicks happening either don't happen any more because I altered the file, or they just don't show at all in the sim - either as material removed, or linking action.  They seem to come from nowhere. 

[isabella.flack]

I hope I can add some clarity here. The Fusion toolpath calculator has determined that it cannot use the inputted values for these heights and updated them. We added a warning so that a user would be aware that the output toolpath will use different heights, however I can see now that the message is confusing as the values the calculator is using are not in the UI. The new values that the calculator uses (and that you sadly cannot see) should be reflected in the post processing. 

I have created a ticket CAM-36050 to solve this.