Fusion design philosophy eschews global parameters? rationale please?

[Anonymous]

Many times, as my design become more complex and I find myself very much wanting to separate my subassemblies into separate designs (files) in my project to allow for distributed design work, information hiding, enforcing subassembly design integrity, and to control subassembly interdependence, I find myself wondering why Fusion has never supported globally linked parameters, i.e. user parameters that can be defined for an entire project that will be available both within open designs as well as in linked designs in the same or even different projects.

Global parameters, or global variables and constants in computer-speak, are a foundation of all kinds of data structures and algorithms (understanding that Fusion is actually just a high-level interpretive visualizing computer coding environment), for example, the value of a part standard, or the length of a box all the parts your sub-assemblies must hole-align into. I think most other advanced CAD softwares support globals, they are a staple of many design workflows, are essential I would suggest for large complex projects, yet they don't seem to be a priority for the Fusion architecture team. Which makes me hope they have a good reason, plus a solid work-flow alternative to using globals, in mind. 

So I respectfully ask that a Fusion architect please explain in some detail why a workflow paradigm absent global parameters been adopted for Fusion, and what is instead the intendedly better workflow they envision for complex projects in Fusion?

Or is this capability just hard to program into Fusion and so it's late being released? (possible! understandable!)

I am at a crossroads with my project now. I very much want to separate it out to linked sub-assemblies, but if I do I run the risk of duplicating a number or parameters, which will have the same values and intent across several designs, but cannot have the same names in each linked design ("global_parameter_A" must be named something else in another linked design in Fusion such as "global_parameter_A_1" even if both parameters are to always share the same value.)

Thank you!

[TrippyLighting]

This is a current limitation of Fusion 360.

In Fusion 360 all paramenters are global as long as you stay within one design file.

When I started working with Fusion 360 about 2 years ago, linked componens and assemblies (called XREFS in other AD software) did not exist and were added later based on many user requests and as such it has not yet developed functionality that is available in other CAD software packages (which, on the other hand lack some functionality that Fusion 360 has).

It's simply an area where Fusion still has to grow.

Other CAD systems often employ the principle of Configurations, e.g. Solid Works, Solid Edge, geomagic Design. You don't have irect access to user parameters in the external design, but you can create a Configuration of that design and access that configuration from the main assembly (I hope this makes sense). I have posted a similar idea in the Idea Station.

Some of that will be addressed when Configuration management will be added as functionality in Fusion 360 which has been communicated as further out.

Another thhing is that currntly whe exporting a subassembly out tothe data panel, you have the exported stand-alone version in the data panel dna the version currentyl in your desing. You do not have the option to export a subassembly or component to the data panel and convert the current version in your desing into a link to the external version. I have an idea for this in the Idea Station as well.

[Anonymous]

@trippylighting Yes, thanks! I'd read your posts on this before, and they helped me to contextualize this issue, and I'd upvoted your Ideastations as well to help prod things along, and even added my own ideastation when my search initially failed to uncover yours (spelling!) however I cant help feeling that somewhere in the Autodesk "agile" software development process for the fusion360 product and platform, a theory was presented by a senior architect as to why users wouldn't need globals or configurations, at least in the early days of Fusion360 (as we are in, I presume). So, I'd also like to hear this learned perspective directly, if there is one and it can be made public, and then perhaps understand if their argument will help me have what I'm ultimately after; configurable, relatable model data with integrity, and intellectual property security, at the granularity of subassemblies. What I wonder is, do they think, (and I recall you have spoken to this) that it works out to be more efficient for fusion users after all, from a cost benefit point of view, costed for small firms, to take the apparent limitations and risks of data dependence and agglomeration by keeping everything in one project, versus the more "traditional" or "accepted" architectural intent that users with complex projects should primarily link subassemblies via globals/configurations or some similar concept? (which Fusion360 currently can't do.)

[Anonymous]

hence, why RULE 1 is so important.

[jeff_strater]

As one of the Fusion Architects, I’ll do my best to help answer some of your questions and provide my perspective.

I was deeply involved in this.  We did discuss global parameters when we were building "distributed designs" (the ability to link external components, AKA "XRef").  In fact, I think I was even the one that brought up the topic.  We certainly realized that these could be important to some workflows, so it was never a case of us thinking that this was not a valuable or important capability.  But, in those same discussions, we also considered some other XRef capabilities:

