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.


Summary


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.




Reference:
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.

Groups

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.

Selection

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

Tuesday, 9 September 2014

Weird Revit Railing Stuff - Part 1 - Top Rail Transitions


In my previous post I described the properties for "Top Rails" in the new railing types.  Now it is time to show some of the weird differences between old and new horizontal rails.
Goose-neck Transition

Rail Transitions

The Revit help describes the "Transition" property as:
         Specifies the type of transition used in the handrail or top rail.
  • None. In a stair system that includes a landing, the inside rail will end at the nosing of the first or last tread on the landing
  • Gooseneck. Used where there are tight transitions and complex rail profiles
  • Simple. Used where there are tight transitions with a circular rail profile
What the help file does not explain is the subtle differences between these 3 options and the traditional rail transition (over which we have no control).  Nor does it explain how we further manage these transitions.
Here are some examples of what transitions you get on a half landing where the railing turns through 180 degrees on the inside.  In this example the top riser of the lower run aligns with the first riser of the upper run (not good design but common enough in tight fire-escape stairs):

Old Style railing (with the rail set to represent the handrail but with no balusters, for clarity).  Note that the rail actually breaks with vertical cuts.  No options for transition.

Top rail only - None Transition.  Revit does a slightly better job with the joins for the upper run, but still fails on the top of the lower run (but the cut is in a different location to old style railings).  However, it gives a warning message, saying that the rail is not continuous.


Top rail only - GooseneckTransition.  Would you show a railing like this to your builder?  No!  The Revit help file shows a 90 degree corner where it looks marginally less ridiculous

Top rail only - Simple Transition.  This looks exactly the same as the None transition, but does not give a warning message - so this is probably the better option to go with.

Old Style railing with the a one tread stagger in the riser alignments - better design but Revit still cannot handle it even if a builder could.

Here are the four options at larger scale with a one tread stagger of the risers on the landing:
Old style railing
Top Rail None Transition
Top Rail Gooseneck Transition
Top Rail Simple Transition

If you add both the old style rail and the new top rail at the same height, Revit does not give any error messages - it will create both occupying the same space, but with different transitions.  This won't show in plan but looks messy in 3D (even more so if you made the transition a gooseneck.
Old style railing and top rail combined


This differentiation is further complicated by the plan offsets of the rail relative to the stair edge.  All the above examples were done with the centreline of the rail being coincident with the stair edge (where the railing sketch line goes by default).
Railing centred on stair edge
 
If you change the plan offset so that the railing sits over the actual stair treads (and landing), you would expect the railing transition to work better as it has a little more length to make the turn in (half a railing width).
Sometimes it works better, and sometimes not. . . . .
(NB.  In order to make that horizontal offset, it is somewhat confusing - see below **).

The old style railing behaves somewhat better when you offset the railing - it gets the upper transition right but still can't cope with the lower transition even though it is plainly "buildable" in real life:
Old style railing offset from centreline
The new Top Rail option finally works in 3D when you offset the top rail by half a rail width (for None and Simple transitions).
 Top Rail offset from centreline





Aaaargh!  When you do that it gives the Non-Continuous rail warning message.  You had better check your plan view to see what it has done - yes, it breaks it in plan to give a totally unacceptable representation.
Non-continuous rail in plan
 The gooseneck transition works fine in plan, but is crazy in 3D - unacceptable again.


So it looks like we are snookered!  None of the options work effectively in both plan and 3D.  There will be more on this in a future post - perhaps a solution?  There is also much more to know about weird railing behaviour in Revit . . . . (to be continued)

How to change the rail horizontal offset

Warning: the next section will give you a headache.

**  To change the plan offset of a rail is confusing:  There is an instance property for each railing, but using instance properties for such global changes is a nightmare for inconsistency.
Not only is it unwise to use the "Tread/Stringer Offset" instance property, but it has a default value of 25.4mm (which is a nasty one inch in imperial units) - a value that you cannot pre-set, so you always get 25.4, which really should be set to zero for consistency.
There are three type properties you could use:
For the old style railings, you have to go into the Rail Structure settings and find an Offset property for each rail.  This is fairly logical (albeit hidden away) and it allows different offsets for each rail.

For the new style Top Rails, you can change the "Baluster Offset" which also moves the top rails along with balusters.  NB. this setting has absolutely no effect on old style rails.

In addition to this setting, there is also a "Hand Clearance" type property belonging to the Top Rail type , which cannot be accessed from the Railings type dialog box - you have to find it in your project browser.  This value will offset your top rail sideways, and it will change the "Projection" property (clearance plus handrail size) - so for a top rail on a stairwell it could be zero or -25mm to make it centred on the sketch line;  for a wall mounted handrail it could be about 50mm  but you would be better off using "Handrails" for that purpose, which have their own hand clearance property - it would be easier for users to understand if the two sub-categories are kept for two distinct purposes.

Headache yet?  No, well in that case you need to be a juggler, and keep those 4 horizontal offset properties coordinated for every railing situation you have - and you might just make it as a Revit model manager, or even a BIM manager.

More Weird Railing Stuff:
Part 2 - Railing Extents (Top Rail only)
Part 3 - Railing Sketch Offsets & Transitions