Monday, 2 October 2017

Weird Railing Stuff - part 8 - Moving Handrail Supports

I have explained previously that Revit handrail support spacing is measured along the length of  sloping handrails, not horizontal (plan) distance.

What does this mean when it comes to moving individual supports on a handrail?  Well, the rules are equally weird, but differently weird.

In the following  example, you might want the spacing to be measured horizontally (in plan), so you need to move the supports on the sloping parts of the handrail.

The first thing to do is select just the support (Tab, select), and unpin it.  This will allow you to slide the support along handrail - but most likely you want to be very precise about how far it is moved.  You might try using the 'Align' tool, providing you have something like a reference plane to align to:

Law of Diminishing Returns

In this context, the Align tool does not do what you expect - it presents you with more Revit Weirdness.  Once you select the reference plane to align to, then click on the support centreline, it moves the support only about two-thirds of the way (this fraction probably varies depending on the slope of the railing). 

My first thought was that it was converting the horizontal distance to an actual distance up the slope of the handrail - but it is not that value (something slightly different).  It is using some other mysterious mathematical rule that I cannot fathom.

If you try Align again, it goes another two-thirds of the remaining distance.

 Try again and you get closer - but you will never quite get there.  There has to be a better way?

Move Weirdness

If you try using the 'Move' command, and select a horizontal distance, you get exactly the same result as the Align tool - it does not move it to where you tell it.  The same 'Law of diminishing returns' applies.

The Move (Workaround) Solution

The trick here is to use the move command, but make sure that you snap to the end point of the support, and then have a reference line that has an end (or intersection) point exactly where you want it to be placed - slightly above the underside of the handrail.

The Slide (Workaround) Solution

There is another trick - providing you have a (reference) line running vertically and stopping exactly where you want it to be placed (as with the previous workaround), you can just select it and slide it along the handrail, and it will snap to the right place.  However, I do not recommend this because if your reference line is too long or short, it may look like it went to the right spot but could be slightly off.  The move command is more precise.

Reset Warning

If you click on the 'Reset Rail' or 'Reset Railing' commands, you will lose all of those careful support relocations on the whole handrail - each moved support would be moved back and repinned, while deleted supports would be reinstated (including those silly ones exactly on the ends of handrails).

Wednesday, 27 September 2017

Weird Railing Stuff - part 7a - Support Spacing Postscript

I mentioned in my previous post about handrail support spacing that the distance between supports is measured along the length of the handrail regardless of its angle, rather than a horizontal plan distance (which is used by other railing element spacing).  It turns out that it gets even weirder:

Revit Railings Get Weirder and Weirder

I thought I would check where it is measured on the handrail, and whether it takes into account a fillet radius if you have one.
  • On a horizontal railing, it measures support spacing on the underside of the handrail
  • On a sloping railing, the supports seem to be attached to the handrail a bit higher - you can snap to the top endpoint of the support.  In the example I tested, with a 75mm high support, the top is about 7mm vertically into the handrail.
  • This means that the spacing is measured slightly above the underside of a sloping handrail - this may vary depending on the angle and the type of support.  However, I have no desire to investigate any further - this is weird enough already.
  • If you have a curved transition from horizontal to sloping handrail (fillet radius), the support spacing measurement transitions (on a radius) from underside of handrail to somewhere above the underside.
  • This means that you cannot accurately predict where the supports will end up - unless you do a checking diagram like the one below.  I can tell you, this is the first and last one I will ever do!

 Extension to Floor

I know that you'd never put supports like this on a handrail with a vertical extension to the floor, but I just wanted to see what it does with the spacing:

