Rule #1 / Restructuring of components

[JRTG]

Hi,

I've been using Fusion 360 for some conceptual design work, in order to learn it and see if it's fit for my needs (machine design).

I know Rule #1 and I try to adhere to it.
However, for each design so far, after a while I realized that I should have grouped components differently and/or need to add an extra subassembly level.

This post also mentions exactly what I want to do: "In either case, periodic refactoring, [...] is to me an essential if not always fun task."

However, I don't really succeed in restructuring the components in a clean way.
Even if I roll back the time line and add the new component before any features of the components that I want to relocate, I often can't move the existing components into the new component.
You can of course restructure with CutPaste features, but that only generates extra clutter in the time line.

This is also written in above mentioned post, but no solution is given: "Notice that some entities in the timeline sometimes cannot be moved to where you might prefer them. Notice further that some entities in the browser can sometimes be moved up or down or across the hierarchy, and sometimes can't be." 

Furthermore, there doesn't seem to be any functionality to check which references a certain component or feature has, wrt other components or wrt the assembly level, and to break or reroute these references in order to change dependencies.
(which would have been my plan B: if you can't restructure due to references: break the references, restructure and -if needed- recreate the references).

Given that so far I've only been doing very limited work with a small number of components, I am wary that for larger assemblies the time line will quickly become a big mess.

So I'm looking for more experienced users' advice on how to cope with this.

Thanks for your advice,

Johan

[mohammed.aliTDPXK]

Hello @JRTG ,

Here's a forum post I found for you.

https://forums.autodesk.com/t5/fusion-360-design-validate/fusion-360-r-u-l-e-1-and-2/td-p/6581749

Let me know if this helps
Thanks!
Do like the post and accept as solution if this answers your query.

[TrippyLighting]

@mohammed.aliTDPXK I appreciate you mentioning the sticky post I made a long time ago, but @JRTG already mentioned that he knew these "rules". 

As the inventor of these "rules" I'd have to say that they can help to avoid some pitfalls, but not completely prevent the struggle to restructure an assembly. 

One of Fusion 360's strong suits is Top Down design where components are designed in-place and a single Fusion 360 file can contain an entire assembly created that way. That also means that the timeline is enabled for that single assembly file.

In cases where components can easily be dragged and dropped from one structure tree either into into another tree branch or up and down the hierarchy, a cut/paste(?) feature is inserted for that operation in the timeline. That is undesirable as when you roll the timeline back, the structure that you have created and which you though into not undoes itself as you roll back the timeline for edits. That is very irritating and the more complex a design is, the more irritating that becomes. It also clutters up the timeline.

It is also not uncommon to get the dreaded warning " The timeline cannot be rolled back to before the active component".

It would be incredibly helpful if, by the choice of the user, the creation of the cut/paste feature in the timeline could be disabled. 

The other issue that I see is that due to Fusion 360's flexibility it is incredibly easy to create references that then prevent the restructuring or moving of a component in the structure tree altogether. Unfortunately a tool set to visualize and untangle these references and rearrange them so components can be move is all but non-existent.

I've requested both of these a number of times over the years and fully understand that these are non-trivial requests and difficult to implement. I've not received feedback that would indicate that any first steps have been taken into that direction. 

[mohammed.aliTDPXK]

Hello @TrippyLighting  and @JRTG ,

I was more interested in your Rule 1 exception 🙂 .

Apart from that I would also encourage to create components as external components(Xref) when in doubt. This way we have a separate component and also we can utilise the edit in place workflow if required.

[TrippyLighting]

Yep, that can be one. 

However, if you do work exclusively with linked components, in that case at least for machine design, Fusion 360 looses a good bit of it's competitive advantage.

I should mention that for more than 20 years (of 30) of my career as an Engineer I've spend developing manufacturing automation solutions. Machine design is a topic I have intimate and knowledge of. 

[johan.rutgeerts]

Dear all,

I wanted to give an update on this.

It has become a rather long post, but I hope this might be of use to others:

It really bugged me that I wasn't able to retain a clean structure, to the point that I had decided that Fusion 360 was ok as my short-term solution, but that it would inevitably have to be replaced by some other CAD system later on. Which I really regretted as cost-functionality wise it offers so much.

But then I found this blog post about reference objects. To me, this functionality is a real game changer.

It allows me to work very similar to how I used to work in Creo Parametric (with its hugely expensive AAX extension):

• I create a top design assy (TDA),
• I only use external components,  (*)
• The first component in the TDA is the 'skeleton model' (**): it holds the basic sketches and references (e.g. kinematic chain of the machine, origin references for subcomponent placement, some geometry sketches that are common to multiple components, etc),
• The skeleton model is positioned on the origin of the TDA with a rigid joint,
• Then, for each functional group (e.g. 'frame', 'drive system', 'heating system', etc), a new external component is inserted ('Functional Group Component' - FGC).
• Each FGC is also positioned with joints wrt to the top desing assy or wrt the references of the skeleton component (***).
• Each of the FGC's is then edited-in-place to add the reference objects (as described in the blog post),
• Further components are added to each FGC as needed, to model subassy's and parts,
• Further design is (preferrably) not done by edit-in-place (as this can lead to unintentional creation of extra design contexts) but by opening the external components,
• The TDA is kept up to date by saving each component after edit, updating the out of date TDA and syncing all assy contexts.

(*) Probably a combination of external and internal components could be beneficial, but I want to streamline my workflow first before I focus on that.

(**) I reuse the name 'skeleton' as this is what it is called in Creo.

(***) It seems that you can't directly reference the skeleton geometry when creating the joints. I didn't further investigate this, as I currently didn't need this (my FGC's are fixed to the TDA origin). Maybe it would be better to define the skeleton component as an internal component of the TDA instead of external...

