Sunday, 13 January 2019

Weird Railing Stuff - part 16 - Rail Hand Clearance Property

Following on from my previous post about Railing Offsets, here is some more detail about the ludicrously inconsistent UI for Handrails and Top Rail offsets in the 'New-style' railings.

Handrail Offsets

Handrails can only be moved laterally within the Handrail Type Properties (not in the railing properties).  This is controlled by a property called 'Hand Clearance'

The Hand Clearance property dictates how far the inside face of the Handrail is offset from the 'Notional Railing Centreline', which is not necessarily where the wall or other railing elements are*.

  • The Handrail family has a ‘Hand Clearance’ property, and projection property (see below)
  • In trying to use a real-world term, Autodesk have muddied the waters and made it totally confusing to work with.  This property is only logical with certain types of railings:
    • one example might be a wall-mounted handrail that has no other linear elements; and even then it only works when the Railing 'Offset from Path' property is set to zero.
    • If the railing has balusters and posts, with a Handrail mounted on those, the ‘Hand Clearance’ property does not take account of the baluster/post width, so you'd need to add in half that width yourself.

Once the Hand Clearance property is set in the Handrail family, you have to go back to the Railing family to see the effect it has on the whole railing, where the calculated Lateral Offset is displayed (not shown in the Handrail properties).

The Lateral Offsets are calculated by the system, depending on the Handrail type properties.  Typically this should be:
  • Hand Clearance + (Profile Width / 2)    - in this case  40 + 30/2 = 55mm.  
  • The Lateral Offset represents the centreline of the Handrail relative to the notional centreline of the whole railing (which is itself moved around by the 'Offset from Path' property).
  • If you want a centred Handrail, you need to make its hand clearance property minus half the profile width
Projection Property
  • There is another calculated property that is displayed here: 
    'Projection', which is calculated as (Hand Clearance + Profile Width)
    It is again greyed out, and updates immediately after any changes to the profile width or Hand Clearance.
  • I cannot see the logic of having this property displayed here, while the Lateral Offset is not.

Changing Properties

The knock on effects of any changes you make is again, a little confusing:
  • If you change the profile type, and hence its width then the 'Hand Clearance' is likely to change.  What Revit is trying to do is maintain the 'Lateral Offset' value, and hence the centreline location of the Handrail.
  • This may be logical to the software programmers, but not to designers, who would want to maintain the Hand Clearance when the profile width changes.  
  • The end result is that you need to pay careful attention, and manually change the Hand Clearance yourself after every profile change.
Once you have made any changes to the Handrail Type properties, then click OK, it returns to the Railing Type properties (if that is where you started from).  There is a display bug here:
  • The Lateral Offset does not appear to be recalculated (although it is).
  • To cause a display refresh, you need to change the value of the 'Position' to something else, and then back again.
  • Alternatively you could close the Type properties and reopen.

Wall-Mounted Handrails

In the case of Wall-Mounted Handrails, where there are no Top Rails or Balusters, the settings need to be somewhat different - and this is about the only situation where the term 'Hand Clearance' makes any sense.

The Railing Instance property 'Offset from Path' needs to be set to zero.  It is very frustrating that this is not a Type property, or at least have a default value stored within the Type properties - as you need to remember to set it to zero every single time you place a railing of this type.

The Handrail Type properties should be set with the actual Hand Clearance that you want - say 40 or 50mm.

Make sure that you choose the correct profile size first, as Revit will alter the Hand Clearance if you change the profile.

The Railing Lateral Offset property will be set automatically.

Top Rail Offsets

  • The Top Rail family also has a ‘Hand Clearance’ property, and projection property.
  • This is confusing - the Top Rail is meant to be there to support other railing elements, although it may double as a handrail. Whether it serves as a handrail or not, it would typically be centred with balusters etc on the 'Notional Railing Centreline', which is what the Hand Clearance value is measured from. 
  • Just to make it doubly confusing, the Top Rail offset is inconsistent with Handrail offsets:  a positive Hand Clearance value moves the Top Rail outside the stair in plan (Handrail moves inside stair).
  • Although the calculation for Lateral Offset is the same, it moves the opposite way:
    • (Hand Clearance + Profile Width / 2) - in this case  -25 + 50/2 = 0mm
  • If you want a centred Top Rail, you need to make its Hand Clearance property minus half the profile width of the Top Rail.

