Correcting the CL symbol in mirrored Revit links

The automatic 'Centreline' capability on Revit dimensions can be really annoying when they pop up unexpectedly.  But when you actually need them it is very useful to be able to just change a property of the dimension family to make the CL symbol appear.

I have seen people just placing many instances of two little pieces of overlapping text, one being C, the other L - all because they didn't know about this feature.  That is criminal!  And its a nightmare when dimensions need to be adjusted.

Mirrored Centreline Dimension Symbols

What happens when you mirror the elements and dimension?  In most situations, Revit handles it perfectly well, because the CL is a symbol family, and Revit automatically corrects the symbol orientation.  However, there is one situation where it does not work:

• If the dimension is in a linked Revit file that has been mirrored - normally you would not see the annotation in the linked file, but if you set the view properties for that link to be 'By Linked View', then the dimensions in the mirrored linked file become visible.

• In this situation, the symbol may not be displayed correctly, depending on how the symbol family was created:

CL symbol in Mirrored Link

• The OOTB centreline family is actually made up of arcs and lines (not text) - this symbol does not display properly in mirrored linked files.

I was recently asked to solve this problem, so I searched high and low for settings in the dimension and in the symbol family that might solve this.  I found nothing.

• Next I tried converting the symbol from lines to actual text in the family - I'm not sure why it was originally done as lines anyway?
• This needs to be made up of two pieces of overlapping text - in the symbol family, not the project file.
• In this example I made the text using a font that was clearly not lines - 'Algerian' was the first suitable windows font that I found, to make the demo clear.

• In the original file it looks fine, as expected.
• Once I looked at it as a mirrored linked file, another problem showed up:
• Each letter was displayed correctly, but displaced sideways

• Aha, it must be the text justification, I thought.

 

• But no, that made no difference whatsoever when I tried centre, left or right Horizontal Align.  Revit is just mirroring each piece of text around the symbol centreline, then flipping the text back again around its own axis.

Weird Workaround

So what was the solution?

• Edit the text in the symbol family - Put a space after the C and one before the L.
• Shift the letters accordingly. 

• It wasn't perfect to start with, so I had to shift the text around a bit, or add a second space after the L

Weird behaviour in Revit requires weird thinking workarounds!

Weird Stuff with Global Parameters in Revit

Following on from my earlier posts about transferring global parameters between Revit projects, and deleting global parameters, here is some quirky stuff that happens when you are working with Global parameters:

Weird Behaviour & Bugs

1.   Duplicate Labelled Dimensions

If you add a dimension to elements that already have a ‘global parameterised’ dimension, the new dimension automatically takes on the same parameter, without you realising.   If you subsequently delete that dimension, you get a message saying ‘A Dimension that is labeled . . .’  Unconstrain to remove constraint

• If you expand the warning, it tells you what the Parameter label is

•  It does not tell you that you are deleting a secondary (redundant) dimension with the same label as another dimension, which still remains in the model

 2.  GP Equals Constraint Conflict – Fixed in v2018 (?)

If a dimension between two elements (say gridlines) has a GP associated to it, then you place a dimension between the grids and an element midway between them, you would expect to be able to change that dimension to ‘Equals’. Illogically, Revit does not allow this – it warns you that it needs to remove the constraint. Unfortunately if you go ahead, it removes the GP constraint but keeps the Equals constraint – which is not very helpful as you now need to guess which other constraint it removed. It does not highlight the other constraint

• I recommend that you cancel, then figure out where the conflict is - do not click on 'Remove Label'
• One solution to this is to create another GP that is a fraction of the original one (half, in this example), and apply that to the secondary dimension, instead of an equals constraint

• Another solution is to put the equality constraints between other elements that are in the same location but not GP dimensioned – eg between two walls that are aligned to the gridlines.
• NB. This problem does not occur if the GP associated dimension is a reporting parameter.
• This bug is reportedly fixed in v2018, but I have not had time to test it yet

3.  Edit Witness Line Bug

If you associate a GP to a dimension, and then subsequently delete the dimension, Revit will ask you if you want to unconstrain (remove the constraint) – this is good behaviour. However, if you edit a witness line instead of deleting the dimension, Revit removes the GP association (as you would expect), but does not ask if you want to remove the constraint – effectively hiding the constraint. This is really bad behaviour by Revit, because it means you can end up with lots of hidden constraints, which catch you out later on. Autodesk refuse to accept that this is an inconsistency in the software that should be changed. I recommend that you never edit a witness line on a GP associated dimension.

4.  Shape-Handles vs Calculation

If you have a family that has grip handles when placed in the model, those handles can be ‘hidden’ when GPs are associated with certain properties in the family. This happens if the property is used in a formula that drives the geometry related to the shape-handle:

• No GPs associated – shape-handles available

 

• GP associated to a property used in width formula

• In this situation, it is better not to associate the GP directly to the property. Instead you need to use a dimension with a reporting GP associated to it. Then the association is far enough removed so the shape-handles are unaffected.

5.  Circular Chain of References

• At some point you are likely to encounter this warning dialog:

 

• I strongly recommend that you do not click on ‘Resolve’ because it will remove a formula, but not necessarily the one you are expecting, nor the one you just added that caused the problem. Instead you should cancel and figure out what is causing the problem – first click on ‘Expand’ to see if you can figure out the conflict; although using the ‘Delete Checked’ option does not seem to resolve anything (the same dialog just as likely pops up again), so you will then have to cancel anyway.

6.  Change Instance to Type

If parameters are changed from instance to type in a family, then reloaded into a project, you may get this message if the parameters had been associated to GPs

• You then have to reassociate the property to the GP – but it is easier to do as it is likely to be only one type property to relink

7. Duplicate Type Loses Associations

If you duplicate a family type that has GP associations to any type properties they lose the associations.

Weird Revit Railing Stuff - Part 2 - Railing Extents

Go to Revit Stair & Railings Index Page

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

Go to Revit Stair & Railings Index Page