Reporting Parameter for stair pitch

[IMCornish]

Is it possible to create a Stair Tag with the pitch reported?  I have a tag which includes the number and height of rises as well as the size of treads but I would like to include the pitch also.  Obviously this would use the dimensions of the rise and tread in the formula Tan X = Rise/Tread, but how do I create this in a tag?  I have looked at using a Reporting Parameter but every time I read the Wikihelp paragraph on them my eyes just glaze over as I cannot follow it at all but it does mention formulas....

Can anyone help please? 

[rosskirby]

This is kind of related to the room occupant load tags question, in that the answer is no, because you cannot currently have a calculated value in tags.  It would be great if you could, but unless something has changed very recently, this is still not possible.

Just to satisfy my own curiosity, why do you need to calculate the stair pitch?

[IMCornish]

I want both a quick check and also a label for a stair in plan view on a UK Building Regulations Application drawing to show compliance with Approved Document K of the Regulations. Will save time and kill two birds with one stone.

[rosskirby]

Oh, gotcha.  As far as I know, there isn't an automatic way to pull that into a tag, since it would be a calculated value.

[IMCornish]

I assume that there is also no way to put a 'General Annotation' family into a Tag and use that to calculate the pitch?  I have tried this and although you can insert default parameters into the tag family which are linked to instance parameters in the annotation family, they do not appear as editable attributes in the tag once selected in a project environment.  I created an annotation family with Stair Tread and Stair Rise parameters then used these in a formula for the value of a shared parameter 'Pitch' which I used as a Label in the annotation.  Bringing this into the tag family I created similar Rise and Tread instance parameters in the tag and linked them to those in the annotation, thinking that they would appear in the tag, when used in a project, for manual editing where I could enter the actual values.  But nothing doing. Very frustrating.

This brings another question to mind though, which is, having brought the 'Generic Annotation' into the tag family and selected it, I note that there is the possibility to link it to a parameter (Label) rather like a dimension.  What is that all about and is there any future in investigating that as a possibility?

Thanks for your help thus far.

[rosskirby]

Not as far as I know, no.  It would still fall under the calculated value prohibition.  Nesting annotation within other annotation is always risky business, because it's hard to understand, and therefore predict, the behavior (at least for me).  The only time I use a nested generic annotation is when I want to have a symbol as part of another family (like a duplex outlet, or a camera, or something where the represenation of the family needs to be something that looks nothing like the family itself).

I'd have to experiment with the daisy-chained parameters with the annotation families, since I don't build annotation families anymore.  I'm not so sure that it would work, however, since tags are kind of a special beast.  When you're working with a non-annotation family, the parameters you're linking are hosted in the family itself, and aren't dependant upon what happens to that family when it's in the model.  Annotation families, however, are "dumb" (for lack of a better term) until they end up in a model, and are linked (by tagging) a particular family.  That leads me to believe that the daisy-chained parameters wouldn't work, but I'd love to be proved wrong, so have at it, and let us know what you find.

Good luck!

[Chris.Aquino]

While calculated values cannot be shown in tags at this time, one workaround you want to try is to add a shared parameter to the stairs, calculate the value in a schedule, enter the value into the shared parameter, then tag the shared parameter.

We understand that this may not be the preferred workflow, but it's one we have seen others utilize in the past.

[IMCornish]

Will try this and get back though I am wondering how to get a schedule value into the shared parameter unless you mean manualy?

[rosskirby]

It would be manual.  The only reason for the schedule is to have the value automatically calculated somewhere that you can reference.  Then you manually enter that data in the tag.  I've tried this method before, and it's really only been beneficial to me when it was either a complicated calculation that I didn't want to do manually, or when it was a calculated value that was going to placed in multiple instances and was likely to change over the course of the project.