If you set the Hand Clearance to zero, you would get a Top Rail offset by half its width from all the balusters (unless they also had offsets . . .)

Here is  more information on the inconsistency between Top Rail and Handrail Terminology

Monday, 7 January 2019

Weird Railing Stuff - part 15 - Railing Lateral Offsets

I started out writing about the 'Handrail Hand Clearance' property of Railings in Revit - then I realised that it would involve analysing all of the related lateral offset properties associated with Railings and each different component.  It turns out to be a real "dog's breakfast", with at least six different ways to offset railing components, with minimal consistency between them all.  So I decided to document that first before looking at how it all affects 'Hand Clearance'.
Colour coded railing sub-elements
The above view of a railing is colour coded to help distinguish each sub-element; it is set at an oblique angle so that offsets are clear to see in the following examples with exaggerated offsets of 500mm.

A Dog's Breakfast

Railing Sketch line.

When a railing is placed automatically on a stair, it has a sketch line, that is typically on the edge of the run/landing.  All railing lateral offsets relate back to this sketch line location.

1.  Offset From Path

This is an instance property, which is applied to the whole railing and all its sub-elements.  
It represents a notional centreline of the railing, offset laterally (sideways) from the railing sketch line, which is placed on the edge of stair runs and landings by default.

Unfortunately there is a built-in system default value of 25.4mm, which is one inch.  The logic to this is obscure - it only works if your top rail happens to be 50.8mm (two inches), and where the face of the top rail needs to align exactly with the edge of the run/landing.  Why is this so bad?
  • This never, ever works in the metric world (all but two countries in the world) - even if we have a 50mm top rail there is still an 0.8mm discrepancy every time; Occasionally it might suit a situation in the imperial world, as described above;
  • This never works when the stair abuts a wall (metric or imperial) - see what happens to supports later on.

This default value is infuriating - as you have to correct every single stair railing after placement.  In my opinion it should be a default that we can control in some way (either a 'last placed' setting or in the Revit.ini file);  alternatively it should be a Type property rather than instance.  Please vote here on Revit Ideas if you agree with me - if this blog has helped you out, then please help me out by voting.

2.  Old-Style horizontal rails

The old Type Property dialog box for horizontal rail structure has a separate 'Offset' property for each rail element.  This does not used the word 'lateral' anywhere on the dialog box, so you have to guess which of the three possible directions it will offset (x, y or z), as well as which is positive or negative.

3. Baluster Placement (Individual Balusters)

The Baluster Placement dialog has a separate 'Offset' property for each baluster element.  This does not used the word 'lateral' on the dialog box, so you have to guess that it is a lateral offset property - although there are also Base and Top offsets, so it is easier to identify.

Warning:  This individual Baluster Offset property goes in the reverse direction to most other offsets:  A positive value pushes the baluster outside the stair, while a negative value goes in towards the stair - this is inconsistent with most other railing offsets.

4.   Post Placements

Railing posts are similar to Balusters (with the same reverse direction offset)

5.  Baluster Offset (and Top/Handrail)

Back in the Railing Type Property dialog box, there is another property called 'Baluster Offset' - another guessing game ensues.

This can give very unpredictable results.  It will laterally offset all of the balusters by the same amount;  it does not affect the horizontal rail structure.  With the old style railings, it was confusing enough because the individual Offset goes one way, and the overall baluster offset goes the other way. However, with the new style railings* it is almost incomprehensible :
  • The balusters will all be offset laterally by the same amount.  Unless . . . .
  • If an individual baluster offset value has been applied, it is cumulative, so the individual is added to the master baluster offset property (bearing in mind that a positive value for one may cancel out a negative value in the other).
  • Old style horizontal rails will not be affected (they get left behind).
  • New style 'Top Rails' will be offset.
  • New style 'Handrails' will be offset.

The net result of all this is that the Baluster Offset property may work as a Type control offset for the whole railing, provided that you don't have any old style mid rails - in that case you have to offset each of those in the Rail Structure dialog box.

* New style railings were introduced from Revit 2013 onwards, but old style railings were not automatically upgraded - only if you've swapped to the new style railings!  You may still have old-style railings in your projects.

5A.  Rest

