Interchange doesn't work for Merged Parts?

[akelly]

Using CP4.

TL/DR: You can use an interchange assembly to swap out un-related components of an assembly.  You can't (?) use it to make the same swap in a merged part.

Example

A is a weldment.  I have 2 different versions.  A.ASM for the drawing and A.PRT that has all the components merged together.  A has tabulations (i.e. A-1, A-2, A-3, etc.).  The tabulations can use either components B or C.  B and C are similar, but they were created in different files.

Assembly	Component
A-1	B-1
A-2	B-2
A-3	C-1
A-4	C-2

Working

A.ASM (generic) uses B.PRT (generic).

I made A_INTERCHANGE.ASM with the Interchange sub-type to define reference pairs between parts B.PRT and C.PRT.

A.ASM family table has a column for model B.  For A's instances, it calls out the instances for B.PRT or C.PRT as per above.  The family table verifies successfully.  I've spot-checked several of A's instances and confirmed that it uses the right component (i.e. the interchange assembly is working correctly).

Not working

A.PRT (generic) uses B.PRT via Model --> Get Data --> Merge / Inheritance.

I set up a family table with a Merge Part column for B's feature.  It uses the same instance names as per A.ASM's family table.

Verifying A.PRT's family table shows success, but it's wrong.  A.PRT's instances using B.PRT's instances are correct.  But A.PRT's instances using C.PRT's instances are giving the B.PRT generic. Every A instance that's wrong gives an error in the message area.:

Merge reference part is not replaced by family table.

Observation is that swapping parts in the merged part is not using the knowledge supplied by A_INTERCHANGE assembly..

Work-around

Non-ideal.

In A.PRT, merge both B.PRT and C.PRT.  In the family table, when B's instances are needed, suppress C's feature and vice-versa.

If I'm using A.PRT's instances in a next higher assembly, it'll cause regen failures for some of A.PRT's instances.  If the defined reference was to B's feature, but C is active per the above table, the reference will be missing.

[tbraxton]

The inclusion of a family table with a merge in it leads me to consider this rule.

I can not tell from your description if this may be an issue. Are you sure your model structure is not causing a problem with this constraint for an interchange assembly?

You cannot add another instance of a component if the generic instance is already in the interchange. You cannot add the generic instance of a component if an instance is already in the interchange.

[akelly]

Yes, hard to follow.

A_INTERCHANGE.ASM has only 2 components - the generic of B.PRT and the generic of C.PRT. I noted how B.PRT generic is assembled to A.ASM generic and set up the reference pairs between B and C accordingly.

A.ASM's family table works great.  For A.ASM's instances that call out C.PRT's instances, the interchange assembly is able to replace B generic with the requested instance of C.

A.PRT is a merged part. I placed B.PRT with the same references used to place it in A.ASM.  Since A.ASM's instances were giving the correct BOM structure (i.e. the interchange is working correctly), the expected answer is for all of A.PRT's instances to have the "correct" merged solid geometry.

FYI, toggling the feature from merge to inheritance gave the same result.  For A.PRT's instances, it didn't break A's instances of B.  But it didn't fix the problem of A's instances of C failing to regenerate, either.

[akelly]

Does anyone have any ideas whether an Interchange can swap out merge features?