The answer is that the supports get flipped to the outside of the handrail (what becomes the top when it turns the corner to be horizontal).  However, the spacing between the two supports as it goes from vertical to horizontal is not predictable.  In the example above, the typical spacing is 200mm (just to be certain it doesn't come away from the wall!), but the distance measured orthogonally between those two supports on the corner is only about 190mm - so we are adrift by 10mm.  As I said, it is not easy to predict exactly where the supports will end up.

If we had a start/end indent property, we could at least make a guess, then tweak the indent value until it is exactly where we want the first/last support - without having to unpin the supports (which has its own problems, to be discussed later).  Please go to the official Revit Ideas website and vote up my idea on this

Just to entertain you, here is what Revit does when you have a handrail extension to a wall - note that the support goes to the top of the handrail again (not that you actually want a support when the handrail fixes to a wall, of course!).

Sunday, 24 September 2017

Weird Railing Stuff - part 7 - Support Spacing

It amazes me that very few Reviteers make use of the 'Railing Support' capability that we have had in the software for over 5 years now.  In fact, a very large percentage of users don't even know they exist
Here are some possible reasons why that is the case:
  • If you upgrade a project with the old style railings in it, they are not converted to the new style railings, so you cannot use railing supports in them.  To achieve this, you have to copy a new railing type into your project, then swap the old family type to a new one to get access to the support functionality.
  • The metric project templates provided by Autodesk do not include any railings that use handrail supports (this includes the Australian and UK templates);  they do have some support families - but if you don't know how to use them, you'll never figure it out by playing around with the railing samples.
  • The sample files that you can download from the Autodesk Knowledge website include only the old method of using balusters to look like handrail supports - and that is the imperial unit sample file, which you would expect to be the most likely one to be updated when the software was changed (The metric version would have no chance, even if you could find it on the Autodesk labyrinth-site).  I wonder if anyone at Autodesk knows what QA means?  'Quality Assurance' is the correct answer, not 'Quick As (get this out the door)'.
  • The settings for adding supports are buried deep as type properties of a nested family.  The chances of finding this are slim - although that has improved recently with the ability to get to a handrail family properties directly from the railing type properties dialog box with one mouse click.
  • The methodology for setting up handrail supports is mind-bogglingly complicated and counter-intuitive - and it is all type-based properties hidden inside handrail families nested into the railing family.
  • Even when you have set up the supports in a handrail family, you have to remember to choose left or right (for the handrail) in the railing family, otherwise nothing shows up.

Handrail Support Spacing

Once you have figured out how to set up Handrail Supports in a railing,you will obviously want to control the spacing - first the initial spacing, and then changing the spacing.  There are at least two weird things you need to know about this - the first is how illogical and inconsistent the spacing properties are.  The second weird thing relates to moving the supports - to be dealt with later:

Spacing Properties

Do you think it is weird that baluster spacing and handrail/top rail extension length properties are measured in plan distance regardless of the slope of the railings, while support spacing is measured along the actual length of the handrail whether it is horizontal, sloping, vertical or going round a twirly flourish at the end?  Whichever one is correct, it is weirdly inconsistent.

How would you measure the support distances on this handrail?
In the Handrail type properties, you have the typical Revit options (plus a special one):
  • None
  • Fixed Distance
  • Align With Posts
  • Fixed Number
  • Maximum Spacing
  • Minimum Spacing
Unfortunately these are not consistent with each other, and none of them will give you the outcome that you desire (unless by a fluke the spacing just happens to work for your stair):

1.  'Fixed Number' does not put supports at the ends of the railing;  the spacing varies depending on the overall railing length, and the number that you put in - NB. the number is a type property of the handrail, which means that you most likely need a unique handrail type and a unique railing type for every single instance of the railing.
It seems that the supports always use centre justification for this - it is greyed out and you can't change it;  also, the greyed out value for spacing is just a remembered value from the previous settings, and is misleading here.  Revit does not report back to you what the actual support spacing is on each handrail instance.

If you have a free end handrail, you would typically want a support close to the end (but not exactly at the end).  You don't get a support anywhere near the end, unless you put in a ridiculous number of supports, like 50 in this example.
Fixed number does not put supports at the ends
If you have an extension to wall or floor, then this option makes sense, however, the spacing includes the length of the extension, measured along the handrail, including vertical length for a floor extension.  The example below, with a wall extension is the one and only situation where Revit gets the support locations close to what you might need, albeit that you need a separate type for each different number of supports.

2.  'Fixed Distance' only puts a support at the start or end of the handrail if the justification is set to Beginning or End;  the distance at the other end is pot-luck depending on the overall handrail length.  If the justification is 'Center', then the distance from the start and end again depends totally on the overall length of the handrail - so it is luck of the draw, but it will be the same at each end.
The calculated distance includes extensions.

 3.  'Maximum Spacing' always puts a support exactly at the start and end of the handrail; justification is not an option here - it is greyed out (and set to center).  Just imagine sending this drawing to a builder or fabricator - you'd be laughed off the site.

Revit does not take into account whether an extension with a wall or floor fixing is chosen - it still puts a support in place at the very end, just where it is fixed to the wall/floor.

4.  'Minimum Spacing' behaves just like the Maximum Spacing settings, although the actual spacing will be different.

5.  'Align with Posts' is an interesting option - I don't get why you would use it, unless your posts are non-supporting in themselves.  If you do use it, you have no option for supports between the posts, so what good is that?  I would have thought the option should be 'Align with Posts & Maximum Spacing Between' and suchlike.  Or 'Maximum Spacing Except at Posts' etc.

With all of these options, you have the opportunity to unpin a support and move or delete it; [Edit - thanks to Peter Schiettecatte for pointing this out:] but you can only add additional supports by unpinning an existing one and copying it along the handrail (a clever but not too obvious workflow).  However, once you have done this, it takes just one innocent (or stupid) click on the 'Reset Railings' button to lose all that hard-won support over-ride spacing.

The Solution

What we really need to solve some of these issues is to have consistency in how the spacing is applied (at ends); and the ability to set start and end indent properties for handrail support spacing.  These would operate rather like the equivalent properties on a 'Divided Path', although I guess they'd need to be type properties to be consistent with all the other handrail properties (Oh, how I wish most of those were instance properties in the actual railing)

If you think this is a good idea, please go to the official Revit Ideas website and vote up my idea on this.

Wednesday, 20 September 2017

Revit's Most Hidden Commands (part 5) - Selection Locks

The title of this post is somewhat ironic - because the command in question is right there on screen, all the time in Revit.  However, it is remarkable how many Revit users never see it and don't know what it does.

I'm talking about the Selection Locks at the bottom right of the screen, in particular the one called "Drag Elements on Selection". 

It used to be called 'Press + Drag'.  I didn't like it then, and I don't like it now.

In the words of Captain BIMCad, it is the "Little Button of Evil".  I am glad that someone else considers this little icon to be the bane of Revit Users lives.

It is astonishing how many Revit users do not have this set correctly - unfortunately the default out of the box Revit setting is wrong.    Just Plain Wrong!   Downright Evil!

The correct setting is for the little evil icon to have a red cross on it so that users cannot select and move an element with one mouse movement - something that is all too easy when trying to make a multiple selection by dragging the mouse.  When  "Drag Elements on Selection" is disabled, the user would have to select an element, let go of the mouse button then click and move again - that is a more definite action that is unlikely to be done by mistake.

To solve this once and for all, you need to have a BIM manager that sets this properly in your Revit.ini file, and an IT team who understand how to roll out Revit.ini files to all users (that is a challenge in itself).  The fall back position is to manually check (and change) the setting on every computer in your office, for every user profile, including whenever a new person joins the company.

The other selection locks are extremely useful, but cause endless confusion because most users just don't see what is right in front of them.  The same settings are also available from a drop-down menu below the selection icon at the far left of the ribbon.

It is really important that everyone makes the best use of these, so that you can avoid accidentally selecting things like underlays, linked files and pinned elements.  Obviously you just disengage the locks when you do need to select any of those elements.  and remember to re-engage the locks afterwards.  But never, ever disengage the 'Drag Elements on Selection' lock - it should always have a red cross on the evil icon, and not be ticked/checked in the drop-down menu list.

Wednesday, 23 August 2017

Scheduling Global Parameters in Revit

Revit is all about data and displaying or extracting that data.  So, you'd think that when a new Revit feature  is added, like Global Parameters, you should be able to schedule them?
Wrong!  You cannot directly schedule or tag Global Parameters in Revit.

However, I have devised a workaround (NB. this won't work on Revit 2016 R2):

Example 1 - Reporting Dimensions

In this example there are several sloping ceilings.  Each ceiling has a built-in property 'Height Offset From Level', which represents the height of the base of the ceiling slope.  This can easily be scheduled.  It is not so easy to schedule the height of the top of the ceiling slope - unless you use global parameters:

Step 1 - Reporting Dimensions

  • In a section view, add a dimension from the level to the top end of the sloping ceiling
  • Associate this to a global parameter
  • Make it a reporting parameter

  • Repeat this step for each sloping ceiling

Step 2 - Project Parameters

  •  Create a new instance project parameter called 'Ceiling Top Height'
    • Make it a length type
    • Apply it to the ceiling category
    • Give it a meaningful tooltip
  •  Each ceiling will now have that property, albeit blank


Step 3 - Associating Global parameters

The Project parameter properties of individual ceiling elements then need to be associated to the relevant global parameters (reporting dimensions):


  • This obviously means that one global parameter is required for each ceiling, which could become tedious for many elements - but this a workaround, after all.

Step 4 - Create the Schedule

A schedule can be created to display this information:
  • A ceiling schedule could be created, showing the built-in height parameters and the project parameter with associated global parameter

Example 2 - Area Calculations and WC Numbers

Step 1 - Global Parameters

Create your global parameters, with formulas as required.  In this example, global parameters are being used to calculate the number of toilets required for a community hall, where the statutory regulations require a certain number depending on the floor area of the hall:

  • There are two reporting parameter dimensions for room width and length.  
  • These are used to calculate a room area - this is an extra step to be taken because even though Revit gives us room areas automatically, we are not able to associate areas as reporting parameters, so we can't use the system Area property (except as a check on the calculation)
  • There is a user defined "Area per WC" - which is set as 1 WC required per every 30 square metres of the hall area.  This value can be changed later.
  • To establish the number of required WCs, a simple calculation is done:
    Hall Area / Area per WC
    This is an integer parameter so it always gives a whole number;  however, you could make the formula a bit more complicated so it always rounds up to the next integer
  • There is another check formula that sets the minimum number of WCs to be 2 - this is partly because arrays will only accept 2 as a minimum.  There is an 'array workaround' if the minimum really needs to be 1, but that is not shown here.

Step 2 - Project Parameters

The trick for being able to schedule and tag global parameters is again to use an intermediary - namely Project Parameters:
  • As many project parameters are created as you need for scheduling/tagging global parameters
  • They are defined for the categories to be scheduled - in this example it will be for both rooms and generic categories
  • 'Area Calculated' is added to the room category so that it can be scheduled and tagged
  • It must be a shared parameter for tagging;  if you want to apply it to just one category and only schedule (not tag), you might get away with it not being shared;  for multiple category schedules it needs to be a shared parameter.

  •  'WC Numbers' is an integer parameter added to both the room and generic categories - for rooms it is just for schedules/tags;  for generic categories it is being used to drive the model - number of WCs in the array

Step 3 - Associating Global parameters

The Project parameter properties of individual elements then need to be associated to the relevant global parameters:
  • The room element for the hall has its 'Area Calculated' property associated to the 'AreaCalc' global parameter
  • Its 'WC Numbers' property is associated to the 'WCNumCalc' global parameter

  • The WC cubicle component has a family property for the 'Number of WC Cubicles', which is used to control the number in the array.  This is associated to the 'WCNumCalc' global parameter - so that when the hall area changes, the global parameters recalculate the number of WCs and push that change into the cubicle array component..
  • NB. It is not possible to associate a global parameter directly to an array number in the project environment, so the array has to be built into the family - another workaround.

Step 4 - Create the Schedule

Schedules can be created in a number of ways to display this information:
  • A room schedule could be created, which shows the contents of the room

  • A better way to achieve this is to create a multi-category schedule that includes one element in the required room (Hall) and also the WC cubicles in the other rooms
  • Room properties can then be added for each element - in particular the project parameters for the hall room
  • The one element in the room 'Hall' needs to be listed in order to display the associated global parameter values of the room (Calculated Area & Required WC numbers), even if we don't want to schedule that element itself. This is because a Revit multi-category schedule cannot contain rooms as one of the categories - only the room properties of other category elements.
  • In this example, the schedule needs to be filtered to restrict it to just show generic category elements (WCs) plus the category of the element in the hall (a door in this case, but it could be anything); and then further filtered to get only the relevant ones listing

  • The fields from Rooms and Count, can be renamed to indicate required and supplied WC numbers


These are only two specific examples of how global parameter data can be scheduled and displayed.  Of course it is unlikely to suit your exact requirements but it should demonstrate the principles to be applied to different situations.