Are you still following all this?   If not, (or you have a headache) just have a rest or lie down for a few minutes, before moving on to the next one.  I can't say it gets any better . . .
Deconstructed Railing

6.  Handrail

New style railing Types have handrail properties - these include "Lateral Offset" for each handrail, which are greyed out. 

The Lateral Offsets are calculated by the system, depending on the Handrail type properties.  This represents the offset of the Handrail centreline from the notional Railing centreline (which is in turn affected by the "Offset from Path" property . . .)
Refer to Rail Hand Clearance Property for how this is calculated.

If you change the 'Hand Clearance' property it will move the centreline location of the Handrail relative to the overall Railing.
  • This has to be done in the Handrail Type properties dialog box, not in the Railing properties.

7.  Right Handrail

The above example assumes a handrail is set to 'Left' Position.  If it is set to 'Right', the whole handrail is mirrored and offsets outside the stair.

8.  Top Rail

Top Rails also have a 'Hand Clearance' property, but unlike Handrails, this is not displayed as a Lateral Offset in the Railing Type properties.

The Hand Clearance property of of the Top Rail most assuredly does affect its Lateral Offset - so it would be mighty useful to have that property displayed, even if you want the Lateral Offset to be set to zero most of the time.

Why oh why is it missing?

One possible reason it is missing might be that the offset direction is the opposite to Handrails - a positive Hand Clearance on a Top Rail would give a negative Lateral Offset.

9.  Sketch Offsets

I would not be surprised if there are other Offset properties that I have missed.
There is at least one more way to move Railings, aside from playing with the properties:
  • Edit the stair sketch and 'Offset' the sketch lines from their original location.
  • I would not recommend doing this on stairs without good reason, as it would make the properties even more confusing.
  • If the sketch lines go outside the run or landing (laterally), you would most likely encounter hosting and height problems - so that is not advisable.

If you are confused by all this, it is hardly surprising.  I will try to shed some light on how to manage these offset properties in future blog posts. . . . .

Wednesday, 12 December 2018

Weird Railing Stuff - part 14 - Railing Baluster Height Top Offset

Balusters have always been completely confusing in Revit Railings.   However, one baluster property used to be quite straightforward:  the baluster Height, which Revit seemed to handle quite well - providing the baluster top constraint was set to the appropriate rail element.  In earlier Revit days, baluster height could be set as an absolute value, or could be attached to one of the rail elements:

Revit Railing Rail Element Definition

Each of the named 'Rails' were available as a top constraint for balusters - whatever names you gave to the Rails were shown in the drop-down menu 

In the old Revit railing method the highest 'Rail' usually represented a handrail or top support/fixing rail of some kind - and this would be a good constraint for the balusters - if its height changed, all the balusters would adjust accordingly.  It didn't really matter what you called the Rails (but it does matter now - see below).

A Cat Among The Pigeons

A few years ago, we were given new specialist system defined railing elements "Top Rail" and "Handrail".

The original rail elements remain available in the UI for use as mid rails for example (although can still be used to represent handrails).  This means there are now three different ways to define the continuous rail elements.

At this point, Baluster top constraints became very confusing and inconsistent . . . .

Baluster heights can still go up to the old Rail elements.  They can also go up to new 'Top Rail' Elements but not to new 'Handrail' elements. 

Some railings have only handrails without top rails, so that is a totally ridiculous restriction.

Rail Naming

The old style Rails, might have the same name ("Top Rail") as the new system name of "Top Rail", particularly as that was a common naming convention in old style railings.

This could be very confusing as they both appear in the Baluster dialog drop-down menu - in order to avoid a conflict  the word "Element" is added as a suffix to the system family.  This drop-down menu is the only place it is so named.  Get used to it!

What I recommend is to rename any old style Rails that may represent handrails or top rails - this will avoid any confusion. 

A better solution is to use the new system family rails for either handrails or top rails and then remove the old style rails that used to represent handrails.  Even though the new system Rail families have been available for at least five years, you will find many railings that are set up the old way, so you will need to fix them.  The reason for the old style railings hanging around so long is partly because old railings are not upgraded to new style ones when an old project or template is upgraded - this is amply demonstrated when you look at the Autodesk sample file, which has never been fixed!!!  Thankfully Autodesk did fix their supplied project templates - but your company templates need to be manually corrected.

