Fire escape path running dimension

[tomnewsom]

I have a feeling that this would require dedicated tools, but I'm happy to figure out a workaround.

We have to do a lot of fire strategy drawings for office fitouts, which require measuring total escape distances. These measurements are typically a multi-segmented line running from the farthest corner to the esape door, and have to be calculated manually in autocad. Is there any way to automate this in Revit? I've been experimenting with dimensions etc, but I don't think they have the flexibility.

[bowlingbrad]

You could use a detail component with a length parameter (like an arrow). Stretch them end-to-end and then schedule them. You would need an instance parameter for the length and maybe a type parameter for the exit path. This way each path could be scheduled separately. HTH

[david.kingham]

To quickly check a distance use the tape measure tool with chain checked and this will give you a running total, for something that stays on the drawing...i'm not sure...

[Elmo]

With Revit 9 you could use the new 2 pick family to do what you require.

[tomnewsom]

You could use a detail component with a length parameter (like an arrow). Stretch them end-to-end and then schedule them. You would need an instance parameter for the length and maybe a type parameter for the exit path. This way each path could be scheduled separately. HTH

This sounds like a decent way forward. If I use shared paramaters, I should be able to tag one of the lines and have the calculated total length in the tag. I think...

Will go and have a play - thanks for the tips!
I will report my finding...

-

Works so far. Having trouble getting them to schedule though.

I've got two shared paramaters for each detail object - Segment Length (Length, which is set to "=Length in the family editor) and Route ID (Text)

I can get those parameters up in the schedule creation process, but only through Multi-Category, as there doesn't seem to be a 'Detail Component' Category availble for scheduling.

From Schedule Properties, I go through "Add parameter" - "Shared parameter" and select one of my new shared params. Hit OK, and get back to the properties scree. I do the same for my other new parameter.

I filter by "Route ID" - "parameter exists" and leave everything else default. The schedule comes out blank :(

Is there maybe a limitation to scheduling detail components?

PS: I'd post up the RFA, but everything's got the name of the client and project all over it, which is top-secret :(

[bowlingbrad]

oops! I think I should have said specialty equipment component.

Here's a project with the info working. Yes, uses shared parameters, remember to check the "Calculated Totals" checkbox for the length parameter in the formatting tab of the schedule.

[tomnewsom]

You star!

Just got to convert that to metric and I'm laughing. Cheers!

[blads]

:cool: very nice... thanks a bunch

[dhurtubise]

Just to improve, make the arrow an instance visibility parameter, so you can turn it off for the whole path except the last one :-)

[tomnewsom]

Although it is a shame that there's no function for 2-pick placement :(
It was just like drawing lines when I made an Annotation family...

Maybe having an angle parameter would help. Would I get grips to change the angle?
*goes to play*

[dbaldacchino]

Well you could use the line based generic model family then. You would be able to add a chain of objects instead of one by one. Then set instance visibility parameters for the start line and the end line. Nice solution though :)

[inouizi]

oops! I think I should have said specialty equipment component.

Here's a project with the info working. Yes, uses shared parameters, remember to check the "Calculated Totals" checkbox for the length parameter in the formatting tab of the schedule.

How would this work if I wanted the lines to show on elevations and 3D views and didn't need the arrows?

[Steve_Stafford]

