Annotation for Showing the setback of a plane relative to another plane

[libengan]

I'm working on interior elevations.  Sometimes cabinets are projected or setback from one another, but it can be difficult to tell in elevation.  I would like to have an annotation family that references two planes and shows the setback of one plane to another.  I can do this with a generic annotation family and a custom instance parameter input, but is there a way to create a smart annotation that reads the offset in geometry and will get auto-updated if the planes move?

[RDAOU]

---

@mhiserZFHXS wrote:

1) "Dumb" is a pretty universally accepted term for tags/annotations that aren't linked to any parameters, as OP has been doing. I'm not referring to what you're suggesting.

2) I understand what you've been saying the whole time. My point was that implementing your idea would be extremely time consuming while adding little additional functionality. For one, OP has explicitly stated multiple times that while cabinets were their example, it is not the only use they are looking for. But ignoring that, all of these parameters would need to be added to EVERY casework family they have. And even then, you need to manually drag all of those reference planes to the adjacent elements for it to work properly. And looking at OPs posted drawings, this isn't something that would be in a single tag type. They have the offset tagged at each offset point. Meaning the appropriate type would need to be selected for each of those offset points, leaving room for error.

Sure, you can lock it so if things are nudged, it still reads correctly. I suppose that's one step above a dumb annotation, but just one.

OP was wanting a way to be able to tag the offset distance between any elements, and the answer to that is that it is not possible. I think it could be a handy feature to be implemented though.

---

I read your reply twice just to make sure that I did not misunderstand it but it quite clear. According to you locking a family to an adjacent component or a plane is one step above dumb, while tagging a nonexistent property or parameter is seen as a more practical and intuitive solution. Simultaneously you contradict that when you state that dumb is a universal definition applicable to annotations which are not live linked to the model.

Then you elaborate further to state that modeling components to fulfill their intended purpose and having to foresight to plan how components should be modeled based on the general Information Requirements,    incorporating parameters to track setbacks and offsets is unnecessary work and counterproductive. What I am not sure about though is that how does your statement tally with that of the OP where he/she states that in there office they are known for stretching the limits way beyond  what is normal and typical

Nonetheless, thank you. I will take that into account in future discussion.

[mhiserZFHXS]

Listen, your idea works. I'm not saying it doesn't. It will result in a tag that is reading a parameter. If OP feels its worth their time, then great. 

But to me, its still an artificial tag, which is why it only has slightly more utility than a dumb annotation. It is not reading a true offset from the surface of one object to another. It requires multiple steps to be used correctly, both in setup, but also in actual placement of the family and tags. Multiple steps means multiple chances for error, especially if OP is in a large firm with lots of people using this. Having a dumb annotation that everyone knows needs to be updated whenever the model changes feels safer than have a "smart" tag that still requires multiple layers setup and maintenance to work correctly. And again, this is only usable in non-system families. It has to be able to added as a parameter, with all of the reference planes, to a family.

It just feels like a "this can technically be done" exercise more than something that can be practically used without error.