Light Fixture Grid Positioning and Wires

I've seen some lighting content that has been modified to make it easier to align with acoustical ceiling tile grid patterns. For example this stock family is the Downlight-Recessed Can.rfa with some reference planes added so we can snap to the grid during placement, or use the Align tool easily afterward.

I didn't bother to assign any parameters to control them. I can use them to fit the fixture in a 2x2 grid or use the Align tool later to position it in the middle of a 2x4 grid. It might not be obvious but I can use one reference in a family to move the family over by selecting another part of the family as my second pick. This means it is easy to just set the reference planes at a fixed position and use the family's own references to move it over if necessary. It just means I don't have to have parameters to decide if the fixture is meant for a 2x2 or 2x4 grid. All this is seems good at first except when it comes time to add wiring to the fixtures.

These helpful reference planes end up affecting where the wire's graphical ends terminate. The fixtures are connected to their wire but they just stop at the extents defined by the reference planes. Not fun when you have to adjust a lot of wires to get closer to the fixture. This means Reference Planes aren't ideal for this task. This is what the family looks like if I use Reference LINES instead.

I've held the same attitude toward adding dimensions in this example too, with much better results as well! We can set the reference lines to Strong (IsReference) and uncheck the Visible parameter. They won't be visible when you select the family but the Align tool will "see" them and Revit will highlight the ceiling grid pattern when you place the fixture too. Fwiw, if you leave it checked they still won't be visible when you select the family.

Fwiw, Model and Symbolic Lines that are Strong References and assigned to Invisible Lines provide the same result. You can uncheck the Visible parameter so they aren't visible when you select the family.

(This is based on working in 2014, it does not work in 2012 or 2013. Nothing seems to resolve it in those versions)

Naming a Reference Plane

I read recently that just adding a name to a reference plane would cause it to be "strong". The notion of Strong, Weak and Not a Reference are related to the IsReference parameter, which I've written about before. It's my observation that adding a name to a reference plane has no impact on it's behavior in a project. To test my belief I created a small family with a collection of reference planes with various combinations of Name and IsReference parameter values.

The reference plane on the far right is set to Not a Reference and has the Name No 3. Its the only one that is invisible in the project environment. The two on the far left have IsReference values (Weak and Strong) but have no Name either, they still are detectable in the project. I sketched dashed lines from the detectable ends of the reference planes. The dashed line on the far right is sketched where the reference plane should be but I couldn't snap to the end because it isn't detectable there. I also added a dimension string across each detectable reference plane.

I think my beliefs are intact, just adding a name to a reference plane does not alter its IsReference conduct in a project. When we create a new reference plane Revit assigns Weak Reference to its IsReference parameter. If we copy a reference plane, those that Revit lets us copy, it also assign Weak Reference to the copy.

Window or Door Frame Positioning

We quite often want to be able to move a window or door assembly back and forth within a host wall. This is easy to do as long as the assembly is moving "in" but doesn't need to move beyond the host in the opposite direction. A relationship between reference planes does not generally like to be reversed. We usually get yelled at with a message like this.

When we want the flexibility to move something from or toward something else we need to define an alternate reference point, reference plane in this case. If we place a reference plane in front of the exterior side of the host we can set it far enough away to provide enough room to move the assembly without generating an error message.

In the image above I can move the Frame Offset reference plane "outside" the exterior face of the wall by using a negative dimension value and toward the Interior by using positive values. The fixed dimension value of 12 inches defines the reference offset value I used in the formula column. This means when I enter zero for Frame Offset that the assembly will be flush with the exterior of the wall. Here's what it looks like using a negative 8" offset to move it outside, from the exterior face.

There are firms that use multiple walls to define the layers of what many people use one wall with layers for. When you place walls next to each other a door or window family is hosted by one of them. If you need to move the family "forward or backward" you need to be able to change the notion of what host reference plane is relevant. This is one approach to solving the problem.

Is it Too Late to Change

