Nested Generic Annotation changing Family Type parameter breaks constraints

[GPnmulder]

I have nested generic annotations controlled by a family type parameter in an unhosted family (level based). The generic annotation(s) are also constrained by two ref planes that allow for movement of the generic annotation in X and Y directions. Changing generic annotations via the Family Type parameter breaks the constraints. Interestingly, there are conditions under which it doesn't that I can't figure out.

In the test family (attached):

1. Switching between 'GenAnno_Device_Square_Foot' and 'GenAnno_Device_Square_NoFoot' does not cause an issue
2. Switching between the 3 types in 'GenAnno_Device_Square' does not cause an issue
3. Switching to 'GenAnno_Device_Circle' causes the issue
4. Switching between 1, 2, or 3 causes the issue

All the generic annotation families are basically the same family but renamed.

Scouring the internet leads me to think it is a limitation of generic annotations if they are constrained. Some alternatives I've considered are:

1. Build as many types as are needed in a single generic annotation family to avoid having the Family Types parameter change families
2. Nest the generic annotation families into detail item families which are then nested into the family. I need the symbol to be annotative and detail item families do not seem to have the same issues breaking constraints when being switched via the Family Types parameter

Any help appreciated.

[GPnmulder]

I'm trying to upload two sample families but I am not able to?...

[barthbradley]

Well that's a bummer.  Having your family would make troubleshooting a whole lot easier.  

@Viveka_CD: any suggestions how the OP can post his file? 

[GPnmulder]

Uploading families doesn't appear to be working...let's try a link:

Family Types Generic Annotation with Constraints

[FAIR59]

The (horizontal) reference planes have different Id values in the nested families. It might be that 's the source of the problem. I did a quick test, creating 2 families using the standard Generic Annotation template, and could change between those without problem.

[GPnmulder]

Thanks for the response! When you say ID values I assume you mean the element IDs? Sounds promising but I don't understand. Because even using 'save as' the element ID of a ref plane will change; the only way to keep the element ID of a ref plane would be to make all types within a single family. No? Am I misunderstanding?

I have tested using 'save as' and can confirm it works...and sometimes it doesn't. When it doesn't is what I can't figure out. For example, this is what I just tested:

1. Took a 'working' GA, saved as '_Test', loaded into family; constraints and family type parameter work as expected
2. Took that same '_Test' family and saved as '_Test2', loaded into family; selecting it in the family type parameter breaks the constraints

I can't figure out the logic/pattern, if there is one. If you try enough nested GAs it seems it will eventually break the constraints. I'll keep testing.

[GPnmulder]

So it seems that one trigger is removing elements (lines) from the GA and adding new/different ones. Interestingly, updating/overwriting a GA family definition that already exists in the family also does not work. It must be removed and reloaded, even if the 'symbol' is the same. This essentially forces you to make all necessary GAs from a single starting GA in that family.

I'm beginning to think this is a software problem. It is definitely too unpredictable to use this workflow as is. I think I'll see what the factory says.

[barthbradley]

you know, the odd thing is that the family works perfectly fine in a project. Were you aware of that?  

[GPnmulder]

Yes, to a point. It allows you to change family types and won't throw an error, and you can even change the family type parameter in the type properties. But for those GAs that break the constraints in the family editor, the symbol controls in X and Y just don't work for that type/family type GA in the project.

[barthbradley]

I messed with your family a bit this morning and it's a bit of a head-scratcher.  Mostly because I don't understand what intelligence you are trying to build into the family.  Are you trying to build grips into it that you can grab a hold of in the Project?   If this is it, maybe make the Annos static (pinned) and flex the grip reference planes. Do you get the concept?

[GPnmulder]

The grips are there and do work in the project, allowing the ability to move a symbol in 4 directions. The reason for this functionality is that due to our nature of work, we may have several families either stacked vertically or horizontally in 3D or elevation, but in plan (issued sheets), industry convention is to show symbols. This allows for moving the symbol without moving the family origin.

What I'm trying to achieve is consistency for the end user. If the family type is changed, or a new one created, the expectation would be that regardless of what GA is selected in the family type parameter, it would respond to the X and Y controls.

I should add that I have the above workflow in place for our current families. The difference is that now I am attempting to consolidate/reduce the number of individual families in our library. Hence the family type parameter for the GAs. I am also using family type parameters for nested families showing the actual geometry but I removed those in the sample family to avoid confusion.

Hope that helps. Thank you for your help. I have submitted a ticket with Autodesk. 

[barthbradley]

I get it. Thanks for clarifying. So, is this the first time you've labeled the Annos to a Family Type Parameter?  I can't think a time I have ever done that.  Still, it seems to work with all but one Anno.  Interesting puzzler.  Please share back with us what Autodesk says. 

Fun Thread.  

[Viveka_CD]

Thanks @barthbradley

@GPnmulder Can you please try zipping the file and reattaching?

Regards,

[GPnmulder]

@barthbradley  This is not the first time I've controlled GAs via family type parameter but it is the first time I've used the family type parameter AND constrained them to ref planes.

@Viveka_CD Zipping the files seems to work.

[Viveka_CD]

Thanks for confirming @GPnmulder

I'll take a look at your files!

Regards,

[ToanDN]

You just need one more level of nesting. Nest all of your symbols into one Generic Anno family, same location. Establish a Family Type label there to control Types. Then nest this family into your model family, constrain it, setup the Family Type label exactly like you did. Now the constraints should yield no errors because they don't need to switch among reference planes of different families.

[FAIR59 · Accepted solution]

A possible work around, that avoids constraining the refplanes of the nested family:

• draw a horizontal and a vertical model line on the ref-Plane ( non Visible and line style <Invisible Lines> )
• place the nested family origin on the intersection of the 2 lines.
• Make a group of the 2 lines and the nested family.
• constrain the lines to the [Symboll Offset from Wall] ref.plane and the [Egress Arrow LR] ref.plane.

[GPnmulder]

@FAIR59 That indeed works...and just might be the route I choose.

@ToanDN Your solution also makes sense and is a good option.

It seems then that the ref planes of GAs get treated differently when constrained compared to other family types. I haven't done extensive testing to confirm but don't recall having this issue with non-GA family types. Compared to the other family with nested GAs in detail item families there was not an issue. I'll post back if the factory provides any insight.

Thanks everyone!

[GPnmulder]

The factory reports that this is a logged issue and under review to be addressed. This link was provided to track updates and current possible workaround: Constraints are not satisfied when setting a family parameter to a nested family type

I personally could not get their solution to work. Re-creating all GAs and host families from default rft also works 🙂 I opted to continue with grouping the GA and ref line constrained to ref plane.

[allison_burkett_Td3]

I was currently experiencing this same issue in Revit 2025 and the invisible line + grouping workaround worked for me. Thank you!