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.
Warnings
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.
