families coming in at varied elevations

[MKFreiert]

I'm working on family quality control, and running into an interesting series of glitches.  

For most families, the "Elevation" as they're inserted defaults to 0, and that represents the bottom of the family.  Some families however come in at another seemingly random (although occasionally useful) height, for which I'm not seeing anything related within the family, or the instance parameter that drives their elevation in the family doesn't change it in a project.

examples:

-a grab bar comes in at 3'-0" in the project (lovely, right where I want it to default to) but in the family it's located at 0'-0" (family ref level at 0, bar located at that, insert it into any project, it lands at 3'-0", but editing the elevation parameter will move it back to 0, new insertions always land at 3' though)

-another grab bar (vertical) comes in at 3'-0" but it's to the center of the bar instead of the base, and the instance parameter doesn't change its elevation at all, while the level offset does, despite the opposite holding true within the family.

-another family comes in with the top reference plane treated as the bottom of the family, so that while it's at ~2' AFF its level offset is 4'10"

There are enough variations to this that I'm not certain posting a family (or 5) would clarify anything, I'm more looking for information on how revit defines the insertion level for families, and how that can be edited.

These families unfortunately have come from all over as folks developed their own families as needed. 

[MKFreiert]

ok more coffee for me, I'd forgotten about the "defines origin" toggle, but where does this mystery insertion elevation come from?

[constantin.stroescu]

The Insertion Point of the  object made in Family Editor is determined by  the intersection of three Perpendicular Reference Planes:

1. first Reference Plane : Center (Front/Back) - visible in Floor Plan- Ref.Level as a X axis 
2. the second Reference Plane : Center( Left/Right) - visible in Floor Plan- Ref.Level as a Y axis
3. the third Reference Plane that fix the elevation of the point :   visible in Elevations Views  . This third Reference Plane is, usualy , more dificult to be found because it is hidden by a  Level Line , a Face or Ceiling profile line. Use TAB in order to find it...

All these three Reference Planes  are , in Properties, checked as Defines Origin

In Properties (Family) there are a set of options that controled how the object is inserted into Project : Properties > Other....the first two options:

1. Work Plane Bassed   - if checked = the object , in Project, can be placed on any Work Plane or a Face ... if unchecked  = the object, in Project, can be placed only on Levels ( or relative to Levels by using offset)
2. Allways Vertical   -   if checked = the object , in Project, will keep allways its vertical position   -  if unchecked  the object can be placed normal on any face or Work Plane

[MKFreiert · Accepted solution]

Figured this out by comparing families against each other extensively. Specifically looking at face based, wall based and unhosted families as groups and looking at what they were and weren't each doing with bits that behaved as I wanted.  

For wall hosted and unhosted families:

If there is a "Bottom" plane defined & as origin, the location of the Bottom relative to the Ref Level determines the default insertion height.  Within the family changing Ref Level elevation from 0 will result in this distance not relating to the level the family is placed on as clearly.  

For face based families:

The "Default Elevation" parameter is... the default elevation.

I feel silly now, and have refined (and made longer, sigh) the quality control process.  Some of the bottom planes weren't set as defiing origin, some planes that should have been Bottom, were set as a Center (which in initial checking made sense, so I missed that it wasn't right) and some of the families were built constrained to the Ref Level (or partially so) which seems to mess the above rules up a bit.  Entertainingly, one dev was kind enough to list themselves as author on families that contained each of those bloopers, so I know who to blame for a solid third of the mess :/.