Community
Fusion Design, Validate & Document
Stuck on a workflow? Have a tricky question about a Fusion (formerly Fusion 360) feature? Share your project, tips and tricks, ask questions, and get advice from the community.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Component requirement sucks (no can join bodies)

9 REPLIES 9
Reply
Message 1 of 10
lure23
696 Views, 9 Replies

Component requirement sucks (no can join bodies)

I need help understanding why some things are only allowed for 'components'. It seems to me that it's simply an implementation detail, a thing coming from the code base up - and being nastily visible to us users.

 

Current problem is this: 

 

I have a group of boxes (with a joint origin) and a thickened cylinder (with a joint origin). I would like to align these. 

 

Can that be done?

 

Nope.

 

no_can_join.png

 

Both the pattern and the cylinder are dimmed, meaning not available for clicking.

 

I can see no reason the computer couldn't calculate the transformations to turn the pattern around and place it perfectly where I want. I know I must make these into components, but then there seem to be places where having components is not very handy (i.e. one cannot do a pattern of them).

 

Sigh.

 

Please tell me the justification of having "components". Maybe I will obey.

 

--

Made the bodies components and attached the joints. This happens (the joint isn't moving the whole group - maybe it is no group any more that the individual bodies were made into components; but there was no option to make a pattern into components). 

 

componented.png

 

There's a video about a similar situation, and in that the pattern is moved to right position by 'move', not by joints. But in other threads here, joints have been promoted as a way to manage such situations. I think both ways should work.

 

What's the right way?

 

Asko Kauppi

IT guy into Cleantech.
9 REPLIES 9
Message 2 of 10
lure23
in reply to: lure23

Made a tool component with the help of that pattern. So now I have:

- two components

- one joint origin for each

 

components_still_reluctant.jpg

 

Joint still doesn't accept to marry these.

 

I should be able to select either a component or a joint origin to both the 'Component1' and 'Component2' selections, right?

 

I should be selecting the thing to move first (by experience). That would be the comb-like tool box.

 

- selecting 'Assemble > Joint'

- the pipe is selectable but the comb component isn't (why?)

- okay, let's select the pipe

- for the second component, I would get to select the comb-like box, but *not* the 'Joint Origin 7' placed within it. (why?)

 

Oh yeah. I had forgotton to actually promote the comb box into a component.

 

Now I seem to get through, but isn't this like a narrow alley in the dark? Some street lighting, please.

Asko Kauppi

IT guy into Cleantech.
Message 3 of 10
Oceanconcepts
in reply to: lure23

Asko,  I appreciate your frustration.  The role of components is something that doesn't get enough coverage in the tutorials or help, I believe.  

 

A couple of thoughts:  You can make a pattern within a component, you need to select the bodies. The "bodies" are still bodies, they are just wrapped in a "component" folder.  It also ends up being useful to set up nesting arrangements within components, so for instance an assembly you might want to move as a group could be set up, with components nesting inside the top level component.  It seems to me that bodies at the root level have very limited use in Fusion- as temporary construction helpers, perhaps, but the action seems to take place at the component level. Since the help and tutorials focus on fairly simple designs, this doesn't get pointed out enough. 

 

For instance- it was for me a bit hard to grasp initially that elements like construction geometry behave completely differently if they are created at the root level, versus being created within a component or subcomponent (with the component activated). At the root, they are construction references that are not associated with the originating geometry, within a component they are tied to and move with the component- perfectly logical and powerful, once you get it. But a leap of understanding, if you are used to working in a parametric environment with history. 

 

Ron

- Ron

Mostly Mac- currently M1 MacBook Pro

Message 4 of 10

yes, you are correct:  This is not an ideal workflow in any way.

 

You can get the system to work like you want using joints and components, but I'll admit that it is clumsy.  The basic idea is:

 

  • you need two components - one with multiple bodies (for your boxes), and one with just the cylindrical tube body.  The easiest way to get there is New Component, to create empty components, then drag the cylinder body into one component (in the browser), and drag the boxes into the other.
  • Then, you should be able to use joint to put these together.  You can also use the "Align" command (select faces of both components, and Align is in the context menu) to do the alignment without a joint, in some cases.

Now, no one would argue that this is good.  And, because we have heard this request enough from users trying to do real work that we are pursuing a more general approach of allowing components and bodies to be "snapped" together in a much easier workflow.

 

Thanks for the valuable input

 

Jeff Strater (Fusion development)


Jeff Strater
Engineering Director
Message 5 of 10

Hey Ron, Asko, and any else interested,

 

Jeff, Charles and I collaborated on the topic of bodies and components. We came up with some info that hopefully clears up some of the confusion between the two. You can find the content in the Bodies and components topic in the help. 

 

As always, please keep the feedback coming on the product or the help content. 

 

Thanks.


Patrick Miller

User Experience Designer
Fusion 360 Learning
Message 6 of 10

That's a very clear and much needed introduction to that, umm, component of the Fusion conceptual universe. 

 

One thing that I would also call out and emphasize- that can be a real stumbling block if you don't know- is the importance of "Activating" components in some situations- for instance when you want to associate construction elements with them.  If I want to create an axis or a mid plane and have it move with the part, it needs to be placed within the component. 

 

Also how selecting bodies from the drawing often yields different results from selecting them in the browser. 

 

Great work!

 

Ron

 

- Ron

Mostly Mac- currently M1 MacBook Pro

Message 7 of 10
lure23
in reply to: Oceanconcepts

Thanks, Jeff, Charles and Patrick.

 

One thought I had today regarding this is that if there was a "default" component instead of the root-level bodies and constructs, it might be more clear for the user. Now our initial learning is to play at the root level, only to find out that's rather counterproductive.

 

What do you think of this?

Asko Kauppi

IT guy into Cleantech.
Message 8 of 10
jeff_strater
in reply to: lure23

We have, at times, considered the idea of changing the default for commands such as primitives (box, cylinder) or features (extrude, revolve, etc) to be a new component.  The problem that this causes is an unnecessary level of component hierarchy if all you want to model is a "part" (to use an Inventor term).  It ends up being awkward to model a single component, because you really need to activate that component in order to put sketches, work features, etc inside the component.

 

One thing we have discussed is some kind of a notion of what a given user will be doing in a design.  If you could specify up front:  "I'm building a mechanism", or "I'm building a single object", then we could perhaps tailor the UI to those workflows:  default to "new component" for assembly/mechanism modeling or "new body" for single-component modeling.

 

The one workflow that I use a lot in my own modeling is "create components from bodies".  I find myself just accepting the default, which is "new body", and when I'm happy with what is there, just converting some/all bodies into components.  Then, if I need sub-assemblies, I use drag/drop in the browser to change the structure.  It's not perfect, but I find it useful.

 

This is a good discussion, and I hope it continues, because this is an area that we struggle with in the development team, and I know users struggle with as well.  There has to be a good solution...

 

Thanks for the great feedback

 

Jeff Strater (Fusion development)

 


Jeff Strater
Engineering Director
Message 9 of 10
lure23
in reply to: jeff_strater

Hi Jeff,

 

using root level is fine if I can then sum up the created (stored in separate Fusion 360 designs) constructs together in some other design = top level assembly. Such workflow would make sense in also other ways - we could give ownership of certain parts to certain people in the team, and combine the whole using Joint Origins. This would take away the burden of needing to merge changes done into a central, huge design. Also, it would allow multiple "playgrounds" to exist using the same components.

 

Is this the long-term intended model for Fusion 360?

 

Currrently, I think all the components must be in the same design (or copy-pasted there). [ Actually, I'm left watching the webcast in its middle. Maybe it's there. ]

Asko Kauppi

IT guy into Cleantech.
Message 10 of 10
haughec
in reply to: lure23

Yes, we are working toward this.  You can "Place" or Copy/Paste designs into a top-level assembly today, but they are then owned by that assembly with no reference to the placed design.  We definitely recognize the need to place components and maintain an associative link to the original design.  I expect this will be possible sometime after the first of the year.

 

Thanks,

 

Charles Haughey
Fusion 360 User Experience Architect

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report