How to delete detached stock while simulating

[sapitch]

Hello !

As shown in the two pics attached, my first toolpath cuts material left from previous setup with a end mill.
Then, with a facemill, i do a 3d adaptative to rough the part.
But the facemill collides with that extra material thats "floating in the air".

So, is there a way to delete/remove/ignore detached stock while simulating ?

Thanks

[seth.madore · Accepted solution]

Unfortunately, that is not possible at this time. It's something that's been raised more than once, so the devs are somewhat aware of this need.

[engineguy]

@sapitch 

As Seth @seth.madore  rightly says not possible the way you wanted to do it, however a small workaround will I think do what you need.

I used 2D adaptive to do the final operation in the attached example and it appears to be fine, to get it to clear all the middle block I put in a -7mm "Stock to leave" which creates an overlap so the corners that would normally be left are cleared.

As you didn`t upload a file I have created what I think is close to your image, here is what it looks like in the Simulation, it may or may not be of any use to you but it is an option to "get `er done" 🙂 🙂 🙂

This only one of a number of ways you could do it including using Stock from the first Setup for the Second one etc, etc, really whatever you are comfortable with, hopefully you will get other options posted for you, I just think this is a pretty easy/simple method to get what you need 🙂 🙂

File attached, run through the Simulation and then go through the settings used and fine tune them as required for your machine etc, etc 🙂 🙂

Regards

Rob

[sapitch]

Ok, thanks for the fast reply, i'll try some workarounds

[sapitch]

