Tuesday, 21 October 2014

Revit Purge - So Good You Use it Thrice

How often do you use the Purge command in Revit?  Have you ever noticed that the icon includes a broom?
Probably your Revit model manager is the only person allowed to use it because you could accidentally remove important stuff from your project if you don't know what you are doing.

If you are allowed to use the command, and you know what you are doing, then you may not be aware that you need to run the command three times in succession to do the job properly.  This has been the case for the last few years since the Factory added the capability to purge materials.

Why Purge three times?

1.  The first time it will select all the unused elements that it is able to:
2.  The second time it will pick up materials and assets that were used by elements purged the first time
 3.  The third time it will pick up unused material assets that were previously associated with the materials purged the second time

Why does it do this?  Well it seems unable to handle purging the materials and assets at the same time as their parent elements - it is all too much for it.  It is not consistent with other aspects of the purge command - for example if you purge an unused group, Revit will also purge items that are in the group providing that they are unused elsewhere.  So Revit can do it all in one go if it wants to.
My guess is that different people coded the software for material purge, and they probably didn't follow the same rules.  Or perhaps there is a technical reason for the inconsistency?

Either way, I am very, very happy that we can actually purge materials because it did not used to be the case a few years ago, and it was extremely tedious deleting materials one by one.  I know that on some projects  it can take half an hour to run the purge command, so it is annoying to have to run it three times.

Why is Purge Dangerous?

Why not let just anyone run the purge command?  Well, apart from the time it takes, it can remove important stuff from your project that is tedious to reinstate - here are some examples:
  • Curtain Wall Mullions.  Purge will remove some unused system families or types - like all those tricky corner mullions.  It removes all unused types, including the last one of each mullion system family.

  • If you try to place a mullion then you discover that no mullion family is loaded - not something that a novice user needs to deal with.

  • Purge does does something a bit different with some annotation families: eg. Spot Elevation families;  it removes all but one unused family - so it will not remove the last one (it may not be the one you want to keep).   Typically you will actually want several different spot annotation types (at least one each for plan and elevation).  This means that most of your annotation standards can be blitzed in one command - and they are laborious to set up again.
  • The same goes for other annotation types like dimensions, text etc - although they are easier to reinstate.
To get around this problem, I suggest creating a "setup" phase that is earlier in time than "Existing" and placing one of each type of mullion, door family, annotation etc that you do not want to have purged accidentally.  The elements in this phase would not be visible if they are demolished in the existing phase.

Purge Does Not Remove Everything

Despite it being too easy to purge some things, it can also be hard to remove others:
Where one family is referred to by another that is retained in a project, Purge will not remove either (even if unused).  There are numerous examples, each of which behaves differently:
  • It is impossible to remove either of the Stair path arrow system families, despite the fact that most people only want to use one as their corporate standard.
  • Basic walls cannot be purged if they are defined as part of a stacked wall, even if the stacked wall is not used.  Nor can they be deleted in the Family Browser (by right-clicking) until they are removed from the Stacked Wall definition.
  • Railing Subcategories like Top Rails (and Handrails) will not be purged if they are part of a railing definition even if that railing is not placed in the project.  However, you may be able to delete them from the Family Browser:
  • If the railing has other elements beside the Top Rail you try to delete, it allows the deletion, with a warning message (in which case the Top Rail vanishes from the railing); 
  • However, if the Top rail is the only element in the railing that has been used, Revit will not allow you to delete the type
  • Railing Supports behave differently (as they are not system families):  Revit allows deletion of the supports, with only a warning message

If you really wanted to, you could go through and manually delete all kinds of families  and types that are used in other families, but it is a laborious process, which makes minimal impact on a project size.

Reducing Family sizes

A similar technique can be used in Revit family editor to remove those unwanted nested annotation families - in particular, Section Heads.  You cannot delete them from the family browswer, so you have to go to Section Tags under the Additional Settings part of the Manage menu - and set the section head and tail families to None;  then you can purge them.  This makes a tiny difference to the family size, but if you do the job once in your family templates that difference will affect many subsequent families.

Sunday, 5 October 2014

