Sunday, 3 December 2017

Weird Railing Stuff part 9 - Handrail supports on Multistorey Stairs

At first sight it seems that the new Multistorey tools in Revit look like a significant improvement over the old method.  However, as you delve deeper, there are some new problems that have been introduced with the new feature.

Weirdness #1

Once a regular component stair has been converted to multistorey that process cannot be reversed.  There is no command to 'Reset Stair' or 'Convert back to single storey'.  You can go to the 'Disconnect Levels' command, and select the other levels - this reverts it to a 'Single Storey Multistorey stair' - but it still identifies as a multistorey stair in the properties

So what, you might think?  Well, you can manipulate a multistorey stair by tab-selecting the stair inside the 'multistorey group', but that could be very confusing.  The more significant issue is what it does to railing supports:

Weirdness #2 Railing Supports

If you have a stair that has railing supports, and then you convert the stair to Multistorey it does something strange to the supports.  The original level stair railings behave normally - you can select a railing support and it will be pinned.

You can unpin individual supports then move them, swap to a different type or delete them

On the other levels, you can select the supports but they do not have a pin icon.  However, you can actually move, copy or delete them;  what you cannot do is swap their type (it is greyed out); nor can you change the hand clearance property.  They are in effect in some middling state between pinned and unpinned.

If you modify any of the railing supports, you can 'Reset' the railing so that all moved or deleted supports are reinstated to their original position.  Copied supports vanish.   

You might expect that supports on the original stair railing would become pinned again.  Well, not exactly:

Weirdness #3

If you 'Reset' the railing on the original stair level, it actually converts it to the strange middling state where none of the supports are pinned any more but there are reinstated to the original locations.

The moral of this tale is that you should probably try to adjust all the supports before you convert a stair to multistorey, especially if you want to swap any support types.  If that is not possible, you may still be able to do what you need to the supports after making the stair multistorey - notwithstanding all the other painful issues with railing supports.  One thing is sure - you will be confused.

Sunday, 12 November 2017

Scheduling Wall Heights in Revit

One of the new features in Revit 2015 was the ability to schedule wall heights - well, sort of.  More Wall parameters could be scheduled than previously:

  • Base Constraint
  • Base Offset
  • Top Constraint
  • Top Offset
  • Unconnected Height
What was not included in this list was "Top is Attached" or "Base is Attached". 
This is really worrying because it means that when a wall is attached at top or bottom, the "Unconnected Height" is almost certainly going to be displaying a false value in the properties dialog box, and in the schedule.  

Unattached wall with correct Unconnected Height property

Attached wall top with wrong Unconnected Height property
In the properties dialog you can see those "Attached" checkboxes so it might alert you to the issue, but that does not help in a schedule, as you cannot display those properties there.

This also occurs when a wall has been attached to a gable end roof (or any angled roof)

Edit Wall Profile

The same problem could also happen if a wall has had its profile edited - again the wall heights could be scheduling false values. 

This is not so simple to pick, as there is no property for "Profile is edited" - however, Revit knows if it has been edited or not because it displays a "Reset Profile" icon in the ribbon if a selected wall has had its profile edited .


Basically, when you schedule wall heights using the 'Unconnected Height' property, it could be a pack of lies!  If we could also schedule the "Attached" properties of a wall, then we could use the schedule to identify attached walls, and perhaps use conditional formatting to highlight possible false height values.

One alternative solution is to create a calculated value of Length x Unconnected Height to get the supposed area;  this can be compared to the actual reported area (built-in property).  If they are different then you know that the wall has been either attached or had its profile edited - therefore the 'Unconnected Height' property is unreliable.

You could take this a step further by adding a comparison calculation

You could then do some conditional formatting to make any dodgy wall heights easily apparent

One other thing you could do is reverese engineer the height by adding a calculated Average Height - This would only be accurate for rectangular walls, as those with sloping tops or edited profiles would still not be accurate - hence the use of the word 'Average' in the calculation name.  I would use this solution with caution - perhaps only where walls have accidentally been attached to floors above.

Attach Walls to Edited Floor Sketches?

One of the reasons that all of this is likely to be an issue for all of you is that when you edit a floor, Revit always asks if you want to attach walls below it.  The default answer is 'Yes', which means that a lot of walls will end up being accidentally attached to floors above - meaning that your wall heights will be wrong in schedules.  Wouldn't it be better if the default answer was 'No' and even better still if this dialog box never, ever appeared.

Please vote for this Revit Idea to encourage Autodesk to do something about this.

Thursday, 2 November 2017

Weird Stuff with Revit Shared Parameters

When you create a suite of similar parametric families (say windows), you will define a series of parameters that control the families in the project - it may be dimensions, visibility switches etc.  If those are instance parameter, there is a really important choice you have to make:

  • Should they be "Shared Parameters" or just regular "Family Parameters"?

Conventional wisdom says that you only need to make them shared if you want to tag or schedule them in the project.  However, there are some other critical differences in behaviour that may affect your decision:

Did you know that when you make them 'Family Parameters', then start using the families in the project and swap them over for similar families with identical parameters - Revit loses the  data held in the instance parameters - even if the instance parameters are identically named in the families?  Aargh!!  That is not good news.  This even happens if the families were cloned from one source that already had the parameters set up.

However, if you used 'Shared Parameters' that instance property data is maintained when you swap family/types (provided that the same shared parameters are defined in each of the families).

Here is another reason for using shared parameters even when you don't need to tag or schedule them.

Sunday, 29 October 2017

New in Revit 2018.2 - Pattern Dialog Box

