I do see that Revit door families have Fire Rating as a Built-in Type Parameter, the value off which needs to be entered manually. I have read threads which bemoan the need for duplicating the door families to create new fire rated door types, and agree that this would create chaos.
Here is my question. Is there a modification that we can add to the door families that allow them to pick up the fire rating parameters from the wall?
Gelöst! Gehe zur Lösung
Gelöst von Sahay_R. Gehe zur Lösung
Gelöst von David_W_Koch. Gehe zur Lösung
Gelöst von ToanDN. Gehe zur Lösung
Aaarrrgggghhhhh. Any non-Dynamo idiot-friendly solutions?
Of course, the other (primitive) way out would be to create a folder of Fire Rated Doors in the library.
How would Dynamo work this out? My IT guys have given me the impression that managing Dynamo over our network would be very very painful.
Your IT folk know that Dynamo gets installed with Revit right? I think they are just concerned of how to support it.
Yes, that is their concern as to how it will behave over the network.
@Sahay_R wrote:
Aaarrrgggghhhhh. Any non-Dynamo idiot-friendly solutions?
Of course, the other (primitive) way out would be to create a folder of Fire Rated Doors in the library.
How would Dynamo work this out? My IT guys have given me the impression that managing Dynamo over our network would be very very painful.
Dynamo can pick up the Fire Rating value from host walls and write them to a text parameter of the doors. With that said, any time a wall fire rating changes you need to run the script again to update the door information.
IMHO not every team member needs to know or use Dynamo. Assign the task to one person who is comfortable with creating scripts and regularly running them.
A non-dynamo approach would be create dedicated views for checking, with view filter to show walls and doors of different ratings in different color codes. When you see the colors don't match then go fix them. Color blind personnel needs not apply.
It doesn't do anything to the network...it interfaces with the local Revit file just as if someone was working on a normal project.
A little late the to party here, but here is my 2 cents:
Rather than have parallel sets of types (or families) for every fire rating possible for each door configuration, we use an instance parameter for the rating. That does not, of course, solve the manual entry problem. Perhaps building codes in your area vary, but the codes we deal with do not have a 1:1 relationship between Wall and Door ratings that would allow a for a relatively simple program/Dynamo graph to translate a Wall rating into a Door rating.
As cool as computers can be, sometimes it is still more effective to have a human being capable of thinking while modeling to do certain things. Setting up a view with filters to color-code the various types of fire and smoke rated Walls as well as the ratings on openings in those Walls (including Doors) can help identify any Doors that got missed, or had the incorrect rating assigned.
Here in Europe walls and doors have distinct fire classification codes and not necessarily matching fire insulation requirements. Doors have more complex codes than walls: for instance they can be self closing, smoke sealed, etc.
It's technically possible to copy the parameter value from the host to the door via Revit API with a simple plugin, or with Dynamo. It's seems also possible to have event notifications to run in the background and update the door parameter whenever a wall classification is changed. Might be other possibilities with A360 and Forge, but that I unfortunately have no experience. I remember that Jeremy had a project with a Mongo database to deal with fire classification for instance.
Luis Santos
archi systems as
In my mind two thirds of the value would be: alerting the plan checker or production person to if the door needs to be rated, and what level of rating. In a door schedule of dozens or hundreds of doors that are not rated, that would be great, even if there were no calculated value that calls out the rating of the door. Still, I would think that given the IBC chart for door ratings, a minimum value could be assigned to the door via a calculated value, as long as the wall type had fire and smoke enclosure info.
Wow, this old thread really has come back to life! To segway on to the thoughts of @David_W_Koch and @Anonymous, an instance text parameter added to door families, associated with a global parameter in the project. This should bring the required information fairly quickly and painlessly to the schedule. Of course, this will not 'talk' to the walls and it will require human intervention and interpretation.
Thx Rina - We have too many doors to do this retroactively, but I'll suggest it for next time!
@rsahayUZMK9 wrote:
Any non-Dynamo idiot-friendly solutions?
Non-Dynamo solution:
Create a view template with filters that change the color/cut fill of fire rated walls. Assign that view template to a non-document view. At the same time also create a filter that changes the cut of doors to match the fire rating. Go through and find the doors that are not colored and change them to a fire rated type per your parameters.
It's purely visual using this method, but I use it quite a bit, as I am a dynamo noob.
@Anonymous wrote:
A little late the to party here, but here is my 2 cents:
Rather than have parallel sets of types (or families) for every fire rating possible for each door configuration, we use an instance parameter for the rating. That does not, of course, solve the manual entry problem. Perhaps building codes in your area vary, but the codes we deal with do not have a 1:1 relationship between Wall and Door ratings that would allow a for a relatively simple program/Dynamo graph to translate a Wall rating into a Door rating.
As cool as computers can be, sometimes it is still more effective to have a human being capable of thinking while modeling to do certain things. Setting up a view with filters to color-code the various types of fire and smoke rated Walls as well as the ratings on openings in those Walls (including Doors) can help identify any Doors that got missed, or had the incorrect rating assigned.
I deal with this too. For example: one hour corridor walls which require 20 minute doors, and one hour occupancy separation walls which require 45 minute doors. Those are two different wall types (not a must, they can be one type), each has two fire rating parameters, one says 1-hour for the wall itself, and another says 20 or 45 minute, respectively, for the opening. Dynamo can bring that 2nd opening fire rating parameter to the doors' fire rating parameter semi-automatically.
oops....I didn't notice that @David_W_Koch said the same thing I recommended already.
....except me - VIVE LA DIFFERENCE!
Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.