Dont try to build spaceships

[HenryDara]

The Fusion 360 Splash screen shows a wonderful spaceship looking thing, boasting the innate abilities of Fusion 360 to create complex assemblies that can take you to the moon. First I must say that I think Fusion 360 is awesome, it really is, but its not all that.

What ive learned about Fusion components and assemblies is that they will ruin your day, and cost you lots of time if you use them as though they always work. The truth is, a design with lots of dependencies between components will sooner or later fail and have to be re-done from scratch. Joints will go yellow for no reason, alignments wont function, timelines will get corrupted where features cannot be removed, even if you want to get rid of the offending feature. And you will just give up and redo your design, hopefully getting closer to the mark the second time around (but never all the way there)

The only designs that dont have this problem are those that were built from components referenced externally to the main design. Which was how I started doing this to begin with until I wanted to build the spaceship from the splash screen (I mean that euphemistically of course)

So to avoid expensive time losses, i am now saving my components externally, and then re-importing them (after some external massaging) back into the design, in an effort to remove all dependencies that cause such problems.

Although this has me going back and forth between designs, and re-updating constantly, it always keeps things straight, and problems compartmentalized within their detached designs.

I really enjoyed working with Fusion 360 components, and building complex fully integrated designs, until I didnt. When it goes bad, it goes really bad, so IMHO Fusion is just not fully there yet for fully integrated workflow within a single design with more than just a few components.

[jeff_strater]

@HenryDara - do you have any examples to back up these beliefs?  If there are bugs in Fusion, we would very much like to fix them, but, frankly, we need data in order to find and fix them.  In my experience, I have never seen a case where "Joints will go yellow for no reason", or any of your other claims.  In fact, I spent a week recently, investigating another user's claim of joints failing for "no reason", only to find that every single failure was caused by an edit, or sloppy modeling. 

It's a perfectly OK workflow to always build designs from the bottom up (external components) if you want to, and I support that workflow if it works for you, but I don't believe in any way that that workflow is any more stable than top/down (all local components).  Again, if you have data that shows that, we would very much be interested in it.  

[HenryDara]

Thanks Jeff, I appreciate your input always. I am convinced that my problems are a direct result of something Ive done wrong somewhere along the way. More times than not that is the case. I try to clean up yellow stuff in the timeline as soon as I see it, and after redoing designs a few times I have really tried to be more careful, but I can never be careful enough. I can always, without fail manage problems if I detach my components often. Yes, it would be nice to fix "me" someday, and I am working on it, but for those that struggle as I do, this might be a helpful way out. I understand your concerns over poor modeling, but sometimes the kind of perfection Fusion requires are outside of most users abilities. For those this might be a better way of getting the job done regardless of small mistakes in the workflow.

Thanks again.

[GRSnyder]

@HenryDara, I don't know if this is what you mean by "saving your components externally and then reimporting them", but I have also started breaking out complex subassemblies into separate Fusion 360 files and then reincorporating them through Insert Derive, cherry-picking only the final bodies or selected sketches and parameters. I like this approach a lot - I don't think of it as a workaround so much as good general hygiene. 

Fusion 360's UI is designed for a certain scale of operations. There is after all only a single master timeline of everything you've ever done in a project, and you can't really work work on subassemblies without keeping in mind how their operations relate to the global timeline. You can use grouping and various other tricks to limit the timeline to one screen's worth, but ultimately things work best if you keep each file to a reasonable scale. 

[Beyondforce]

@HenryDara ,

So basically what you are saying to newbies, don't spend time to learn F360 basics and best practices.

From what you are describing, you never learned the difference between Delete vs Remove command since in many/most cases, that's why you get warnings and errors! Which is also why I have created a detailed video just for that on my YouTube channel.

On the other hand, I do understand your reaction. It is an emotional reaction and not logical. Men, in general (including myself), don't have patience and don't like to read instructions and naturally, it leads to all kinds of problems. It's easier to blame others than ourselves. All you had to do, is to ask for help and ask specific questions!

I'm with @jeff_strater  100%. 

Remember, there are many people in this forum that want to help you, so go ahead ask us questions! 😃

Cheers / Ben
---------------------------------------------------------------------------------------------------------------------------
Did you find this reply helpful? If so please use the Accept as Solution or Kudos button below.

Need a new computer? Fusion 360 Hardware Benchmark: TESREG.com
Check out my YouTube channel: Fusion 360: NewbiesPlus

[janus2]

I am not planning a spaceship, but a mechanical calculating machine from the year 1700! It consists of more than 1000 parts. In many assemblies with lot of gears and many joints.
In the beginning I had many problems and error messages with Fusion 360. Sketches not fully constrained. Wrong use of Delete/Remove. Not following Rulle#1. And so on.
I have started three times completely new.

But now I have a very stable model of the calculator and can simulate the function completely. Now I am already in the stage of production. The integrated CAM is a very big help. This was also the reason to switch to Fusion 360.

Changes can be made very easily and quickly. Recalculate CAM data in seconds. And the milling machine is running again.

My advice:

Get to the bottom of the problems. If necessary, rebuild individual assemblies. You can copy the components with paste new. Then it is not so much work.