Following on from my last post about new features in Revit 2018.2, there are some very nice tweaks to the Pattern dialog boxes:

Fill Patterns

  • The Fill Pattern dialog box is now fully resizable (height & width) - Revit remembers the resize operation during the session.
  • The Fill Pattern dialog box has been redesigned to replace text icons with visual icons - as per many other Revit dialog boxes.
Revit 2018.2 dialog box
Old dialog box

  • No Pattern <None> is now at the top of the list (when accessed from a dialog box that has the option to remove a pattern, such as the Material dialog box) - this replaces the 'No Pattern' button at bottom left of the old dialog box.
  • Solid Fill is now second from the top of the list (Drafting patterns) after 'No Pattern' - generally I think this is a good thing.  NB. This is not the case with the Override dialog boxes, which have not yet been redesigned - so we have another new inconsistency.

  • There is now a Search/Filter function for patterns - it will filter the list to only include whatever contains the text you type into the 'Search' box.  It is not case sensitive.    Watch out for this feature:  if you have any text in the search/filter box, you may not see the <None> or Solid fill items at the top - it will take some getting used to, and will surely catch you out a few times.
  • It is now possible to select multiple fill patterns when the dialog box was accessed from the Manage toolbar (but not from dialogs that require you to choose a fill pattern to be used somewhere - like the material dialog box);  If multiple fill patterns are selected, they can be deleted but not edited (the edit icon is greyed out).

Edit Fill Patterns

The Edit Fill Pattern dialog box has been redesigned - the new overall layout is more logical:
Revit 2018.2 Edit Pattern dialog box
Old Edit Pattern dialog box

  • 'Simple' patterns are now labelled as 'Basic' 

  • When listing custom patterns from a pattern file, it shows 4 instead of 3.  When the dialog box is resized vertically, it only increases the size of the preview, not the list of custom patterns, so you still need to use the tiny scroll bar on the right.
  • The 'Import' button (on the left) has been replaced by a 'Browse' button (on the right) - why?
  • The Import Scale value has been unlocked so it can be changed at any time after importing - this sounds great but BIM Managers may not be happy as they will lose the ability to set and lock down pattern scales.
  • Changing the scale without re-importing is immensely useful, as we often do not know where the pattern came from.  In this situation,  the preview updates as soon as you change the scale.
  • We have lost the File Units -  Aaaargh!  Why?  I like to know if the source was metric or imperial.
  • As with the old dialog box, we cannot see the name of the imported pattern file, which would be useful.
  • We now have a search/filter function for custom patterns, which operates much like the one on the Fill Pattern dialog box - this only works immediately after importing a pattern file. 
  • The title 'Settings' seems a bit odd when the pattern is set to custom - it was obviously designed for Basic/simple patterns, where it is more appropriate.

Overall, this is a welcome change to the UI, with only a few minor quibbles.  It would be great to have many, many more such minor improvements that incrementally take away the pain of using Revit.

Friday, 20 October 2017

New in Revit 2018.2 - Family Types Memory

Here we are with a third set of enhancements for Revit this year - first version 2018, then 2018.1 and now 2018.2

There is nothing amazing - just small things as Autodesk themselves say.  I have tested a couple of things and have some comments on the first of them:

Remember Column width spacing in Type properties dialog

This one is in the Family Editor - in the Family Types dialog box (the one with four blue squares, which I never remember the name of).
When you open that dialog box, the column widths are never arranged how you want them:  The formula width is too small if you want to add formulas; the 'Lock' column is always too wide etc.
In previous versions, after you had rearranged the widths, then closed the dialog box, the next time you opened it, those darned column widths were back to standard.  In addition to this, when you make the dialog box wider, all the column widths expand; if you make the first column wider it often seems to make the 'Lock' column wider too (ridiculous for a checkbox), and then you get a very irritating horizontal slider on the dialog box - pretty soon the left hand columns disappear off screen when the focus goes into a formula . . . .

In Revit 2018.2, they have addressed just one of those problems - but only partially:  Yes, the column widths are remembered when you reopen the dialog box - sounds great but . . . .
Standard column widths

When you adjust the column widths, you have to be careful to make sure that the vertical divider line to the right of the 'Lock' title does not disappear -
Adjusted column widths to make formulas readable

Once the right hand Lock column divider disappears, you get the scroll bar along the bottom of the dialog box.  Once the whole Lock column disappears, and you put the focus in the Formula column, it shifts the Parameter Name column off screen to the left.

 If you adjust the dialog box width, it is possible to make formulas and values readable - but watch that Lock column width
Adjusted dialog box width

In version 2018.2 they have broken something in the controls for adjusting the widths and sliding the scroll bars - it is pretty flaky.  Within 10 minutes of testing I had managed to entirely lose the Lock column, so you couldn't see it even with the slider fully to the right.   I have reported this as a bug, and Autodesk have replicated the problem, so hopefully they are fixing it already.

The Bad News

  • The Dialog box column widths are only remembered per session (Actually that may not be so bad after all . . .). 
  • The annoying expanding Lock column is still annoying.
  • The nasty horizontal slider is still there, doing its worst to hinder you - I would much prefer it if the Lock column was always narrow, fixed to the right side of the dialog, while the other three columns scaled proportionally with the dialog box (at whatever width you set).

The Good News

  • The Dialog box column widths are only remembered per session. 

Yes, this really is good news because if you manage to screw up the widths on the dialog box, it all resets when you next start Revit.   Actually it is good news anyway, because it is most likely that you will want different alignments depending on your task, each time you open Revit.

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.