Find dependencies of a design context

[johan.rutgeerts]

Hi,

I am working an a design with subcomponents, and somehow I unintentionally created extra design contexts 'Context4' and 'Context5':

Upon mouse hoover, Context 1, 4 and 5 all show the same tooltip: "Context from [top assy] v44" (can't share the top assy name).

Context4 and Context5 don't seem to contain any references, as there is no geometry?

Questions:

1. Can anyone explain when an existing design context is reused, and when a new one is created? I have no clue when/why these were created,
   
   
2. I would like to delete the extra contexts, but I want to avoid to discover later on that some features are failing due to missing references. Is there a way to check for dependents of these contexts?

Thank you,

Johan

[TrippyLighting]

@jeff_strater could you lend a hand, please?

[jeff_strater]

no, I cannot.  This is not an area with which I am familiar.  As far as I know, there is no way to reveal the dependencies of an assembly context, other than the obvious (delete it, see what breaks, undo).  Perhaps @kgrunawalt can provide more information.

[kgrunawalt · Accepted solution]

After you create a context intentionally via the pencil in browser followed by changes to external components, you should explicitly edit the context to do more work on those components if appropriate (that point in timeline and that particular occurrence of the external component are right for your edits). You edit a context via context feature in timeline or context in inserted document’s browser.

Otherwise, you might end up with more contexts than intended. Fusion warns you if the current timeline marker is immediately after the intentional context. If there are features between, fusion assumes you need to edit in a new context when you use the pencil.

Having multiple contexts is ok but it is simpler to have fewer. 

What does it mean when there is no referenced geometry under the context in the browser? It means that an edit was done in the child model that uses component positions imposed by the current parent assembly but no geometry from the parent. WE NEED TO MAKE THIS CLEARER! It’s a known shortcoming. Sometimes the need for parent positions is obvious, sometimes it is subtle. It’s obvious is you extrude a body in one component up to the face of another component and the relative position between them is determined by the parent assembly’s timeline. If both components are in the edited child subassembly, then the face reference is local and not part of the context. The assembly context needed to compute the extrude is just the imposed relative position between local components. The context appears empty in the browser.

Sometimes the need for parent position in context isn’t so obvious. Then you can get a seemingly empty context and it isn’t clear why. Fusion could do a better job showing the need.

You can see which features depend on these contexts by looking at their tooltips when hovering over them during the edit on the external inserted component. Features using a context will have its name in the tooltip. That might help identify how positions are used. Even just creating a new component can use parent positions. This might seem surprising. Fusion contexts are very powerful and flexible but a bit mind bending!

This is a long post. Please follow up with questions if it doesn’t help!

[johan.rutgeerts]

@kgrunawalt thank you for the clarifications!

And kudos to the design team on this functionality!!

If you haven't seen this post, then it might be worth checking out as it's a first draft of a 'best practice' to structure large assy designs using design contexts.

Some further questions/remarks below:

---

@kgrunawalt wrote:

After you create a context intentionally via the pencil in browser followed by changes to external components, you should explicitly edit the context to do more work on those components if appropriate (that point in timeline and that particular occurrence of the external component are right for your edits). You edit a context via context feature in timeline or context in inserted document’s browser.

Otherwise, you might end up with more contexts than intended. Fusion warns you if the current timeline marker is immediately after the intentional context. If there are features between, fusion assumes you need to edit in a new context when you use the pencil.

Ok this makes sense (I had to read it twice, though.. 😉). 

One has to be aware that "edit in place" is very different from "activate", in that it creates features in the top assy with a defined place in its timeline. And if you edit-in-place a component multiple times, that it might automatically create extra context features. This was not at all clear to me beforehand.

Maybe it would be beneficial to explicitly force the user to choose a context on edit-in-place?

E.g. by presenting a dropdown menu:

or by moving the edit-in-place pencil to the assy contexts:

Re. the warning message: I had no clue what it meant.

For a start, it gives you the options "Edit Context1" and "Create a new context if you make associative edits". But  if you're editing Context1, you are also making associative edits...

Anyway, it is clear now, but I still wonder: is there a practical use case where it would be beneficial to create a new context, when there are no changes in the design history? If not (or if this use case is very uncommon) then I'd skip this message and edit the existing context by default.

Also, consider following case:

• Assemble external components A and B in a top assy,
• Edit in place component A,
• An assy feature 'Context1' is created for component A,
• Edit in place component B,
• An assy feature 'Context1' is created for component B,
• Edit in place component A,
• A new assy feature 'Context2' is created for component A, although no geometry of the top assy was actually changed.

I didn't test this, but this would imply that if you alternately edit component A and B in place by clicking on the pencil instead of selecting a specific assy context, that you'd end up with a whole bunch of assy contexts in the top assy.

Instead of the current warning, I'd rather expect no warning on context reuse, and a warning if a new context will be created: "An assy context Context1 already exists, but the assy timeline has been changed since. Do you want to create a new assy context or roll back to the existing context?

What does it mean when there is no referenced geometry under the context in the browser? It means that an edit was done in the child model that uses component positions imposed by the current parent assembly but no geometry from the parent.

I had indeed edited-in-place a component to add a subcomponent, and since I had pressed the pencil instead of choosing the existing context, it had automatically created a new context (which remains empty as no reference geometry was selected, only a component added).

Anyway, all this is resolved as long as I refrain from clicking the pencil icon, and activate a specific design context instead.

Thank you!

Johan

[TrippyLighting]

---

@johan.rutgeerts wrote:

Maybe it would be beneficial to explicitly force the user to choose a context on edit-in-place?

E.g. by presenting a dropdown menu:

---

Excellent suggestion! I'd prefer this one.

[tyler_henderson]

Johan,

These are great suggestions.  We really appreciate the feedback, and you make a lot of good points.

You asked:

---

Anyway, it is clear now, but I still wonder: is there a practical use case where it would be beneficial to create a new context, when there are no changes in the design history? If not (or if this use case is very uncommon) then I'd skip this message and edit the existing context by default.

You are right.  If there are no timeline changes in the assembly, then there is no reason to create new Contexts when you edit-in-place a component.  Today we display the message giving you the option to edit an existing Context or create a new one.  But I agree, it may be better to just force the edit of the existing Context (last one in the timeline for that component) rather than confuse the user with options that aren't really necessary.

A question for you: Today we let you create multiple Contexts for the same component in an assembly.  This is beneficial if you have multiple instances of the same component and they are in different positions in the assembly.  We also expose the Contexts in the assembly timeline so you can drag them around.  One practice is to just keep dragging a Context to the end of the timeline if you need to reference things added to the assembly after the Context was created.  But what if we only allowed one Context per Component per assembly, and we did not expose the Contexts in the assembly timeline (only in the Component's browser)?  The Context would be created on the first edit-in-place, and every subsequent edit-in-place of that component would always edit the Context.  That Context would always be at the end of the assembly timeline (although hidden), so everything in the assembly was always available for reference.  Do you think this would be a better solution (maybe less flexibility but also less complex) than what we have today?

Also one other tip: If you want to see what things are being referenced in a Context, just use the "Reference Objects" command while you are editing-in-place.  It's in the drop-down menu of the edit-in-place banner at the top of the canvas.

Thanks again.  I know we can improve the experience of edit-in-place and Contexts with your help.

Regards,

[kgrunawalt]

Nice idea

[johan.rutgeerts]

---

A question for you: Today we let you create multiple Contexts for the same component in an assembly.  This is beneficial if you have multiple instances of the same component and they are in different positions in the assembly.

This is too abstract for me without an actual example 🙂

We also expose the Contexts in the assembly timeline so you can drag them around.  One practice is to just keep dragging a Context to the end of the timeline if you need to reference things added to the assembly after the Context was created.  But what if we only allowed one Context per Component per assembly, and we did not expose the Contexts in the assembly timeline (only in the Component's browser)?  The Context would be created on the first edit-in-place, and every subsequent edit-in-place of that component would always edit the Context.  That Context would always be at the end of the assembly timeline (although hidden), so everything in the assembly was always available for reference.  Do you think this would be a better solution (maybe less flexibility but also less complex) than what we have today?

---

 That's two questions in one:

1. Is there a need for multiple contexts per component,
2. Is there a need for contexts to be in the timeline .

Re. question 2:

Yes, I think this is a necessity. Check the example assy in attachment of a kinematic chain. If you drag the assy contexts to the end of the top assy timeline, you get circular references, as the geometry of the components is used to define the joints in the top assy. 

Re. question 1:

I didn't try this, so I'm not sure it's correct, but consider following case:

What if, in the example assy, you want to share some geometry from link 3 to link 2.

You need an assy context for link 2 early in the timeline to define its joints, but you also want an assy context for link 2 after link 3 is assembled, so you can share the geometry of link 3.

So yes, this seems also a necessity.

Some other food for thought:

You (currently?) can only define an assy context by editing-in-place a component, and selecting geometry from another component. So both components have to be open at once, in one top assy. Or multiple components, if a certain design assy needs input from several other design assy's.

Furthermore, only one design context can be active at once. This is different from the previous CAD system I come from, where it would have been a 'copy geometry' feature, of which you could have multiple. I'm not saying one is better than the other, but it does imply in Fusion that all external references need to be in one context, if you need them concurrently during your design.

This might have limitations if you're designing very large machines, for which it is not possible to load the full machine (or several subassy's) at once. 

Regards,

Johan

[johan.rutgeerts]

There's something fishy when creating external components in edit-in-place:

Consider a top assy with a subassy component in it.

• Click the pencil icon of the subassy,
• Create a local feature, e.g. a sketch on its YZ plane,
• Exit edit-in-place
  • This was a local edit, no assy context has been created --> OK.
    
    
• Select the radio button of the 'local' context of the subassy,
• Insert a new external component,
• Exit edit-in-place
  • This was a local edit, no assy context has been created --> OK.
    
    
• Click the pencil icon of the subassy,
• Insert a new external component,
• Exit edit-in-place
  • In my opinion, this also was a local edit (no geometry has been referenced), however in this case an empty assy context has been created --> Why?

Adds to the confusion:

If you first define a joint, so that the origin of the subassy is not coincident with that of the top assy, then the new components will be positioned either at the origin of the top assy, or at the origin of the subassy, depending on whether you are editing-in-place or not. So they jump back and forth! Now, I think this is intended behavior, since components float and you are supposed to always constrain them as a rigid group or by defining joints, but still...  Try to explain this to someone new... 🙂

Regards,

Johan

[tyler_henderson]

Johan,

It's clear that you have a good understanding of Assembly Contexts and how to use them.  Everything you said is correct.  So what I'm hearing is we should to keep the current functionality, but rather focus on guiding the user toward editing existing Contexts instead of creating new ones, and make that experience easier and more intuitive.

[tyler_henderson]

---

@johan.rutgeerts wrote:

There's something fishy when creating external components in edit-in-place:

Consider a top assy with a subassy component in it.

• Click the pencil icon of the subassy,
• Create a local feature, e.g. a sketch on its YZ plane,
• Exit edit-in-place
  • This was a local edit, no assy context has been created --> OK.
    
    
• Select the radio button of the 'local' context of the subassy,
• Insert a new external component,
• Exit edit-in-place
  • This was a local edit, no assy context has been created --> OK.
    
    
• Click the pencil icon of the subassy,
• Insert a new external component,
• Exit edit-in-place
  • In my opinion, this also was a local edit (no geometry has been referenced), however in this case an empty assy context has been created --> Why?

---

We create a Context for inserted and new components because their position/orientation is relative to the EIP subassembly's position in the top assembly.  The EIP subassembly could have Moves and/or Joints that position/orient it differently in the top assembly than it is if you opened in its own tab.

If you are in the Local Context, then you are viewing the subassembly in its position/orientation as it would appear in its own tab and no Moves or Joints from the top assembly are considered, therefore a Context is not needed to capture the position/orientation of an inserted component.

---

Adds to the confusion:

If you first define a joint, so that the origin of the subassy is not coincident with that of the top assy, then the new components will be positioned either at the origin of the top assy, or at the origin of the subassy, depending on whether you are editing-in-place or not. So they jump back and forth! Now, I think this is intended behavior, since components float and you are supposed to always constrain them as a rigid group or by defining joints, but still...  Try to explain this to someone new... 🙂

---

Yes, this is exactly right.  The jumping back and forth is due to the fact that the subassembly can be oriented differently in the top assembly than it is in its own tab.  You'll notice that if you try adding a Joint while in EIP, we force you into the Local Context so that you are adding the Joint in the subassembly rather than the top assembly.  This maintains the position/orientation of the components relative to each other within the subassembly, so they don't "jump" relative to each other when you exit EIP.