Constraints are not satisfied: moving freely but the constraints

[luigi_mereu]

I think the video is self explanatory.

Can't get this model to work. 

I've uploaded the video where the constraints are having a strange behaviour. There's also the model attached. 

[RDAOU]

@luigi_mereu 

That happens when you nest components/families and constrain such nested components using dimenssions associated with their geometry rather than reference planes in such families. When thats the case, you will receive a prompt similar to the below when you edit or flex the family using its parameters

To fix, you need to

• remove those constrains
• align/lock or place the dimensions to Reference Planes inside those nested families. When you hover over the family, you should get a tool tip telling you what you will be locking or placing a dimension to...Use TAB kew to cycle through the options and Pick a Reference plane. 
  • If you name such reference planes in the nested component, it will be easier for you to identify it in the host family.

[luigi_mereu]

I don't think that's the case.

I've created ref. planes inside the angular piece and aligned the element correctly. Once I go back to the family the problem remains the same. I can still move freely the plane with all the elements but god forbid if I change manually the measure in the parameter.

I've tried every possible combination of align and locked measure I could think of. I can't find any sense at the behaviour mentioned. 

[RDAOU]

@luigi_mereu 

Sorry to say but yes, it is.

I just opened the family you attached and did not need to dig too deep to find an example. You have done exactly what I mentioned in my previous reply and the opposite of what the pop-up warning recommended not to do. Most of the components are constrained using locked dimensions to the geometries of other components rather than to planes and reference planes. This explains the odd behavior you described.

You practically have 2 or maybe 3 options:

• Option 1: Model it properly.
• Option 2: Keep trying with it as is until you think it is stable.
• Option 3: If it doesn't need to be parametric simply make it non-parametric then it does not matter what you lock dimensions to

If you choose the second option, I guarantee that at some point, when the input is undesirable for the family, it will break.

[luigi_mereu]

That's not why I asked for. I know there are some non-canonical constraints and I still believe you can make this model working the way I've created it. It's way easier if you make constraint between objects that need to be together. Hence you don't have to worry about them if the first constraint works fine. 

The question was about the way of thinking of the program. Why you can move it freely with the program understanding everything but you can't work with parameters without having a solution from the program itself. I think it's time to have more sofisticated softwares than this. 

By the way I succeded doing different combination that really have barely sense at all. If someones asks me how did I do it, I wouldn't know how to explain it.

So no, there wasn't a proper solution. 

[SteveKStafford]

Revit places a higher constraint relationship or priority on Reference planes (and lines) than other elements. In general:

• build the bones of a family first (reference planes/lines)
• then add muscle (dimensions)
• finally the skin (forms/voids).
• Test the flexing of a family before adding any skin, make sure the skeleton works properly before adding the skin.
• When using align/lock relationships those should be between form sketches and reference planes.
• Nested family relationships should be reference plane to reference plane.

The more consistent you are with following that hierarchy the more reliable/predictable the content you make will be.