The benefits to me are:

• Designs can only reference those reference objects that were explicitly added to the assembly contexts, so you can't create a 'reference mess' (or at least it's more difficult ;-),
• Clear isolation of design-wide references and parameters in the skeleton component (4*),
• You cannot forget to apply 'Rule nr. 1' (since you are working with external components),
• It is possible to restructure components / add extra subassy levels / etc (5*),
• Allows for distributed design with multiple designers on one project,

Main drawbacks:

• It's a bit of extra work (but imo the benefits greatly outweigh this),
• I really whish they'd implement functionality so that all open components auto-update, as now you have to:
  • Save the FGC after edit,
  • Update the TDA,
  • Save the TDA (which typically also saves some of the FGC's),
  • Update the FGC,
  • Continue editing the FGC
• So that's quite a hassle, but it hasn't been a showstopper to me so far.
  
  

(4*) Of course, each FGC (or in fact every subcomponent) can also have its own skeleton model, with extra design info and references relevant only to that context,

(5*) I didn't need this yet so I don't know if/what possible limitations are wrt restructuring.

I hope it's clear; I currently don't have an example assembly that I can share, but I'll gladly hear any remarks or comments, or if there's questions let me know.

Regards,

Johan

[TrippyLighting]

---

@johan.rutgeerts wrote:

It has become a rather long post,

---

Indeed is is a long post but is it a very good one. Thank you!

[whittakerdw1216]

You'll find the more you work with Fusion and other design software that there is no "Rule #1". This "Rule" is simply non-existent and a waste of time.

[TrippyLighting]

---

@whittakerdw1216 wrote:

You'll find the more you work with Fusion and other design software that there is no "Rule #1". This "Rule" is simply non-existent and a waste of time.

---

After working for 25 years with other 3D modeling and CAD tools professionally, I "invented" that rule and it has helped many users move through their first difficulties in Fusion 360. I was aimed at Fusion 360 beginners.

It was also conceived before the ability for external (linked) components existed, before the derive functionality was released and before in-place editing was  born.

In a design where all components are designed in the same file Fusion 360 R.U.L.E #1 can indeed be very helpful.

I currently work with Fusion 360, ZW3D and SolidWorks (I've worked with SolidWorks since 1998).

[johan.rutgeerts]

@TrippyLighting 

Sorry, my mistake, I did write:  "[...] but I'll gladly hear any remarks or comments" 

😉

@whittakerdw1216 

What I implicitly meant was: "[...] but I'll gladly hear any remarks or comments on why and how to do things differently"

Everyone is entitled to their opinion, but without discussing the 'why you do it differently' and –more important– the 'how you do it differently', I don't see the added value of sharing that opinion.

Regards,

Johan

[GRSnyder]

---

@whittakerdw1216 wrote: You'll find the more you work with Fusion and other design software that there is no "Rule #1". This "Rule" is simply non-existent and a waste of time.

---

I don't think of Rule #1 as an aspiration or design rule so much as a work-around for the issues described in the original post. If you don't get used to using Rule #1 in all new documents, there's no way to go back and fix things without lots of pain and mess. None of the later developments has changed this underlying reality.

[jeff_strater]

This is an excellent post, @johan.rutgeerts.  I would nominate it for Rule #3 status.  It very succinctly (even if you think it is a long post) describes a very useful and valid skeletal (yes, we use that term, too) workflow that makes the best use of create/edit in context and external components.  We are happy to see customers like yourself who see the potential in some of the long and expensive (to implement) enhancements we've added to Fusion (edit/create in place, for instance).  Assembly contexts do, as you point out, help make cross-component references much more deliberate and intentional, which is a very good principle to adhere to.  There are still a few hiccups with assembly context (the update model is not as clean as it could be), but those will improve over time.

In defense of Rule #1, it was, as @TrippyLighting said, written before edit in place existed (and maybe even before external components themselves existed, I'd have to go back and check on that...).  Rule #1 is still valid for those who choose to use internal components.  Personally, I think internal components are one of the most useful and under-valued features of Fusion.  It's easy to forget that, in Solidworks or Inventor, you have to create a new file for every single component in your design.  And...  You have to know up-front whether this will be a Part or an Assembly.  I like the fact that Fusion does not have this distinction.  That said, I agree with @GRSnyder that component structure in Fusion is not as flexible as I would like (I might not have put it quite so harshly, but I'm biased).  We do have plans to try to fix some of these limitations, but I have also been around long enough that I won't make any promises yet.

Thanks for posting!

[johan.rutgeerts]

@jeff_strater @TrippyLighting thanks for the kudos!

However, be aware that multiple aspects (and possible limitations) still need to be explored, e.g.:

• I didn't try to restructure an assembly yet. Will this work, or will this break the assembly contexts?
• The current update procedure is a bit annoying, but workable, for me. Does this still hold for a design team with multiple concurrent design engineers?  
• So far, I only used rigid joints to assemble the Functional Group Components in the Top Design Assy. What if you  need other types of joints? If the kinematic chain is not in its initial pose when you sync the design contexts, the references in each Functional Group Component will change to reflect the new relative pose between FGC and TDA?
• Etc.

Regards,

Johan

[TrippyLighting]

---

@johan.rutgeerts wrote:

...

However, be aware that multiple aspects (and possible limitations) still need to be explored, e.g.:

---

Yep, I am fully aware of that 😉

Thank you for sharing your experience!

Not many people seem to evaluate Fusion 360 abilities that thoroughly. Apparently it is so much easier today to "jump right in" make an inflammatory comment on this forum or  on a facebook group when things don't work out. You, on the other hand chose to make a well though out and very informative post. Thank you again!