Do you build top down or bottom up?

Do you build top down or bottom up?

Anonymous
Not applicable
4,249 Views
28 Replies
Message 1 of 29

Do you build top down or bottom up?

Anonymous
Not applicable

I spent all day building an assembly within one file (standard fusion method).  I changed one part and it affected 3 others creating a tangled mess of errors that is too difficult to untangle without starting over since the error that needs to be fixed occurred early in the design. 

I can't imagine how this can be avoided building everything in one file.  It seems that building the parts independently then assembling them later would avoid the intertangled cascading errors.  Am I missing something?

Any thoughts or suggestions?

0 Likes
4,250 Views
28 Replies
Replies (28)
Message 2 of 29

TrippyLighting
Consultant
Consultant

That is correct. Building each component in its own file will avoid that problem.

The reason is that it prevents you from making all sorts of references between components in the same assembly.

Using edges from one body in one component to project onto a sketch in another component creates an interdependence between these two and that is not always intended. That's jus one example of such references.

 

But with a little practice and discipline it can be avoided or used to ones advantage.

Something that helps is the BORN modeling technique.


EESignature

Message 3 of 29

Anonymous
Not applicable

I find these ongoing and endless discussions (conFusion 360) very interesting and exciting.

 

How about this?

1) If you create mechanical designs (= parts - aka Inventor IPT and assemblies - aka Inventor IAM)

2) And if you have a clear/unique parametric design intent (which you must define in advance)


then use the Fusion 360 all-in-one-file top down approach (eg. Kevin Schneider´s AU Master Class example)

 

3) Otherwise, use bottom up with linked components for mechanical designs

Message 4 of 29

Anonymous
Not applicable

Thanks for the feedback. I suppose it is like working with projected geometry in Inventor.  It was rarely worth the risk of the confusion it eventually caused. 

 

Do you guys recommend any comprehensive courses for F360?  I've spent at least 20 hours watching videos here and on YouTube but none of them explained the pros snd cons of top down vs bottom up.  I would like to invest in a course that has a solid philosophy to build on vs. a piecemeal approach. 

 

Thanks for the feedback and any further suggestions. 

Message 5 of 29

TrippyLighting
Consultant
Consultant

I am not aware of any comprehensive courses in Fusion 360, but have considered putting together a curriculum to support my private tutoring efforts. 

 

The reason this isn't easy to find own youtube videos is that the vast majority are created by hobbyists for hobbyists that often done have the needed experience in any industry to explain this in some context and this does need some context.

 

In general Fusion 360's strength is more of a top down design workflow where you design parts in place in their final location. Terms such as To-Down and Bottom-Up really mostly serve to explain some basic approaches, but most more complex designs are a mixture of both.


EESignature

Message 6 of 29

Anonymous
Not applicable

@Anonymous wrote:

...

..

Do you guys recommend any comprehensive courses for F360?  I've spent at least 20 hours watching videos here and on YouTube but none of them explained the pros snd cons of top down vs bottom up.  I would like to invest in a course that has a solid philosophy to build on vs. a piecemeal approach. 


@TrippyLighting wrote "..I am not aware of any comprehensive courses in Fusion 360, but have considered putting together a curriculum to support my private tutoring efforts..."

 

 

It's the same with me. As a service provider I have compiled modules for (few) paying customers.

 

My experience regarding Fusion is: too many hobbyists, not enough users willing to invest. "Piecemeal" is sufficient for most.

Message 7 of 29

chrisplyler
Mentor
Mentor

 

It helps a lot to go into your Preferences and turn off anything with the phrase "auto-project."

 

Then ONLY project specifically the items you need when you WANT a dependency established.

 

I'm easily able to create everything in a single file without having such problems. Just takes an understanding of how/why things happen in F360 the way they do.

 

 

Message 8 of 29

carlhitchon
Enthusiast
Enthusiast

With separate files, parameters are not shared. This is a strong incentive not to use that bottom up method in Fusion.

Message 9 of 29

jeff_strater
Community Manager
Community Manager

