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.
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).
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?
Made a tool component with the help of that pattern. So now I have:
- two components
- one joint origin for each
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, 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
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:
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)
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.
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
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?
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)
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. ]
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,