Changing nested family types breaks constraint

[trevor.clarkM88RA]

We use nested/shared doors in window families for storefront, the door is locked by a strong reference plane to a reference plane at the face of the storefront frame. After doing an update to the door family, I've been reload it into our window families, but switching away from the flush door type unconstrained the door, both within the family editor and in the project. However, opening the window families, deleting the flush door type, creating the flush type again with the same values as before fixes issues - the flush type can be used without coming unconstrained. The family is upgraded from 2022 to 2024, but even audited families still have the issue.

I'm at a loss as to why this would happen to avoid it or corrected it - I'd really like to figure out why this is occurring as I have over a hundred variations to manage.

[Sleepingfish_Kuo]

Try setting the nested family's Is Reference parameter to a named reference instead.

[trevor.clarkM88RA]

Tried out the Center reference type instead of Strong Reference type, no luck. Attached is an updated family with the revised reference plane in the nested family.

[trevor.clarkM88RA]

In updating the various family versions our firm keeps, I'm noticing that any time the shared/nested family is reloaded in a host family, the constraints locking it will break when the type is switched regardless of the type. If you go ahead and break the constraints, delete whatever type was, and remake the type with the exact same name and parameter values, it will function correctly. In the previously attached family, the door will break switching to and from the "Flush #F" type, but that's only because the family was set to that when it was reloaded. If the nested family was set to type "Full Lite #FG" before the update, that family type will break instead. This type of break is consistent regardless of using Reload From, Load into Project, or Load Family. It doesn't seem to matter if parameters are overridden or not.

Seems like a bug? Or is there a deeper issue with the construction of the family? It's really time consuming to deal with when dealing with sizable family library, our firm uses a Family Type parameter which seems to be something that can't be accessed via API preventing automation of the fix.

[SteveKStafford · Accepted solution]

Nested families need to be constrained in the host family consistent with how they are designed to flex internally. For example, if a family is designed to flex from the center outward equally on either side of its center, then that family should be constrained and adjusted based on its center, not its sides within the host family.

[ToanDN]

Try this one.

[trevor.clarkM88RA]

It works! But do you know what was incorrectly configured with the original family or how it was constrained in the host family? I'd like to take this lesson forward to all hundred-ish families so I don't have to update them one-by-one again.

[ToanDN · Accepted solution]

---

@trevor.clarkM88RA wrote:

It works! But do you know what was incorrectly configured with the original family or how it was constrained in the host family? I'd like to take this lesson forward to all hundred-ish families so I don't have to update them one-by-one again.

---

For the nested door family: 

- set the center ref plane from Not a reference to Center

- set the left ref plane from Weak reference to Left

For the host family:

- removed the constraints from the nested door's left and right from reference planes of the host family

- constrained the center of the door to the center reference plane of the host family