This is a great topic - one of my favorites.  I find the labels "top/down" and "bottom/up" to be a bit misleading in this discussion.  A maybe more important related question is "local components" vs "external components".  You can build in a "bottom/up" fashion using all local components (though it does take a bit of self-restraint to do so).  It's harder to try to build "top/down" using all external components, maybe not even possible.  So, the topics are certainly related.

 

In my admittedly biased view, the ability to have local components is one of Fusion's coolest features.  Most of us came from Inventor, and it was a pain (a UI pain, a data management paint) to create a bunch of parts on disk just to get a quick concept design in place.  So, I tend to like to work with local components when I can.  Certainly when exploring design options, this is very handy.  There is also the related benefit of "design in place".  Again, this is much harder to do in a traditional parts/assembly modeler.  It is very convenient to be able to build up a design with all the components built in the right place.  And the As-Built Joint is the culmination of that workflow.  If the components are in place, then it is very easy to create joints between them.  Finally, the ability to do position-based modeling is also very powerful in this workflow - to be able to reference a component inside another component, at a certain position, I find very useful.

 

So, when should you use external components?  Your mileage may vary, but I find that external components are very useful for components that don't change much (off the shelf stuff), because then you don't need to have all the features for building those components cluttering up your timeline.  There is also a performance aspect to it.  For small designs, having all the components in a single timeline is great.  Once you get above 50 components or so, it becomes a nightmare to manage (more on that later), and can be slow to modify one of the early components in your design.  So, if you know you are going to be building a large design, it's good to think up front how you might want to break it up.  Maybe along subsystem boundaries makes sense.  A lot of this just takes time and experience to find the way that works best for you.

 

And, the points raised here about it being very easy (too easy, maybe) to create a dependency nightmare using local components is a very good one.  Be very aware of what you are referencing where.  Sure, sketching on the face of another component, or auto-projecting an edge/face from another component into a sketch is convenient.  But, every time you do that, you are creating a dependency in your design.  It's easy to end up with spaghetti dependencies, and as mentioned here, editing becomes very fragile.  So, turn off auto-projections.  Use datum planes without dependencies for sketch planes when you can.  Be very deliberate about projecting things into your sketch.  When you do need to project, choose the most stable thing you can project (a face is more stable than an edge, a body is more stable than a face, and origin work geometry is the most stable of all).

 

Use R.U.L.E. #1 and #2 to keep your components self-contained.  You will be much happier.

 

One last word about local components/top/down modeling.  If you want to save yourself future nightmares when you come back to edit them months later, be very careful in organizing your timeline.  Turn on "Component Color Swatches" to help you visualize your component organization in the timeline.  If you make an edit to a component, roll back to its area of the timeline and insert features, rather than just sticking them at the end of the timeline.  I take it one step further, and create a timeline group for each component, but that's just me.  And, as rule #2 says, rename everything.  It's so much easier to know which extrude created this notch if you have it named in the timeline.  Name your joints, workplanes, sketches, everything.  It is a pain at first, but you will thank yourself later.

 

 


Jeff Strater
Engineering Director
Message 10 of 29

Anonymous
Not applicable

Thank you,  Jeff. I  don't have a firm enough grasp of the big picture to understand all the implications of what you said but that kind of foundational understanding of the platform is exactly what I want to develop. Unfortunately, I  haven't found a good video explaining all of these concepts and mplications. I keep having to invest a lot of time only to find the path I chose was a bad idea. I'd love to find a "develop your F360 philosophy" video. 

 

Thank you for the detailed reply. I'll print this out for reference as I uncover and start to grasp all of the quirks of F360.

0 Likes
Message 11 of 29

Anonymous
Not applicable

For those who come across this thread after me, I found a set of videos that cover the "philosophy" of Fusion 360 design.  These cover "top down" and "bottom up" workflows as well as other foundational concepts that are helpful to understand before you start. 

https://help.autodesk.com/view/fusion360/ENU/?utm_campaign=email_sessionrecap_2_of_4_alt_fusion360&m...