I posted an example after showing it at AU2006. I've attached the project file and here's the first ARTICLE (http://revitoped.blogspot.com/2007/01/egress-path.html) and the FOLLOWUP (http://revitoped.blogspot.com/2007/01/egress-re-gress.html).

[ageorgis]

I posted an example after showing it at AU2006. I've attached the project file and here's the first ARTICLE (http://revitoped.blogspot.com/2007/01/egress-path.html) and the FOLLOWUP (http://revitoped.blogspot.com/2007/01/egress-re-gress.html).
Steve,
what is the best method in specifying total distance not to exceed for the total length say 80 ft

regards,

[Steve_Stafford]

That is the tail wagging the dog I'm afraid. The family makes it easier to confirm and document what we already designed on purpose. The egress schedule will make it easier to catch excessive distances but exiting can't really effectively be designed back into the project if it was overlooked early on. Whenever I've been involved in a project that didn't consider exiting early enough we ended up with some pretty unfortunate solutions, thankfully that's only been a couple times.

I suppose you could use them as you do early design but you still have to evaluate the path your walls are defining to determine whether the distance is excessive.

I few years ago I built a family based on a friend's technique for studying exit travel in a broad brush manner but I can't find it now, probably in a previous employer's folder :wink:. It worked on the principle of a large square that represent a fraction of the total allowable distance. The square centered on a exit door and you put one on each exit. Wherever these squares didn't overlap, your path of travel was too long. Seemed to work pretty well for any path that didn't reverse direction or have more than two changes in direction.

Forgetting my posted example you could make a similar family that isn't line based that can have a predefined exiting path shape such as an "L" or "Z" that won't let you make the total length get greater than 80 feet. You could place this family in your project early along in the design phase and create corridors around it. Seems a bit restrictive from a design sense to me though. Just a thought.

[SkiSouth]

Steve - thanks for posting this. Any tool along these lines helps...

[Andrew Dobson]

These look really useful, but is there a way to make them work across multiple floors?

I.e. from a room the the escape stair, then down and to the exit door?

[inouizi]

I posted an example after showing it at AU2006. I've attached the project file and here's the first ARTICLE (http://revitoped.blogspot.com/2007/01/egress-path.html) and the FOLLOWUP (http://revitoped.blogspot.com/2007/01/egress-re-gress.html).

Hey Steve,
Thanks a lot of for the post, my issue is that I am not looking for egress path families really, the thread got carried in that direction because we started talking about line based families, what am trying to do is use model lines in my project as reveals and I want to be able to schedule those reveals, now I applied the same concept as the egress family you have except I applied it to a wall, but my problem now is when I import that family to my project I can only use it for vertical reveals, I couldn't rotate it in elevation, any thoughts?
Thanks.
IN.

[dbaldacchino]

If you do a line based family, you should be able to pick your wall face as your workplane. Now sketch on the wall in any direction. You were probably sketching using a level as your workplane. In that case, you can only rotate on the workplane that the family was sketched in, fitting your description of "horizontal" only.

[Steve_Stafford]

These look really useful, but is there a way to make them work across multiple floors?

I.e. from a room the the escape stair, then down and to the exit door?You could place them in various places in the model and as long as they all share the same comment a schedule would group them and give you a total.

The problem is workflow. Are you expecting the line to measure the diagonal distance down the stair and then horizontally around a landing and down again? What does the code say about such calculations where you are? Ideally the factory could develop tools to calculate exiting data but they'd need a lot of data to create something. A stair for example could or should tell us the total run distance so we could include it in a report easily. But that is only part of the equation.

[inouizi]

If you do a line based family, you should be able to pick your wall face as your workplane. Now sketch on the wall in any direction. You were probably sketching using a level as your workplane. In that case, you can only rotate on the workplane that the family was sketched in, fitting your description of "horizontal" only.
Please refer to this thread http://forums.augi.com/showthread.php?t=58131
I attached the families I created, since I couldn't rotate the original family that I called vertical, I created another one and called it horizontal, now the horizontal one doesn't resize the way the vertical one does when you inset it into a project.
Thanks for your help!
IN.

[dbaldacchino]

You could place them in various places in the model and as long as they all share the same comment a schedule would group them and give you a total.

The problem is workflow. Are you expecting the line to measure the diagonal distance down the stair and then horizontally around a landing and down again? What does the code say about such calculations where you are? Ideally the factory could develop tools to calculate exiting data but they'd need a lot of data to create something. A stair for example could or should tell us the total run distance so we could include it in a report easily. But that is only part of the equation.
Why not add a simple formula to calculate the sloped run from the projected length on your plan? You could add a parameter to your egress family to do this. It could be as simple as a yes/no instance parameter. For example call the parameter "Sloped Run" and uncheck it by default. Now on a stair, sketch your line in plan and check the parameter. In your schedule, make a calculated column that has an if statement: if "Sloped Run" is unchecked, calculated length is equal to line length; if it's checked, then calculated length = line length divided by the Cosine of the stair slope. I would use something like 30 -35 degrees (or some number that makes sense to your condition) for stair slope and leave it at that. You can make this whole thing more complex by adding the calculations inside the line based family and entering slopes for different stairs, but I think then you get to a point where you're trying to micro-manage too much.

[Steve_Stafford]

I've attached another mockup to consider. As for the stair run/slope...mock'er up David, sounds like it'd work. :smile:

[dbaldacchino]

Ok, mocked'er up :) This is your original example Steve. Now there is an instance parameter "Over Stair" (checkbox) that if checked, will calculate the length of travel based on a stair of a certain Rise and Tread, which have also been added as instance parameters. If "Over Stair" is checked, the annotation "Stair" shows up so you'll know if you've got some inadvertently checked over non-stair areas. The schedule is the same as before as I found it to be easier to do the calculation within the family instead.

[chuttonx]

Anyway we can get the COMMENT Listed against the running line so it is easier to refer back to from Schedule to Line....?


Colin....

[david.kingham]

Just add it to the tag, here's an example