Whenever I spend time in the Revit Family Editor I run into past decisions. Sometime they are my own and quite often they belong to somebody else. I've always encouraged people to develop good habits when it comes to using and defining reference planes. I've even been teased about wasting time in a demonstration by naming each reference plane even though doing so wasn't pertinent to the topic. Habits...

I recently encountered a bunch of families that were built by a few people for their project. I was asked to make some changes so a part of the family could be scheduled separately. That meant making use of the concept of making a family "shared". A family that is nested into another is only treated as a symbol when we see it a project. A family that is nested AND Shared is loaded into the project as an actual separate family (appears in the project browser) as well as being visible as part of the host family. This special condition allows for scheduling nested parts as though they are unique parts, apart from the host, as well as permitting us to place them separately. This subject could easily be few separate posts.

While I was digging in I noticed that few if any of the reference planes were named. I also noticed that most of them did not redefine the original reference planes so that they made sense in the context of the family itself. By that I mean that people will use the default Center (Front/Back) or Center (Left/Right) reference planes as a "left" or "right" or "front" or "back" or something...but not rename/redefine them as such. That means that when we examine a family the "center" (the reference plane that Revit thinks is center) of the family is really an edge or side. Autodesk's own content isn't immune to this either.

In this situation I thought like a mechanic, if I've already dropped the transmission I might as well fix some things that I can't get to otherwise, or "while I'm in here"...

Sadly if a project is using this content and people have done things like put hundreds, perhaps thousands, of them in their models, bad things can happen, when they are reloaded. As Mr. Maller says... it can be a "screwtastrophe". Families that have dimensions referencing them in the project will generate the dreaded "dimensions must be deleted" messages as soon as you reload them. Specifically if you change the IsReference status of a reference plane and reload the family Revit can't find the original reference plane anymore. Worse a family might shift its location, particularly if being swapped out for a different version.

I don't think it can be overstated or stressed enough, content needs to be created carefully and good habits need to developed and observed. It may not be too late to make changes but it can be painful.

Reference Plane Order

This is subtle. When you draw reference planes the order they were created plays a role in how a parameter will move them later. Draw two new vertical parallel reference planes, draw one on the left and then next to the right of the first. Add a dimensions and assign a label (parameter) to the dimensions. Flex the parameter value and watch the reference plane on the right move. If you have a lot of reference planes it can get confusing but this underlying behavior is lurking there.

You can force certain behavior by pinning reference planes, locking dimension or using the EQ constraint to force them to move equally about a center reference line. Like I wrote, it is subtle. Just keep it in mind while you do your family editing.

Two Minutes with Constraint Quirkiness

Okay it's a little more than two minutes but less than three. I've been running into a few things lately that I don't recall being an issue in the past. Then again maybe my memory isn't what I thought it was? Take a look at this image. Seems pretty straightforward.

I've got a pair of Reference Planes that I want to keep positioned on either side of a rail (as in stiles and rails for a door). In the past I could do what you see and then use the dimensions on the right to shift the collection of reference planes up or down a bit. Now I find that I can't unless I select all three together. In the past I just grab the one in the middle and use the referencing dimension to shift it up/down. Doing that now gives me some weird results. It's probably better and easier to explain it with a video so here's one at You Tube.

Invalid References

Ever see this message?

There are a number of reasons why it occurs. This is one example that can occur when swapping families. Not all families are created equal. Shocker I know...sorry. When you swap one family for another after applying dimensions you run the risk of confusing the dimensions. Let's take this simple family, GM01.rfa.

The Right and Left reference planes have corresponding names and IsReference settings. Now lets look at GM02.rfa

In this family I've made a mistake (on purpose of course), the Right reference plane has a different IsReference setting, it is set to Weak Reference. Technically the family is also a little bit wider than GM01, but that won't matter. If I've added dimensions that reference this family, as soon as I try to swap GM01 for GM02 I get the message I mentioned at the beginning.

The essence of the warning is that something has changed in a way that Revit can't transfer the dimension reference to the new object. The tricky part is figuring out what that "something" is. Sometimes it is how the family is made.