There's so much information in so many different places, it is difficult to figure out where to start.

0 Likes
Message 12 of 29

kb9ydn
Advisor
Advisor

@jeff_strater wrote:

 

In my admittedly biased view, the ability to have local components is one of Fusion's coolest features.  Most of us came from Inventor, and it was a pain (a UI pain, a data management paint) to create a bunch of parts on disk just to get a quick concept design in place.  So, I tend to like to work with local components when I can.  Certainly when exploring design options, this is very handy.  There is also the related benefit of "design in place".  Again, this is much harder to do in a traditional parts/assembly modeler.  It is very convenient to be able to build up a design with all the components built in the right place.  And the As-Built Joint is the culmination of that workflow.  If the components are in place, then it is very easy to create joints between them.  Finally, the ability to do position-based modeling is also very powerful in this workflow - to be able to reference a component inside another component, at a certain position, I find very useful.


 

So from reading this I take it that Inventor doesn't have a way to create internally stored components in an assembly?  I've seen this topic harped on before (the Onshape guys in particular); that "traditional CAD" requires an external file on disk for every part or component.  But assuming that Solidworks for example is "traditional CAD", this just isn't true.  Solidworks has what it calls "virtual parts", which only exist inside an assembly, and do not have a separate file on disk.  In every other way they act just like regular parts.  And there are also virtual assemblies, which are the same as regular assemblies but don't have a separate file on disk.  So with these it's possible to have as many parts and subassemblies as you want, with everything stored in a single disk file.  You can also save virtual parts and assemblies out to their own files at any time, and even convert regular parts and assemblies in to virtual parts where the virtual part is no longer linked to the original external part.  All of this is really quite easy to do, and I use it all the time.  If Inventor doesn't have this, then I can see how it would indeed be a pain.

 

 

 


@jeff_strater wrote:

So, if you know you are going to be building a large design, it's good to think up front how you might want to break it up.  Maybe along subsystem boundaries makes sense.  A lot of this just takes time and experience to find the way that works best for you.


This is true I think for any CAD system, for any project of more than a handful of components.  It's also not something that you can really learn that quickly either.  The general concepts can be taught but it takes experience to internalize those concepts and know how to efficiently apply them.

 

 


@jeff_strater wrote:

If you make an edit to a component, roll back to its area of the timeline and insert features, rather than just sticking them at the end of the timeline.  I take it one step further, and create a timeline group for each component, but that's just me.


