Doors - placing fire rating coloured "dots" on doors

Hello Hivemind,

I’m looking for an option to place coloured Dots on door fire rating drawings.

We are using a shared instance parameter for the door’s fire rating. Our studio standard is to place a coloured dot over the door with a key to the side to indicated the fire rating. The idea is the “dots” would pick up on the door instance parameter fire rating.
Green 30, Blue 60, Red, 120, Magenta 240.

Fire rating

I’m sure this could be done with a generic family, I’m just not sure how.

Thanks in advance.

Hello @craig_SW
I think you can use a Door Tag for this.
Or you can create a Family with the four types of colored dots.
If the origin of your Doors family is in the standard position, use Element.Location from the Doors and place the Family Types there.
Take the Projects origin in consideration.

Hi,

another option: in our office we had this dot embedded within door family. It’s visibility was set to display only in coarse drawings - that’s the detail level of our fire protection plans. If all the other drawings are medium/fine than this works. Otherwise I would go for the tag solution, as Marcel advises.

Hi.

Thanks. The problem with embedding is we do very big projects, so adding to the doors may become a bit of a sisyphean task.

I tried creating a tag, but Revit still doesn’t allow shared parameters to be added to filled regions…

How is your tag built? I think there should be four regions inside it (each with different colour), controlled by visibility parameters. And those visibility parameters can be driven by your shared parameter with fire rating.

1 Like

Hi, that looks like a good plan. How would I drive the visibility parameter with the shared parameter, it only allows a “yes/No”? A formula?

Thanks!

exacltly, a formula —> if your_shared_parameter == 30, then true, else false

this might be helpful:
https://revitforum.org/showthread.php/1046-Revit-Formulas-for-quot-everyday-quot-usage

if the true/false is not working try 1 and 0 values…

Click the little button right next to the Yes/No option i guess

Whatever you choose, the “link” between the door and the Tag is artifical at all times. A tag cannot change it’s appearence based on the value it reads.

So for a Dynamo script there is no difference between reading the FireRating value and pushing that into the Tag or just making a Tag with 4 types (or 4 different Tags) and have your script pick the appropriate one based on the FireRating value read from the door. The Dictionary functions are great here.

This way you automate the placement and choosing the right type in 1 go.

Well, if the tag has four circles inside it actually can change it’s appearance based on the parameter…i believe.
So I think solving it without Dynamo (plain Revit) would be more future-proof.

1 Like

Hi, I feel like I’m getting close but I’m not that good with formulars… I’ve created a Yes/No Shared Parameter with the FR30 FR60 etc. And added to each filled region as Type parameters. But I can’t add a formula that work in the family and there’s no “mapping” once I load it in to the test project I’m using. The doors in the test project all have Shared Parameter “Fire Rating_Instance”…

Any ideas, I really appreciate the help, it feels really close to resolving.

Thanks!

Hi,

I am very sorry, but it seems I have misled you. What I described won’t work in the annotation family, only in model ones. It seems within annotation families it is not possible to use shared parameters, except for labels (just checked).
Unless it is possible on newer Revit versions…

So I guess Bjorn was right.

1 Like

Hi Bjorn,

It looks like this is the best option but I haven’t a clue where to start. Do you know of any examples I can retro-engineer?

Thanks!

Thanks anyway! It did seem the most sensible solution but “Revit Says No”. It’s a little bizarre this isn’t an option…

1 Like

Hi @craig_SW,

do you still need help for this one? i think it is doable with a simple script.

-biboy

1 Like

I would use four types of the same tag family with a manual visibility control for each in the family - no formulas needed.

Place the tag types via door types manually by adding a filter to each view to hide all doors except the FR ones. Then tag all in view and change the type of the tag once done. Do this for all 5 FR values (or 10 FR values - though that doesn’t scale as well). Easy enough to push through.

To do via Dynamo graph: tag all doors, get the tag elements in the view, gather each tag’s host, quarry the FR from the host, group the tags by the FR value, and set the tag type based on the associated grouping, and deleting the non-tagged items. I prefer this method over the ‘create tags’ as the same graph can be used to update the tags as designs evolve.

If you would prefer to create the tags: get all doors in the view, pull each door’s FR value, group the doors by FR value, get the associated tag for each FR value, we try the location of the door, tag the doors.

1 Like

Hi, yes any help out be appreciated.

I’ve taken an script from any similar thread and manipulated it. It’s “almost there”, it will place the tags but there are problems. See below


Hi, thanks for the reply.

This is what I’m trying to achieve with the script I posted.

Can you post the files (Revit and Dynamo)? If you can’t post here use dropbox, OneDrive, box, google drive, wetransfer, etc…

WIth out the files to help more directly we’re stuck rebuilding your Revit model, then the shared parameters, then the tag family including all types, then the dyn… all of that adds up to a lot of time which many of us don’t have available.

As a tip in the meantime: Instead of just filtering, I recommend you use a List.GroupByKey node where the list is all of the doors, and the key is the fire rating value.

GroupByKey is certainly 1 way of doing it.

This could also get you started by getting the right Tag Type for each Door.

You will need something to filter out the Doors with a non-compatible input and I’m unsure you can actually Tag this way. The OOTB nodes seem to use the Tag By Category function where you cannot control the Type of Tag, but it takes it from your preference Tag lists. Some of the package Nodes I tried for this kind of stuff also were not reliable in a variety of scenario’s.

I’m getting a preference for Tagging all the Doors in the relevant FR plans with a Default Tag and just the TaggAll command and then finding them and switching them through a script later.

1 Like