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!