Good luck
Jan

[TrippyLighting]

While I don't necessarily agree with all of the the OP's statements, I can certainly sympathize with it.

It isn't that complex things cannot be built in Fusion 360 but it takes a lot of discipline and in the heat of the battle  even the most disciplined person is going to make a mistake at some point in time. 

This is important feedback from a user and it should not be taken lightly!

I'd have my own feedback to add but don't have the time to write a lengthy post. In shorts, however, there are certain things I'd like to turn off, for example. E.g. If I don't use joints to model stuff I don't need to see them in the timeline.

Just as Parameters, Joins could also be timeless!

[Beyondforce]

@TrippyLighting,
This is a good point and a great idea! The ability to filter (show/hide) features from the Timeline.

Show/Hide: Joints, Sketches, Planes, etc.

[TrippyLighting]

@Beyondforce That's not what I meant. I really don't want certain things recorded in the timeline at all.

[Beyondforce]

Okay, but who decides what should be recorded and what shouldn't?

[TrippyLighting]

The user, through preference settings.

I have a reason for making this suggestion. The other CAD app I work with at the moment uses some of the same core concepts as Fusion 360. For example it allows you to create an assembly in one file (including drawings BTW). The history is recored on a part/component basis. References can be made to geometry or objects in other components at certain points in those components timeline, or not if the user chooses to do so.

Assembly, is excluded from the timeline, because mostly there really isn't any use for that.

[Beyondforce]

I see what you mean. But honestly, I wish that what the problem that beginners have.
Many beginners still don't know the difference between Delete vs Remove or how to work with Components (R.U.L.E #1)! 😉
But personally, like yourself, I would like to see some changes to the UI/UX - Like the Timeline or the ability to change the numbers with the mouse wheel.

[kb9ydn]

---

@TrippyLighting wrote:

The user, through preference settings.

I have a reason for making this suggestion. The other CAD app I work with at the moment uses some of the same core concepts as Fusion 360. For example it allows you to create an assembly in one file (including drawings BTW). The history is recored on a part/component basis. References can be made to geometry or objects in other components at certain points in those components timeline, or not if the user chooses to do so.

Assembly, is excluded from the timeline, because mostly there really isn't any use for that.

---

Excluding assembly from the timeline would be such a huge help for larger assemblies.  Having joints in the history tree allows for some interesting things but the vast majority of the time (for me anyway) it's just not worth the extra management hassle.

Also, breaking things down into self contained sub-assemblies is pretty much mandatory for large designs.  Fusion is halfway there in that it allows for externally linked (and therefore self contained) assemblies.  It just needs the ability to do in context editing of those sub-assemblies.  I could sear i read somewhere that this is actually in the works, but i don't remember where.

C|

[jeff_strater]

@TrippyLighting - good point about this being feedback from a user, and not to dismiss it.  What I was reacting to, though, was the blanket statement that local components vs external components, as a design paradigm, is inherently less stable.  I don't have any evidence that this is the case.  I'm not even saying that it is not true, only that I don't have any evidence to show that it is true.

What I will agree with, though, is that it is probably easier to get yourself into trouble with a top/down, all-local design than with external designs.  Especially with some of the options that exist.  Auto-project being my personally least-favorite option - this option, while appearing to make Fusion easy to use (no troublesome manual projecting), actually can result in some really undesirable dependencies being added to your design.  I would bet that a lot of the "fails for no reason" problems that people run into are actually the result of a misunderstood dependency that is later violated by a design edit.  We've talked about trying to put some guard rails in place, but we always get lost trying to describe what those guard rails would be.

The other comment here that I would make is:  there are definitely limits to the all-local workflow.  I was working with a customer design which had 10,000 features in it.  That was definitely stressing out the system, and I would never have had the patience to get the design to that size in a top/down workflow.  I think the sweet spot is to divide your design into sub-systems of a "reasonable" size, and within those subsystems, all-local components are fine.  Then, just assemble them in a top-level assembly, which could be parametric or direct.

[lichtzeichenanlage]

That's an interesting concept. 

[TrippyLighting]

---

@jeff_strater wrote:

@TrippyLighting - good point about this being feedback from a user, and not to dismiss it.  What I was reacting to, though, was the blanket statement that local components vs external components, as a design paradigm, is inherently less stable.  I don't have any evidence that this is the case.  I'm not even saying that it is not true, only that I don't have any evidence to show that it is true.

---

I  don't think that blanket statement is true either. I personally find the ability to work in one design file very helpful. Fusion 360 cannot deny its top down design roots and that's where working with it is the most fun (for me).

---

@jeff_strater wrote:

What I will agree with, though, is that it is probably easier to get yourself into trouble with a top/down, all-local design than with external designs.  Especially with some of the options that exist.  Auto-project being my personally least-favorite option - this option, while appearing to make Fusion easy to use (no troublesome manual projecting), actually can result in some really undesirable dependencies being added to your design.  I would bet that a lot of the "fails for no reason" problems that people run into are actually the result of a misunderstood dependency that is later violated by a design edit.  We've talked about trying to put some guard rails in place, but we always get lost trying to describe what those guard rails would be.

