The dead-zone between Nesting and Milling

[Max_Marz]

Regarding workflow for parts that require nesting and more than just 2D "cutting" toolpaths available in the fabrication tab;

I have an assembly of plywood parts that have various three dimensional features. Some are simple 2d cutouts, some of them have beveled edges, pockets, holes etc.

Traditionally it seems you would nest all the parts from your assembly into a sheet and then go to town building the toolpaths for the entire sheet. This process is great when you have nothing but 2d profiles to cut and you're leveraging the 2d "cut" toolpaths on a plasma or laser but what if I have a sheet router and I need to cut discrete features into some of the parts?

In my case I am stuck re-building toolpaths from templates or scratch whenever my nest changes, re-selecting lots of geometry. Sometimes a 3d toolpath which works great for one part breaks down when I add multiple quantities of the same part on the same nest, need to change spacing, orientation etc. Suddenly toolpath containment and stock selections become irrelevant. When anything about the nest changes every toolpath breaks.

I tried saving every individual component to its own project file, doing the discrete cam for each part in its own file and then nesting THOSE files by bringing them into a blank project with the "component sources" window preceding nest but no toolpath information follows the components through nesting, why?

[Max_Marz]

I will try this tomorrow and update:
CAMCollect | Fusion 360 | Autodesk App Store

.

[Max_Marz]

Update,
Currently cannot get CamCollect to work, I suspect a post processing error. In researching this plugin I wound up at their site which has a very good writeup about how I would hope/expect fusion nesting to work.

How we simplified low volume manufacturing in our CNC shop - 1D Work

Shocking to have (as a fusion360 user) access to a $1600/yr nesting plugin yet there's no meaningful way to leverage its power. I imagine fusion has backed themselves into a corner a little bit with the relationships of cam and setup data to their associated components but dudes! This extension costs more than fusion itself!

Nesting was purchased from another company by fusion and then implemented right?
The company it was purchased from had a large say in the cost of the extension, right?

I don't want to get into politics too much, but I think yall have some work to do before you can ask world class money for what is essentially an afterthought. It doesn't fit the structure of fusion. You want us to reprogram the cam for our entire sheet every time we run a nesting study. How can you justify 1600/yr and put a massive gaping hole in our workflow at the same time?!

Head hurts from bashing my head into this problem all week and I want my cloud credits back 😞
Edit; I'm not tryin to complain, I appreciate autodesk a whole lot I just feel misled more than anything.

[hyperbolicindustries]

"The company it was purchased from had a large say in the cost of the extension, right?"
-Very doubtful. All they wanted to do was sell their software to Autodesk.

"...ask world class money"
-Even with extensions Fusion is far cheaper than other softwares. Whatever complaints I have about Fusion are tempered just because of it's low price. Something like Espirit or Solidworks addons or Mastercam cost 2 to 3 times what Fusion (with extensions) just in maintenance let alone for the software itself. If you want to talk world class money, something like Siemens NX cost ~35k a year or something close to that.

[Max_Marz]

The point I'm trying to make has nothing to do with the overall cost, I shouldn't have used the verbage "world class money" I figuired the reader would be willing to afford me that one for the purpose of this discussion. It's really more that the valuation within the scope of fusions family of extensions seems inconsistent and it leaves me confused as to what their intentions are. I just want an explanation like,

"yeah we know this workflow doesnt make sense, we're working on it"
or,
"we have plans to do it this way in the future"
or,
"we figured people would do it this way instead"

Its interesting to me that even when you do a cam setup on a discrete component and then import that single component into a manufacturing model the cam that you did in the discrete project file is not included with the import.

This has nothing to do with nesting and its cost, its fundamental to fusion and breaks down the foundational concept of components as containers. The only reason I bring cost into the discussion is that it kinda implies the functionality is there but isn't, I guess that's debatable, but we probably shouldn't, I don't want to fight.

PS: do any of the software packages you mentioned work in the way I'm describing where you can nest setups?

PPS RE: ("The company it was purchased from had a large say in the cost of the extension, right?"
-Very doubtful. All they wanted to do was sell their software to Autodesk.)

To clarify my position, Fusion paid a certain amount of money for this code/software so they could integrate it with their own, I'm sure it was a lot of money and I'm sure the cost we pay for the extension is commensurate. This is no problem! I want to buy that code too! What kills me is that we are paying market price for an extension that likely isn't integrated as well as the original software, in fusions case it's tacked on to the last step which undermines the foundational concepts of fusion. They are shooting themselves in the foot and we pay for it.

I hope this helps the reader understand that my position isnt meant to be a flaming complaint, its just confusing. Why did they pay so much for awesome nesting code and then completely undermine its power with the integration? It feels like I'm missing something that could be as obvious as "just use derive dummy!"