• "Deep update" (the need to update from the bottom up, when a low-level design is out of date).  We recently fixed this one.
• The limitation of linked components to the same project as the design being inserted into (which leads to the need to save before the first insert)
• No "in-context edit" (the ability to edit a linked component in the context of the top-level assembly)
• No ability to do "assembly features" - drill holes in an instance-specific way in linked components (without affecting the linked design)
• Preventing the user from deleting referenced designs, so that we don't have to deal with missing referenced designs

All 6 of these are important capabilities.  Different people would probably each categorize their favorite of these as critical, required, basic functionality.   However, if we had decided to implement all of these right from the start, we would still be working on completing them.  So, we had some prioritization decisions to make.  Should we hold off delivering external references until we have all these implemented?  How do we trade off against other priorities (the above list only includes stuff we didn't do - there was a much longer list of things we did end up implementing, just in the external references project).  So, we decided that there was enough value even without these items that it was worth releasing it that way.  You could argue that it was the wrong decision with respect to global variables.  Others would argue (and have) that it was the wrong decision for any of the other items in the list.  It comes down to personal preferences, backgrounds and priorities.  But, I know that people have been using linked components successfully without these, so in retrospect I still believe it was the right decision.  All of these items are prioritized appropriately on our to-do list, and over time we will implement them.

We would like nothing better than to have all of these implemented today, trust me.  But, we have limited resources, unfortunately.  So, we will continue to have to trade off some of these items against each other, and against other priorities in other areas of Fusion.  

Jeff

[Anonymous]

Thanks Jeff! And actually, that's pretty much the answer I was expecting. It's a totally acceptable answer, and as an experienced engineering and R&D manager I can relate to the difficulty of ranking business trade-offs given our fate as humans to suffer with low information about the actual future, we can only assign probabilities, and those have to always remain suspect. We continually have to place bets in product development. 

Anyway... I had already taken the decision this morning, after reading @TrippyLighting's response, to plan for the reality you've now explained from Autodesk's perspective (no globals...yet...and we can't say when) and to combine my now externally referenced files back together and break links.

But the exercise wasn't in vain. Due to cruft build-up as I learned fusion (self-teaching) while developing my product I wanted to deep-refactor my subassemblies anyway, because I wanted to reduce the timeline item count (to improve human readability of my design steps, and to reduce computational demands as Fusion does its job of constantly recalculating my geometry), and ensure there were no hidden dependencies. In the process I did find unexpected hidden dependencies that were not visible as yellow or red flagged timeline errors, which did not appear in error messages after a "compute all", but only if I altered certain joints, and I found many better ways to populate and structure my timeline, browser, and sketches, and to reduce the parameter count, so that my model is now re-cast in a minimal compute cycle, highly readable, organized state.

I think another lesson here for me is that I will probably want to keep on doing refactors from time to time as I update and change my models and create new subassemblies, tho' hopefully less and less often as I get better and better at working with fusion and its paradigms, strengths, and limitations.

Nigel

[O.Tan]

---

@Anonymous wrote:

But the exercise wasn't in vain. Due to cruft build-up as I learned fusion (self-teaching) while developing my product I wanted to deep-refactor my subassemblies anyway, because I wanted to reduce the timeline item count (to improve human readability of my design steps, and to reduce computational demands as Fusion does its job of constantly recalculating my geometry), and ensure there were no hidden dependencies. In the process I did find unexpected hidden dependencies that were not visible as yellow or red flagged timeline errors, which did not appear in error messages after a "compute all", but only if I altered certain joints, and I found many better ways to populate and structure my timeline, browser, and sketches, and to reduce the parameter count, so that my model is now re-cast in a minimal compute cycle, highly readable, organized state.

---

This was one of the things that I still and do hate about Fusion, I really liked the idea of 1 design file to represent part and assembly but then, it introduces issues like what's mentioned in this tread already and I wonder when will we be able to edit in context as it has been a work in progress for awhile now, and like I said before, when AD do introduce this feature, they need to create a "tool" that'll allow users to convert/break their existing file to sub-assemblies as they see fit.

This is also one of the reason why I totally abandoned the use of history-based modelling and used fully direct based as I don't have to care about how messy my "timeline" gets (and the nature of my job requires me to do unplanned edits which easily messes up a history-based model), sure I lose out on the ability to fall-back on features and some features ended up as dumb features after some edit, I managed to live with that. I always said this and start to sound like an old tape recorder but it'll be good for AD to look at how SolidEdge managed to combine both History and Direct based modelling technique in a single environment, it's AMAZING and very practical!