---

Sometimes there is just no Easy Button. Just turn that off being a default. Even new users get irritated by that 😉

---

@jeff_strater wrote:

The other comment here that I would make is:  there are definitely limits to the all-local workflow.  I was working with a customer design which had 10,000 features in it.  That was definitely stressing out the system, and I would never have had the patience to get the design to that size in a top/down workflow.  

---

As already mentioned the other app manages the timeline/history on a Component/Part basis. It will warn when an assembly or component is out of date but it is up to the user to either invoke the update manually or set it to update automatically.

That management on a component basis helps limiting re-computations to a good degree already, but at the cost of some user responsibility. You've got to pay some attention. That form of workflow might be out of scope for Fusion 360.

However what would certainly be in scope is a freeze bar. Right now we can roll the timeline marker back from the end, but we don't have the equivalent of a freeze bar that we can roll forward from the start to indicate this is done and does not need to be re-computed. Again, that comes at some user responsibility and awareness of what they are doing with the design.

[MichaelT_123]

Hi Mr GRSnyder,

Your statement:

There is after all only a single master timeline of everything you've ever done in a project, and you can't really work work on subassemblies without keeping in mind how their operations relate to the global timeline. 

is not accurate and it might cause damage to brains of innocents.

Every single component in a design has its own separate timeline accessible via UI and/or API.

This local timeline is also intertwined with others in many cases in such way that it create hard to open knot... quite common experience!

Sincerely

MichaelT 

[GRSnyder]

---

@MichaelT_123 wrote: Your statement is not accurate and it might cause damage to brains of innocents...Every single component in a design has its own separate timeline accessible via UI and/or API.

Well, it's true that corrupting the minds of innocents is my chief delight. So I'm sad to be impugned when--just this once--I was being so forthright. 🙂

I'm sorry to differ with you, but I don't think components have timelines. In the API, there seems to be only one timeline per document, and that is an attribute of the Design object.

The mini timeline Fusion 360 shows you for a particular component is nothing but a **** lie. (Forum system: "invalid HTML was found in the message body" 🙂) It's just a version of the global (by which I mean "document-wide") timeline filtered to remove events external to the active component. Your actual state of "now" is always a position on the global timeline. Or in other words, the "now" indicator you see in the filtered timeline for the active component does not necessarily correspond to a unique position on the global timeline. Fusion 360 is maintaining more timeline context than it shows you.

You can verify this experimentally by setting "now" in the root timeline, activating a component, creating a feature, and returning to the root component. The feature will appear wherever you defined "now" in the root timeline.

[MichaelT_123]

Hi Mr. GRSnyder,

... do not take this too seriously.

Time is quite complex, volatile, hyperbolic subject. It is undoubtedly slick and nondeterministic phenomena/concept.

I know, this is a little philosophical, and some people might have the allergy to it, so if you one of them, dull your senses by your personal antidote or just switch to Net-fix-me.

So, there must be at least two conditions which should be fulfilled for Time to exist.

The first:         There must be Observer

The Second:    There must be Event

Observer and Event are exchangeable and reciprocal. One can be the other.

The conjunction of these two creates what we call Time.

There are some consequences of such a definition:

- time is local (to the Observer)

- time can stop to exist if one of the condition is not met.

- time is subjective (to the Observer)

- local Time(s) can traverse each other

- local Time(s) can interfere with each other (changing perception(s) of Event(s) by Observer(s) )

- local Time is submersive as it embeds/conjoins with others to create Time Fabric

- Time can be reversed (means perception of the Observer can be reversed),.. conditions here ...

- Time can only be measured /sensed/shared by describing Events

- .... think about other implications ...

I think it is enough…let’s punch the ballon and hard land in F360 backyard.

The design process is represented by a sequence of creation Events. These Events are described/recorded by the Observer in many ways: in the file structure, memory, in a graphic user interface, etc.

They can be post-factum observed and analysed. The global synthetic view can be represented by the design’s timeLine. It does not describe the whole perfect history of a design process (Events), but it exposes main, important ones. This is a global perspective as visualised in the graphic user interface when RootComponent is activated. The RootComponent is Observer here. The colourful stripes at the bottom of the screen represent embedded Time(s) from some local Observers. They could be a local design creation, imported one, derived, etc. They constitute the Time Fabric of the whole design (global Time) with a structure (texture) of various complexity. Each component (native occurrence) can also be the Observer and find out the (main) Events which enacted its own existence (Event and Observer are reciprocal). It also has (as well as its children) associated Time-Event stamp mapped into its parent or global timeline (they are submersed).

How all of these relate to the practical implications for F360 CADman and his\her mouse?

Look at the design fabric (embedded local Times) their relations, aggregations or dispersions, interrelations. The homogenous flow of colours will indicate a smooth well-lubricated design concept flowing from your intelligent part through your arm, palm and finally by your best friend-mouse into the F360 cloud,… potentially later hitting someone back on this forum, creating another Event.

Regards

MichaelT

[TrippyLighting]

@MichaelT_123 you couldn't have possibly explained that in one sentence ?

LOL