Thanks Rob, i've downloaded your file and tried it.
(Cannot upload mine since i'm not the owner of the file)
You made me discover the stock mode "From preceding setup" in the "Preview features", it was not activated in my settings !! 🙂
https://knowledge.autodesk.com/support/fusion-360/troubleshooting/caas/sfdcarticles/sfdcarticles/How...

The way you did it was not exactly what i was looking for, because there is more toolpaths coming after and smashing all the time in the "floating" stock.
Normally i would cut all that material to chips (from the outside in) with a 2d adaptative, but i think it is too thin for that overhang and can cause vibration and/or tool damage.
Thats why i cut it full slot with a 2d contour.

What i did for now is a "dummy toolpath" that cuts the "floating" stock right after i detached it, and i'll just try to remember to delete it before i post my gcode.
If i forget it, i'll just cut air.
The thing i don't want to do is turn off collision detection for all my setup, since it is potentially more dangerous.

I've also looked if there was a way to have some toolpaths that are active in the current setup but with a "switch" that says something like: "do not include in Gcode when postprocessing".
Have'nt found anything like that other than "Suppress", i'll try it to see if the suppressed toolpath is outputed in the Gcode.

Thanks again

[DarthBane55]

---

@sapitch wrote:

I've also looked if there was a way to have some toolpaths that are active in the current setup but with a "switch" that says something like: "do not include in Gcode when postprocessing".
Have'nt found anything like that other than "Suppress", i'll try it to see if the suppressed toolpath is outputed in the Gcode.

---

I never thought of that, but this would be great!  (suppressed toolpaths will not be output in the gcode, but they also will not be present in the simulation either, which in your case would be pointless).  Being able to create some dummy toolpaths (do not output gcode but remain in simulation) to shape the stock without having to model it could come in handy sometimes, great idea!

In the same sort of idea, it would be nice to have some tools that do not cut in simulation, but that do get output in gcodes...  I know it sounds weird, but we use brushes on some parts to get a particular finish, and the only way at the moment seems to be to define brushes as endmills, which cut the part of course, and screw the rest of the simulation up.  So usually for simulation, I suppress the brush, and to code, I unsuppress.  Would be great to have a tool type that we could say "non cutting" or something along that line.

Anyway, I think I overstepped your post here, but your idea reminded me of this issue with brushes.

Really like your idea though, would like that implemented for sure!

[sapitch]

@sapitch wrote:

I've also looked if there was a way to have some toolpaths that are active in the current setup but with a "switch" that says something like: "do not include in Gcode when postprocessing".
Have'nt found anything like that other than "Suppress", i'll try it to see if the suppressed toolpath is outputed in the Gcode.

@DarthBane55  wrote:
I never thought of that, but this would be great!  (suppressed toolpaths will not be output in the gcode, but they also will not be present in the simulation either, which in your case would be pointless).  Being able to create some dummy toolpaths (do not output gcode but remain in simulation) to shape the stock without having to model it could come in handy sometimes, great idea!
...
--------------------------------------------------------



Well, i've found a way to do exactly that (among other useful things), and it's called "Create NC Program" under the "Setup" tab.
It allows you to pick which toolpaths you don't want in your NC Program, you simply have to unselect it in the "Operations" tab.
It is a good temporary workaround to the "delete detached stock while simulating" problem.

[DarthBane55]

That is awesome!  Now find a way for the brushes problem please... hahaha

[sapitch]

@DarthBane55 

I've you tried playing with "Form mills" ?
Maybe you would be able to get what you want by setting a negative tip offset.
Let me know if that works for you, and i'll put that knowledge in my "tips&tricks bank" 😁



***Edit

Oh, just thought of an other possibility:
The good ol' "Create NC Program" function !

Simply create a setup without the brush toolpath, so you can simulate all the way through.
And then another setup with only the brush in it, the one that you don't want to simulate.
"NC Program" will join them in a single GCode file.

[DarthBane55]

@sapitch 

I like the form mill idea!!  I will definitely give that one a shot.

But I cannot use your 2nd idea (another setup), because I do want to simulate it.  The brush has a body around the bristles, and I need to make sure that this body does not hit anything. 

But the form mill, that seems legit, I would just raise it a bit so that the bristles don't touch, and make that body lower by the same amount (ensuring the body Z level is real), so it would cut air in simulation, but the gcode would be correct, and the body would be correct, and if it hits anything, I would see that.

Thanks a lot!  I am almost 100% positive that this will work!!!

[DarthBane55]

@sapitch 

Aaahhh, it was a good idea, but it does not behave as I would have expected.  See pictures, and even the Fusion file attached in case you want to have a look...  But basically, it simply offsets the toolpath by the amount entered for the tool tip offset (instead of offsetting the tool itself).  In my case, I need to go Z-0.08", but I have tool tip -0.100", so the toolpath is 0.02" above the part, and the gcode too, so the brush will not touch the part in real life.  If you think of a way that maybe I am missing let me know, otherwise I guess this doesn't work unfortunately.

I would have thought that the toolpath would be output to the tool tip defined in the tool, including the offset added to the tip, and that the tool would be above the toolpath by the amount set in the tool tip offset, but it's not like that.  It raises the toolpath, instead of raising the tool.  Then I don't know what is the use for this tool tip offset, I could raise the toolpath myself by saying to leave 0.02" finish allowance on Z...  I might create a separate thread to get some answers on this.

[sapitch]

@DarthBane55 

I played with your file, tried negative "Body length", negative "Shaft" length, nothing of that works.
The "Tip offset" box is kinda useless.

And then i found your 2018 thread about this particular issue !
https://forums.autodesk.com/t5/hsm-support-forum/form-tool-quot-tip-offset-quot-problem/td-p/8346317

Having "Tip offset" working properly would greatly increase the "Form mill" functionality.

There is at least one more option left:
Cheating the length offset of your brush on the machine.
You program Z+0.020 in Fusion, the tool actually goes to Z-0.080 on the machine.

[DarthBane55]

@sapitch 

Daaaang!  I totally did not remember that post.  Thanks for bringing it back up, I will reply to it and see if that case #CAM-11463 will be addressed at some point.

Ya, we could do what you said with cheating on the machine side, but it's one more exception for the brushes, one more thing to remember, not a big fan.  Right now, I do 1 full simulation, making sure the brush body doesn't hit anything, after that I suppress the brush, do another simulation like that, and then unsuppress it again to code the file.  That gets it done too, but I would really like them to fix it in Fusion properly!

Thanks again to bring that old post back!

[ltomuta]

---

@sapitch wrote:

I've also looked if there was a way to have some toolpaths that are active in the current setup but with a "switch" that says something like: "do not include in Gcode when postprocessing".
Have'nt found anything like that other than "Suppress", i'll try it to see if the suppressed toolpath is outputed in the Gcode.

---

For reals, why don't we have this already if nothing better is possible?! Can't be more than 5 minutes work for the dev team. 

[seth.madore]

There is literally no such thing as "just 5 minutes of dev time needed" for almost anything in software..

[DarthBane55]

It's the same reasoning a boss would ask a CNC programmer why is it taking so long to program a part, should be 5 minutes no?  lol

[ltomuta]

Obviously I did not mean that literally but just for fun take the source code  and do a search for if(operation.isSuppressed()) and replace it with if(operation.isSuppressed() || operation.isSimulationOnly()) and see how few little lines of code remain to be touched to have that special operation ignored/processed at the right times. :))

( Oh, and in the process you could also have a look at what happens when an operation is both protected and suppressed. 🙂 )

This is an annoying problem and it is about time to have it fixed one way or another.


BTW, no need for UI changes, just handle the Protected + Suppressed case as SimulationOnly. The current implementation of the combo doesn't makes sense anyhow.