This is one thing that drives me insane with Fusion.  That it even allows features of a component to be strewn out over the entire assembly timeline is just asking for a maintenance nightmare.  And having to rollback the timeline to make edits to a component is not only tedious, it's counterproductive.  The single greatest advantage to component editing within context of an assembly is that you can see how the component fits in to the rest of the assembly.  It doesn't necessarily have to reference anything else (although that's useful too sometimes), it mostly just needs to be visible.  But when you roll back the timeline, half the design disappears.  How helpful is that?

 

I know that the Fusion way lets you do clever things like position based modelling (that you mentioned before), but I find the trade-offs with allowing this absolutely not worth the hassle that it creates the other 95% of the time.

 

 

C|

Message 13 of 29

chrisplyler
Mentor
Mentor

@kb9ydn wrote:

This is one thing that drives me insane with Fusion.  That it even allows features of a component to be strewn out over the entire assembly timeline is just asking for a maintenance nightmare.  And having to rollback the timeline to make edits to a component is not only tedious, it's counterproductive.

 

It only does that when you have the top level of the Browser activated. It's essentially showing you the timeline of the item you have activated, including whatever you have nested inside of that item. It's important that they be sequential, instead of organized by sub-items nested within that item you have activated, because:

 

Suppose you have created two new components within the main Browser assembly (the topmost item becomes an assembly as soon as you nest a new component within it). These two components are a rail, and something that slides along the rail. Suppose you have worked on both of your two new components, but neither is complete yet. Now you go back to component #2 (the rail) and you add a fillet on an outside edge. Then you go into component #1 (the slider) and you project that filleted edge in and finish it up such that #2 can slide along #1 and fits that filleted edge. Well, the dependency of the inside shape of #2 depends on that fillet in #1. So, if you don't have the rail's fillet event in front of the event that shapes the slider, it won't function correctly.

 

You think it's dumb, but you see, there is a good, logical reason for it.

 

If you want to see only the timeline of a particular component, activate that component. The timeline filters itself down to just the stuff contained in that item.

 

 

 

 

0 Likes
Message 14 of 29

Anonymous
Not applicable

As a new F360 user I would like to have a way to understand the best way to use the software since Inventor isn't an option for me anymore.  I think I figure out how to avoid intertangling components only to realize later that something tangled them that I didn't expect would do so.

It is an amazing software for free but the way it works requires so much trial and error to figure out it is very time consuming without someone to point out the quirks along the way.


Does anyone know of a good video that goes in depth about F360 design approaches and specifically what commonly causes problems and how to avoid them?

0 Likes
Message 15 of 29

TrippyLighting
Consultant
Consultant

@kb9ydn wrote:

@jeff_strater wrote:

  And having to rollback the timeline to make edits to a component is not only tedious, it's counterproductive. 


Here is an easier way to do this:

Activate your component.

Roll the timeline back one step

Roll it forward one step.

Now you are at the end of the timeline of that one component and any thing you add now is aded to the end of the timeline.

 

Definitely not a one-click solution, but Fusion 360 is not yet at the point of refinement of Solid Works for example. I generally shudder in disbelieve when people start comparing Solid Works with Fusion 360 and wonder what in the world these people do with Solid Works. The breadth and maturity of functionality Solid Works has today will take another 10-15 years to appear in Fusion 360.

 

I agree with many of your assessments. It is very easy to create relationships between components and the timeline is not particularly informative, neither does Fusion 360 offer any more verbose ways to visualize relationships, let alone fix them.

 

 

 


EESignature

Message 16 of 29

carlhitchon
Enthusiast
Enthusiast

There's a difference between a geometric dependency and a linear history of features (timeline).  For many features, it matters not at all when they were created relative to other features.  Instead of a timeline, it seems to me that a dependency lattice is needed.  That's a 2D graph structure, which requires a separate window that you can open and close or use side by side.

 

Sketches components features would be lattice nodes and dependencies lines connecting them.  By clicking on a node you could show or hide all the dependent features.  That way you can look at portions of the dependency structure without seeing all the stuff that is irrelevant to that portion.

 

Note how you can move something in the timeline and get "circular dependency", but it's difficult to see why.  With a dependency lattice such a move would be obviously not possible (just looking at the lattice) without breaking one or more dependencies.

 

Maybe with that approach this inability to restructure components (which for me is fatal to the design process) could be mitigated.  The timeline is just crushing the entire lattice into a line (with largely arbitrary order of nodes) that's not very helpful and fails to directly display any dependency. You can find them (sort of) by attempting to move things along the timeline.

 

So I think the timeline is a mistake.  What you need is a way to visualize the dependencies. It matters not at all what order they were created in, just what the actual dependencies are.

 

 

0 Likes
Message 17 of 29

kb9ydn
Advisor
Advisor

@chrisplyler wrote:

Suppose you have created two new components within the main Browser assembly (the topmost item becomes an assembly as soon as you nest a new component within it). These two components are a rail, and something that slides along the rail. Suppose you have worked on both of your two new components, but neither is complete yet. Now you go back to component #2 (the rail) and you add a fillet on an outside edge. Then you go into component #1 (the slider) and you project that filleted edge in and finish it up such that #2 can slide along #1 and fits that filleted edge. Well, the dependency of the inside shape of #2 depends on that fillet in #1. So, if you don't have the rail's fillet event in front of the event that shapes the slider, it won't function correctly.


And that's just it.  I don't want that dependency.  If I were doing the above I would edit each of the components individually such that they don't depend on each other.  Why?  Because every dependency you add creates one more opportunity for the model to break later when you make more changes.  It also has a performance penalty because it's one more thing that the solver has to compute.  A few of these dependencies aren't a big deal, but I can tell you from experience that as a design grows, it can get REALLY nasty in a hurry.

 

 

C|

0 Likes
Message 18 of 29

kb9ydn
Advisor
Advisor

@TrippyLighting wrote:

@kb9ydn wrote:
And having to rollback the timeline to make edits to a component is not only tedious, it's counterproductive.

Here is an easier way to do this:

Activate your component.

Roll the timeline back one step

Roll it forward one step.

Now you are at the end of the timeline of that one component and any thing you add now is aded to the end of the timeline.

 

Definitely not a one-click solution, but Fusion 360 is not yet at the point of refinement of Solid Works for example. I generally shudder in disbelieve when people start comparing Solid Works with Fusion 360 and wonder what in the world these people do with Solid Works. The breadth and maturity of functionality Solid Works has today will take another 10-15 years to appear in Fusion 360.

 

I agree with many of your assessments. It is very easy to create relationships between components and the timeline is not particularly informative, neither does Fusion 360 offer any more verbose ways to visualize relationships, let alone fix them.


 

Ahh, that's quite clever!  I'll have to remember that trick.

 

Re comparing Fusion and Solidworks; yes it probably is unfair and I'm fully guilty of making this comparison too often.  Smiley LOL  Given it's relative newness it's understandable that there will be incomplete features and that the UI won't be very streamlined.  But the entire idea of the timeline when working with assemblies is quite fundamental to the workings of Fusion, and it has severe (I would say negative) implications when it comes to working with large models.  So it's hard for me to imagine that the developers didn't foresee this being an issue and build in a way to handle it from the beginning.  I'm SO hoping there is a plan for making Fusion better at working with larger models, but to date I haven't seen any indication of that.  And that is what worries me the most.

 

C|

 

0 Likes
Message 19 of 29

kb9ydn
Advisor
Advisor

@carlhitchon wrote:

There's a difference between a geometric dependency and a linear history of features (timeline).  For many features, it matters not at all when they were created relative to other features.  Instead of a timeline, it seems to me that a dependency lattice is needed.  That's a 2D graph structure, which requires a separate window that you can open and close or use side by side.

 

Sketches components features would be lattice nodes and dependencies lines connecting them.  By clicking on a node you could show or hide all the dependent features.  That way you can look at portions of the dependency structure without seeing all the stuff that is irrelevant to that portion.

 

Note how you can move something in the timeline and get "circular dependency", but it's difficult to see why.  With a dependency lattice such a move would be obviously not possible (just looking at the lattice) without breaking one or more dependencies.

 

Maybe with that approach this inability to restructure components (which for me is fatal to the design process) could be mitigated.  The timeline is just crushing the entire lattice into a line (with largely arbitrary order of nodes) that's not very helpful and fails to directly display any dependency. You can find them (sort of) by attempting to move things along the timeline.

 

So I think the timeline is a mistake.  What you need is a way to visualize the dependencies. It matters not at all what order they were created in, just what the actual dependencies are.

 


 

This very idea (a dependency graph) has been suggested before.  But I would take it a step further and say that in addition to a dependency graph, what it needed is a way to avoid assembly level dependency completely.  In other words, allow assemblies to be built without a timeline.  As you alluded to above, the vast majority of the time it dooesn't matter what order you create assembly components in, so why bother forcing an order?  It's extra stuff that you and the software have to manage for no reason other than "sometimes it might be useful".  Ok, then let ME decide when it's useful or not so I can turn it on or off appropriately.

 

This won't solve all problems with restructuring designs but it will help for sure.  And it would also make bottom up design easier.

 

 

C|

0 Likes
Message 20 of 29

TrippyLighting
Consultant
Consultant

@kb9ydn wrote:
In other words, allow assemblies to be built without a timeline. 

You can do that already. Simply start a new empty design and turn off the timeline and start inserting componebts/subassemblies.

This is generally a good workflow as it is indeed much easier to re-organize assemblies.


EESignature