Edit in place bug?

[ericschimel]

Hi there! So as you may have seen from another post that I've been trying to make a cabinet box and then insert things like doors as "sub assemblies"

I was excited to see the new "edit in place" feature that was just launched so I decided to give it a try.

I think I may have either run into a bug with it, or just some kind of limitation, I'm just not sure which. Here's what I was trying to do: https://drive.google.com/file/d/1kqDIEohcXaMmW5o1w3nvSJUDRYuVuZHg/view?usp=sharing

So what is this, bug or limitation?

[ericschimel]

And a bit of a follow up question:

In this design if I edit my door and save it, then go over to the cabinet and all of the associations I've made with the main assembly break, wouldn't it be the same just to insert the door into the cabinet box design and break the link to the file? I'm sure I'm missing something here though...

I'd much rather this work like a derive, where I could insert the door, joint it and associate the sketch against the main assembly, and push changes forward from the original door to the whole assembly...

[jeff_strater]

@ericschimel - the part I did not catch the first time through (because I was trying to watch a movie at the same time) is at 3:25 in your video, you switch to another open tab that has your door model already open.  So, what is going on is this:  When you do edit in place, make changes, and then return, those changes are propagated to the referencing design, but are not yet saved.  Those in-memory changes will be saved (to both the parent and child) when you save the parent.  But, in your video, you a) did not save, and b) switched to a tab with an already-open version of the doors, which did not reflect the edits you made in place.  When you punched the hole in the door in that separate tab, saved, and did get latest in the referencing design, you essentially over-wrote all the in-place changes that you made.  Fusion does not support making two sets of changes to the same design and merging the result, which is what you seem to expect to happen.

The general recommendation would be:  Don't try to mix in-context and out-of context edits at the same time.  In this case, if you want a hole in your door, a) do it in place, or b) save the in-place edits, re-open the door in a separate tab, then make the hole.  Either of those workflows will work.

[kgrunawalt]

Jeff beat me to this, so this is repetitive, but always good to have a couple takes!

Hi. What is happening here isn't a bug but it is something Fusion could handle better. In the video you are editing the doors subassembly in two tabs: first via EIP, second directly. These edits don't get merged when you "get latest".

You need to first save your changes made during EIP and then open the doors subassembly directly to work with the version that was saved with the EIP context. Instead, the "get latest" replaced your unsaved EIP changes.

So it is not a bug and you can avoid this by saving EIP changes before opening the subassembly elsewhere, but we know we can make this easier to manage and are working on that. Another similar example: two people opening and editing the same model at the same time will create two separate versions when they save. These become versions n+1, n+2. Version n+2 does not include changes in n+1.

Thanks for the very clear video.

[kgrunawalt]

This is a note on the "synchronize" workflow you mention in the video. As you note, Fusion requires an explicit synchronization to update xrefs with contexts when the parent assembly computes and changes what is referenced by the xrefs. You were hoping for an automatic update when you made the change to the parent.

An automatic update has a couple potential issues. Here is the main one. Bear with me on this -- it is an important point on EIP but a little mind-bending. Unlike "local" components that evolve in the parent timeline, the xref is inserted fully built into the parent. Now with EIP, changes to the parent assembly later in the timeline can cause changes to the xref which is inserted earlier in the timeline. This could cause a cycle. We allow that and have done a lot to avoid having a context become out-of-sync unnecessarily. But this makes updating the xref automatically a bit tricker.

Fusion could potentially allow some automatic updating, but we want to be careful to make it clear when an xref is being changed by the parent changes (during explicit sync only) and also control any potential change cycle with an explicit sync.

[ericschimel]

Thanks to you folks I got it figured out... mostly:

https://drive.google.com/file/d/12nUNUXOLt9hu4NbpBieryvtqlb9kLly2/view?usp=sharing

The big question I have now is around the "contexts" 

They seem to be all linked together, and that's not that I thought would happen. My video explains it much better than I can type it out.

But again, thanks so much for your help so far!

[tamirlance]

I have the same issue.  My EIP features don't get assigned to the new context and are instead saved to the default context which then propagates across other instances.  Is that a bug?  Or am I not using EIP correctly?

[kgrunawalt]

Context-based modeling adds features to same timeline. Contexts don’t define alternative designs. A context really is just a set of positions imposed in the xref child components and a set of reference geometry copied into the xref associatively. These positions and references come from the parent assembly during EIP. They really are a “context” for modeling.

A feature created while in EIP may or may not use any positions or references from the parent assembly. If it does, it must be edited when context is active. Fusion auto-activates the context on edit. That last hole didn’t really use the parent at all.

Hope that helps!

K

[tamirlance]

I just came to that realization - thanks for confirming.  Maybe what I really wanted were some derived components with different EIP contexts enabled or disabled.  I come from Solidworks where I use configurations and just jumped to the conclusion that EIP was doing this when in fact its really just doing what it says it does which is keeping track of all the contexts in which edits were made.  What tripped me up was the "default" context.  Is there a reason this is needed?  It seems like the default context doesn't need to be listed specifically unless its needed for programatic reasons since something has to be selected at all times (i.e. you can't unselect a radio button by clicking on it - you can only activate another one)