[Edit: Btw, I wrote, and scheduled this to post ahead of time, in response to an question via email and a last night I read a post at RevitForum.org that asks why almost the same thing is happening. Serendipity.]

Reference Planes Summary Post

Similar to the previous summary posts for Worksets and Shared Coordinates I've grabbed a number of past posts that have Reference Planes in common. I've put a link to each of them on the side bar.

Updated: August 9, 2013

Some of these might slip away from relevance but they do involve them.

2012 Small Collection of Family Editor Advice
2009 Family Editor - Bones, Muscle and Skin
2008 Door Templates

2012 Reference Planes and Wall Closure
2012 Reference Plane IsReference Parameter
2012 Grips Location Reference Planes vs Line
2010 Dept. of Subtle - Reference Plane
2013 Reference Plane Order

2006 Once Upon a Reference Plane
2011 Move Tool is Insensitive
2005 Family Origins
2005 Is You Is or Is You Ain't (IsReference feature)
2012 Invalid References for Dimensions

2006 Automatic Sketch Dimensions
2006 Once Upon a Workplane - Seeing is Believing
2010 IsReference Setting - Weak and Strong
2009 Grips in Families
2010 Flip Arrows and Exterior
2006 Face Off

2009 Air Terminal Doesn't See Grid
2008 Revit MEP - Air Terminal Troubleshooting
2008 Connectors and Their Arrows

2008 Standards - Everybody's Got Standards
2013 Is it Too Late to Change
2013 Naming a Reference Plane

Reference Plane IsReference Parameter

This post reiterates concepts I wrote about many years ago, regarding the IsReference parameter assigned to Reference Planes. The last post was titled "Is you Is or Is You Ain't", paying homage to Louis Jordan's tune.

IsReference settings break down like this:

Not a Reference - ignored by Revit in the project environment, still useful in a family to create "the bones".

Weak Reference - Seen in Project by dimensions, align tool, Revit favors Strong over Weak

Strong Reference - Seen in project by dimensions, align tool and Revit sees these first. (the black lines you see during dimensioning or using the align tool are the weak and strong references in action)

The nice IsReference names like Right, Left, Top, Bottom are all Strong IsReference choices. A reference plane should be named so it is clear why it was created, to you and anyone else later. Programmers comment their code, as much to help them remember why they did what they did as well as what the code is supposed to do. Same concept for these reference planes properties.

The names don't have to match but if the nice names do match what you think they should be, then great. If your families are meant to be interchangeable for other families, like from the stock library you should examine them to see how they are done. I've seen doors that were built opposite when compared with stock Revit doors and when users swap a stock door for theirs, the door panel flips over...ouch.

When Weak and Strong references are combined with instance parameters you see grips in the project environment. You can drag the grip to alter the family dynamically. If you use the Align tool on a weak reference the family "moves" toward the alignment edge. If you use the Align tool on a Strong reference the family "stretches" instead.

Last, these help Revit maintain orientation and two intersecting reference planes can define the X/Y origin. One reference plane in elevation can define a vertical origin. Theoretically a reversal of Right and Left reference planes in two different families would flip their orientation if exchanged for one another. Haven't tried that in a really long time so I don't know for sure that condition still exists.

Not finished apparently. Alex quite rightly reminded me in a comment that I forgot a goody! So he wrote:

"Another advantage of naming your reference planes using the preset Named Planes is that in a project, it will allow you to pick on the dimension grip and bounce between the Left, Right, and Centre options and ditto (depending on orientation) for Front and Rear, Top and Bottom."

Grips Location - Reference Planes vs Lines

When you apply an instance parameter to a strong/weak reference plane you'll get grips that let you alter the element directly in the view. When you do this to a reference line you get them too. There is a difference between the two Reference types in how they affect the grips though. Here's a pair of "desk" families. Compare the two forms in the image below, look carefully at where the grips are located in this one.

If you build the "bones" with Reference Lines and limit them to the size of the geometry they are meant to constrain you can define where the grips are displayed with much more control.

Don't worry, be "Grippy"!