Revit 2015 Shared Parameter Tool Tips

Isn't it great that you can add tool tips to parameters in the family editor?  It is a nice new feature that should help us to manage all those cryptic parameter names.

Shared Parameters

You can also add tool tips to Shared Parameters.  But, you can only add them at the time of creation of the shared parameter - in the Shared Parameter edit dialog box (not in the family parameter dialog box).

Click on the Edit Tooltip button and then add your description

Once you have created the Shared Parameter, you cannot modify the tooltip - try clicking on the Properties button:

It shows the tooltip grayed out, and the Edit Tooltip button has gone.

Project & Family Parameters

In the project or family editor, when you try to add a new Shared Parameter, it lets you do so, but only shows the tooltip that you have already created (if you did so)

 If you choose a Shared Parameter that does not have a tooltip, then it displays a tooltip "Shared Parameter"

If you create a Project Parameter or Family Parameter, then it lets you create and modify the tooltip at any time later.


You cannot add Shared Parameter tooltips later, and you cannot modify the tooltip later.  That means you have to get it right first time.
You cannot edit the shared parameter file externally either - I tried it even though every bit of Revit advice tells you never to do that.

What a shame!  This means that we cannot retroactively make use of this new feature where we already have large Shared Parameter files set up.  It also means that anyone who has set up a standard SP file cannot make use of the feature (eg. ANZRS).

What this also means is that your Shared Parameter tooltips must be very specific because you cannot add tooltips when you use a shared parameter in the family editor (or project).  For example, if you create a SP called "Width_Two" then you have to define its tooltip at creation, not when it is applied to a family.  You might have an L-shaped object where Width_Two means the width of the short leg.  You might also have a double-panel door where Width_Two could be the width of the smaller panel.  That would mean you could not create SPs for multiple uses on different categories or situations (maybe a good thing?).

If I am wrong about this, or anyone knows how to get around it, I'd love to hear from someone.

Saturday, 20 September 2014

Weird Revit Railing Stuff - Part 3 - Rail Offsets

Rail Offsets

Following on from my earlier post (Top Rail Transitions) about the subtle differences between old and new style railings, here is another weird difference.  In my attempts to get the transitions working properly on the inside railing, I played around with the railing offsets in plan at the stair half landing.  Each railing type gave different result - rather than try to explain what is happening, here are the offsets and outcomes for each type in the situation where the risers on a half landing are staggered by one tread (which should be buildable).

Old Style Railing (no top rails)

When the railing sketch exactly follows the edges of the stairs and landing, none of the types work, as we have seen previously.  

So, with the old style railing (no top rail), I first offset the sketch line on the landing by 16mm.
 This was enough to get the transition to the upper run railing section working, but not the lower run.
16mm offset landing sketch line
Section view - 16mm offset landing sketch line
 So then I tried increasing the sketch by 1mm to 17mm, which fixed the lower transition too

 Sadly the mitred joints show in 3D views
17mm offset landing sketch line
Section view - 17mm offset landing sketch line

From the section it can be seen that the transition only works because the 17mm allows the underside of the sloping rail to get to the correct height before the 50mm width of the rail turns the corner (different size rails and different stair angles would need different offset dimensions).

NB. notice how the section view shows old style rails solid in elevation when selected.

Top Rail Only - Transition = Simple

16 or 17mm offsets do not work at all for the new top rail type, even though the geometry is exactly the same
Section view - 17mm offset Top rail only
If you increase the offset by another 7mm (to 24mm) it still does not work

In this example it even leaves a gap between the horizontal and upper sloping rail (with corresponding warning message).  There is a mismatch between plan and 3D view.

 However, add another 1mm to the offset (up to 25mm) and it works again
 And it even works in plan
And in 3D it does not show the mitre joints (unlike old style rails)

So it seems that you have to increase the offset in plan by another 8mm to make it work as a Top Rail compared to the old style railings - even though the geometry should work without that 8mm.  WHY the difference?

But it gets worse . . . . .

Top Rail Only - Transition = Simple

Try changing the Top Rail to have "None" transition, and it breaks again - this time leaving a gap between both sloping runs and horizontal landing rail.

