Unable to select joint origin/ in which component is a joint origin generated?

[R4SMEs]

I have three main components in a model, let us call them X, Y and Z.

Within component Z, I define (sub)components Z1 and Z2, which are wooden panels having a small clearance gap between them.
[So Z is "The component that contains the two panels Z1 and Z2" - later there will be other components within Z such as screws, handles, ...).

I require these two panels Z1 and Z2 to have a hinged joint between them.
[At the moment there is not the complexity of a hardware hinge - I am simply trying to define a revolute joint between Z1 and Z2 at present - effectively, as a "virtual hinge".]

So, with component Z active, I define an As-built Joint Origin between the two faces of the components Z1 and Z2.

Two questions/ issues arise:

Question A:
The first question/ observation is: within which component is the Joint Origin generated?

Following several attempts, my observation is that (following the above procedure), the answer is: sometimes in Z1 and sometimes in Z2 (but, as-yet, I don't see it being generated in Z, where I would expect it to be - given that Z was the active component at the time of defining the Joint Origin).

JointOriginIssues.png
This illustrates what I am writing about.

How to have it generated in Z, where it logically belongs?
It logically belongs in Z since it relates to a joint location between Z1 and Z2, rather than only to one of these (sub)components.

Question B:
The second related question/ observation is: Why is it not possible to see/ select the already-defined joint origin?
When I subsequently try to define the As-built Revolute joint, after selecting Z1 and Z2, the previously defined Joint Origin is not seen.
Consequently, I am unable to define the joint 😞

No doubt, I could work around this issue by being in the top level of the model when defining the Joint Origin.
However, I consider that the Joint Origin properly belongs within Z (it is unrelated to components X and Y which are at the same levels as Z in the overall model).
In the interests of keeping things logical (which is good practice, especially in supporting development of complex models) I should like the Joint Origin to be in Z!
Following which, I should expect that issue B will be overcome, i.e., I expect that it will then be possible to define the associated revolute joint.

[TrippyLighting]

I think your misconception is that you have to create separate (explicit) joint origins before jointing components. That's not needed most of the time. When you create a as-built rigid joint between Z1 and Z2 you are not required to pick a joint origin on any geometry because the as-built rigid joint references the origin of the componetns (so does the rigid group joint).

Only when you create regular joints are you required to pick (implicit) joint origins on geometry to define where you want the components to join. Implicit joint origins are only visible during joint creation.

The joint is then owned by the upper level component, so "Z" in this case.

[R4SMEs]

Here we are talking about a revolute joint between Z1 and Z2, not a rigid joint.

There is a small gap between the panels so I assumed that the way to do this was to first define the joint origin using the "between 2 faces".

Elliptical Butterfly Expanding v24.f3d
This is the complete model so that you can better understand what I am trying to do.

Obviously Z is "Butterfly assembly", Z1 is "Upper panel" and Z2 is "Lower panel".

[TrippyLighting · Accepted solution]

In that case you need to create an as-built revolute joint between Z1 and Z2 and choose "between faces" when asked to pick the joint location:

[R4SMEs]

Okay, many thanks.
I accept that it is possible to by-pass the need to define an as-built joint
As you demonstrate, the revolute joint including its specific position can be directly defined in a single operation and - being simpler - is certainly the best approach in this case.

Nevertheless, considering a more general situation (e.g., where the joint is to be in a somewhat strange location), it may be clearer to first define a Joint Origin.
So, logically, questions A and B remain valid questions.

Here I define a joint origin when Z is active, yet it goes into either Z1 or Z2 but not into Z as I should expect.
[Whether Z1 or Z2 may possibly depend on the order of doing things ... I am not sure about that.]

I have been perplexed in many other instances in understanding where things "go" in Fusion 360.

I don't have another specific particular example at the moment, but was hoping that resolving the current issue would improve my understanding of procedures/ whether relating to what I am doing or to possible minor bugs in Fusion?

[TrippyLighting]

Aha! I agree that there is a bug at play. To be honest, this is not surprising. In 6 years of working Fusion 360 I've not use that option once 😉

At the very least I would expect the joint origin to be created in either Z1 or Z2 when I activate the component first. However, the joint origin is created (in my example) always in the first component.

@jeff_strater @ryan.bales can you please check this out ? 

[R4SMEs]

Trying to express this in more general, formal terms ...

With component Z active, if an "operation" is performed involving subcomponents Z1 and Z2, the result should be associated with (i.e., located in) component Z.

In this case, the "operation" involves Z1 and Z2 in a completely symmetrical way.

I am not sure if "operation" only relates to "Joint origin" but imagine there will be other types of "operation" that have a similar somewhat buggy performance?!

[TrippyLighting · Accepted solution]

Scratch that! No bug, but how the heck would anyone figure that out ?

When creating the joint origin with :"between faces" you'll first need to pick the two faces and then you need tp pick the "snap location". Whatever component the geometry for that snap location resides in will receive the joint origin.

[R4SMEs]

I still consider it somewhat buggy ...

The snap location, by definition, is "between 2 faces", so really shouldn't be tied to either of the 2 components but relate to the higher level component that contains those 2 components.
Really, the joint origin should hover mid-way between the 2 faces without a line associating it only with one of the two!

In this way, one can clearly understand that it is an aspect that represents a linkage between the 2 components, i.e., not just related to one of them.

Further generalising what I previously wrote, my opinion is that:

With component Z or Z1 or Z2 active, if an "operation" is performed involving subcomponents Z1 and Z2, the result should be associated with (i.e., located in) component Z.

In this case, the "operation" involves Z1 and Z2 in a completely symmetrical way.

I am not sure if "operation" only relates to "Joint origin" but imagine there will be other types of "operation" that have a similar somewhat buggy performance?!

[TrippyLighting · Accepted solution]

In retrospect this aligns perfectly with the concepts implemented in Fusion 360.

An explicit joint origin has to be owned by a component and using the snap point, which requires the user to pick geometry for a component, is a perfect designation as to what component the joint origin belongs.

@Jamie.Scherer The documentation does not explain this but it should be a worthy addition to it 😉

[jeff_strater · Accepted solution]

I can explain the thinking around how this works.

Yes, Active Component does control "where new things go" in most cases.  Joint Origin is one exception to that rule.  This is intentional, mostly because the component owner of a Joint Origin is very important.  You always want the Joint Origin to move with the component that owns the geometry associated with the Joint Origin.  Otherwise, you would get some weird behavior in the joint itself (it would move whatever component owned the Joint Origin).  Basically, the idea was that creating these things should always do the "right thing", and put the JO into the component that owns the geometry you selected.  You could argue:  "why not do that for sketches, as well?", which is an argument we actually had early in Fusion days.  I guess the case for sketching on a face not owned by the desired component is much stronger than the case for a JO involving geometry not owned by the target component.  Is that  inconsistent?  Yes, it is.  Surprisingly, though, to the best of my knowledge, until now, this question has not come up.

Regarding "between two faces":  This one is not quite so obvious, because you are selecting geometry from potentially multiple components.  You need 3 selections for a "between two faces" JO - two faces, and some other geometry to specify the precise position of the JO.  What looks to me like what is happening is that the owner of that 3rd selection determines the owner of the JO.  Seems like a reasonable answer to me.

One last point:  Another place where the active component is ignored is the owner of the joint itself.  A joint is created in the "least common parent" of the two inputs selected, regardless of whether this is the active component or not.  Unless...  that least common parent is an external component (which is read-only), in which case the joint is put into the top-level component of the design.

Hope this answers the question.

[R4SMEs]

Many thanks for the in-depth response to this subject.

What do you mean by "least common parent"? (Last paragraph of the post.)

I understand most of what you are saying but shall need to further ponder these details to fully appreciate them!
Please bear in mind that I am still in Fusion 360 learning mode!

My overall thinking was that it seems (would be) nice and logical for the levels of components to clearly indicate dependencies.

With my thinking, if there is a joint origin in component Z1, it implies to me that there are 2 things joined in Z1.
It seems surprising/ rather confusing that, actually, the joint origin may be between Z1 and Z2.

I am not sure exactly how things work for sketches.
I recall seeing some puzzling aspects but can't recall the details.

One aspect of sketches that I can think of that seems surprising:
If, for example, there are 3 components X, Y and Z (at the same level within the model).
There is a sketch in X.
With Z active, it seems possible to see the sketch and even construct a further sketch or geometry based on parts of that sketch present in X.
Logically, this seems rather inappropriate although I admit that it can be convenient!

It seems more logical for the sketch in X to be hidden/ inaccessible unless X (or a higher level component of which X is a sub-component) is active.
In other words, if one wanted to be able to access that other sketch from Z, it should not be in X but at a higher level in the model, of which Z is a sub-level.

Apart from being "more logical", being able to access the sketch in X when Z is active seems to muddle understanding of the dependencies in a model,
which I imagine can complicate understanding and maintainability of the model as it grows in complexity.

Equally, from the sketch being developed in Z, components/ bodies in X and Y can be projected into the sketch.
Again, this is no doubt convenient but doesn't seem to be completely logical!

As a further thought ...
When a component is copied or patterned, all the details appear to be replicated.
So if the component includes, e.g., sketches, there are then multiple copies of the same sketch.
[Presumably a change to any one of those sketches updates the other sketches ...? Or, does it?]

Would it not be possible to have the original data (including the sketch(es) on which it is based) of the replicated component just in one single place, with the multiple copies just having the different data specific to the copy (i.e., their location and, ideally, specific name)?

If a quantity of 10 M6 bolts are required, we have to have components:
"M6 bolts"
+ 10 subcomponents "M6 bolt" where there is extensive repetition of all the details in each of the 10.
[Whilst it is not possible to rename these as, e.g., "M6 bolt top", "M6 bolt bottom", ...]

Copied or patterned component are identical apart from being able to be moved to different positions.
It is a little surprising that they must all have the same name: a change of name in one is replicated to the others.

Those are my general thoughts for the moment ...

[TrippyLighting]

Given that your initial questions have been answered and properly workflow demonstrated feel free to mark one or more answers as solutions 😉

I appreciate that you give that much thought to the structure of your designs and what might and might not appropriate and convenient. This, however, varies based on what you design. If you design machinery and want to re-use components I agree that some things that seem convenient are inappropriate.

People that predominantly just model geometry for visualization often need to very fast and convenient shortcuts are welcome.

I personally often need to create concept models (for machinery) and have to be  fast. Over the years I've found what conveniences I can get away with without breaking my designs.

A good way to create stable designs is to avoid unnecessary references and the BORN modeling technique provides excellent methods.

[R4SMEs]

Okay, I accept that the discussion has been wandering off topic, I shall mark as "Solved" as you suggest.

I am busy learning Fusion and trying to work out appropriate workflows.

The challenge seems to be to minimise the spaghetti-like structure that can easily develop in a model making it both hard to develop and maintain.
A simple change in one place often propagates in unexpected ways in other places.

Thanks again to all for your help!