* NB. The new style handrails/top rails are mostly better than the old ones - but not in every situation.  The old rails could go around a tighter corner on a half landing, where you have limited space [they both break but the older ones in a better way].  However, on balance I prefer to go with the new ones and live with that shortcoming and the many confusing inconsistencies built into them.


When you do fix your old railings, and you replace old style handrails with new ones, you may get an error message when you delete old handrails/top rails:

When you try to delete an old rail from a railing definition, Revit may warn you that it will reassign the height reference (for balusters).  If you say Yes, you might expect Revit to make an attempt to resolve it.  This is in fact quite misleading, because it usually fails abjectly:

The balusters cease to exist until you go in and manually correct their top constraints, which will most likely be unassigned:

Confused by all this?  That is not surprising - go in to your project template and check all the railings, and it may start to make sense.

Thursday, 6 December 2018

Weird Railing Stuff - part 13 - Handrail Support Family Types

Is this a Railing Bug?  Or is it the UI 'As Designed'?
Either way, it is yet another example of how the railing interface in Revit needs some serious attention.

Support Family or Type?

 As you all know, it is entirely possible to have numerous different families that all have the same Type names, in a Revit project.  This can happen for a number of reasons, including the mysterious bug whereby families get renamed with a number suffix when copying elements into a project that already contains that family.  These families may or may not be the same

When selecting a support family type in a handrail family, it only lists the Type name – so that if two different families have same type name, you can’t tell the difference

 In addition, the list of family/types does not appear to be alphabetical - so the order may easily be different to the order in the Project Browser.

Note that in the Handrail Type dialog box, the parameter is labelled as 'Family' when in fact it is listing Types only.  In the Railings dialog box, the parameter is labelled as 'Type' - yet another inconsistency!

Thursday, 29 November 2018

Weird Railing Stuff - part 12 - Top vs Hand Rail Usage Terminology

More Revit Railing UI inconsistency:

In the Railing Type Property dialog box there are sections for Top Rail and two separate Handrail properties.  Each of these have:
  • a Height property.  As noted in another post, the behaviour of the Height property is completely different for each. 
  •  a 'Type Name' property
  • There is also a property that you set whether the chosen type is used or not, and if so what position(s) it is in - these are also inconsistently named, which causes confusion when you first look at them:
Top Rail - 'Use Top Rail'  = Yes/No

Handrail - 'Position' = None, Left, Right, Left and Right

Why the inconsistency?  It would be so easy to make them the same - they could both be called 'Position' or both 'Usage'.  The settings could both have a 'None' option, instead of one being 'No'.

Friday, 23 November 2018

Weird Railing Stuff - part 11 - Rail Heights


More Railing inconsistencies in Revit

The (not so) new capabilities for adding 'Handrails' and 'Top Rails' to railings can be very useful, but the UI is riddled with weird settings and inconsistencies - this one relates to their Height Properties.

  • Handrail has height property built into handrail family type
  • Top rail has height property in the railing family type (not built into top rail family type)
  • The Handrail height is displayed in the railing property dialog box, but is greyed out
  • Top rail height is controlled directly in railing property (much better)
 What this means is that you can have one Top Rail family type that can be used at varying heights.
  •  Meanwhile, if you want to change the Handrail height, you have to click on the hidden button to the right of the Type name - this opens the Handrail type properties for the selected handrail.
  • The height can be changed here - but of course it will affect all railings that use that particular handrail type, so you probably need to duplicate type.

  • This means that you need a separate handrail type for every possible height.
  • It is possible to right-click on a Handrail type in the family browser, and 'select all instances in project' - it does actually highlight them individually.

  • Since Revit users are never quite sure what has been used, they seldom check by this method, but typically duplicate type anyway, leading to a profusion of similar or identical types.
  • For this reason, it is wise to name the handrail types accordingly - either with a specific height or with a purpose

  • This will ensure that when selecting a handrail type in the railing property, you have some chance of getting the correct height.

It is not clear to me why these settings are different - I would much rather that both had height properties in the railing.  That would give us consistency instead of confusion.  It would also mean creating fewer handrail types - we already have enough variations of those to cope with the extensions.

And all this doesn't even address the fact that the old 'Rail Structure' method is still available for use to create handrails, top rails and mid-rails - and that has a totally different method and UI.  Aaargh, what a mess!