At least the broken plan section and 3D view are consistent (unlike the broken rail Simple transition where plan and 3D do not match)

Just add one more mm and it behaves again.  Crazy Huh?

The moral of the tale is that there is no consistency between old and new style railings; nor between different transitions in the new style Top Rails;  and quite often no consistency between plan, section and 3D.  And if you try playing around with these same settings you will most likely get different results to those shown here - because there are so many hidden settings that it is really tricky knowing which change you made does what.  Each time I tried this on a different stair in a different project I got different results.

At worst, I would like to see the new Top Rails achieve successful transitions within the same dimensions as the old railings.  At best I would like to be able to make successful transitions within much tighter constraints as they can actually achieve on site.

Top Rail Properties in Revit Railings
Weird Stuff in Railings - part 1 - Top Rail Transitions
Weird Stuff in Railings - part 2 - Railing Extents 

Sunday, 14 September 2014

Weird Revit Railing Stuff - Part 2 - Railing Extents

We often create railings that consist of only the handrail, be it the old style rail or new (v2013) Top Rail or Handrail.  The reasons for this are varied:
  • Often we are only interested in seeing a railing in plan
  • Everyone knows that balusters in Revit railings are um, tricky, to say the least!
  • Balusters, fixings, transitions etc are incredibly difficult to get right in Revit railings so many people just do those in 2d in a section view.  Yes, very "un-Revit", but pragmatic
In Revit pre v2013, with the old style railings, this did not cause any problems aside from the usual ones of controlling railing locations.  However, from v2013 onwards, you can get all kinds of weird stuff happening, particularly with railing extents  . . . .

Top Rail Railing Extents

With the new style of v2013 railings you can still use the old method of horizontal rails, described in my earlier post on Top Rails in Revit Railings.  If you do this, there would be no issues with railing extents.
If your railing has only a Top Rail, but no balusters, no supports, no old style rails, then it will cause problems.
No rail structure, no balusters
In this situation, the actual railing containing the Top Rail may have large extents:  In v2013 the extents will always include the 0,0,0 origin point in your project; in more recent versions the origin may vary, and may depend on whether the stair has been moved from its original location.

This problem shows up in two situations: groups and selection by click and drag.


If you create a group that contains a railing with only Top Rails, the overall extents of the group will include the extents of the railing, and hence your project origin point (in v2013).  This could result in a group with very large extents, causing all kinds of confusion.
In Revit Sundial (test version of Revit 2015 subscription enhancements, yet to be released), the code has been changed a little so that the extents do not include 0,0,0 but instead seem to include the previous location of a stair/railing that has moved.  Each time you move the stair/railing, the extents remember the previous location.  How weird is that?  Not sure when this was changed.


If you select a stair and railing by dragging across them from left to right (to include them wholly), it would normally include the stair, its sub-components, the railing and its sub-components (inc. top rails).  NB. check this in the filter selection

However, if your railing has only Top Rails, but no other sub-components, the extents of the railing would most likely be bigger so that the railings are not selected.  This is very confusing because the Top Rails are selected, which visually looks like railings are also selected - check the selection filter to see that they are not.
If Top Rails are selected, they will most likely display pins;  you will also notice that the Create Group command is greyed out - this is because Revit will not allow you to create a group that contains Top Rail sub-components, but not the parent railings.

In this situation you would need to manually add in the railings to your selection.  You might be tempted to select by dragging from right to left, which would capture the railings because it crosses their extents - but any good Revit user knows that this is seriously bad practise because it could also include hidden elements (That is the number one Autocad habit that new Revit users must unlearn!).  Once the parent railings have been added in to the selection set, the Create Group command becomes available.

Good news:  In Revit Sundial, the list of railing sub-categories has been tidied up so they are listed together by adding a "Railing:" prefix (like the stairs).  Its only a little thing, but it makes life easier - thanks Factory.

Top Rail Properties in Revit Railings
Weird Railing Stuff:
Part 1 - Top Rail Transitions
Part 3 - Railing Sketch Offsets & Transitions