Parametric Revit Family - Parameters sometimes work, and sometimes don't

[Anonymous]

I think I'm going insane.  For some reason, the attached family will not behave consistently.  Here is the problem.  I want the width to be changeable.   And generally it works well.  If I go from 16' to 15' it's fine. If I make a large change though, it breaks.  So from say 16' to 3'.  YET.....  If I slowly change the width from 16' to 15', then 15' to 14', then 14' to 13' so on until 4' to 3' it will work.  I don't understand this!  This means there is nothing wrong with the framwork and parameters nor the model elements, yet it breaks sometimes. 

Does anyone want to take a look at this and give any suggestions on what is happening.  It boggles my mind and I've spend hours trying to fix this behavior.  In the end I'm trying to use this same trim family as a nested family in an arched door opening and in a garage door family.  This means it's width range should be between 2' to 20' or there abouts.  And, like I mentioned, the family does work with those width values, as long as you coax it there in increments.  Which is something you can do in the family editor, but you cannot reliably do when loading a whole bunch of family types nor can you control what the end user will do.

[barthbradley]

You have no parameters to control the arch.  

[ToanDN]

He has Arch Height.

[barthbradley]

I'm not following you, @ToanDN. The issue is the arch isn't flexing properly. No?  If so, the arch need to be parameterized just like I illustrated.  Otherwise, it's going to be problematic.  

Maybe I reading the OP wrong.  Wouldn't be the first time. 

[ToanDN]

@Anonymous It will break when the width is less than the arch height.  Make sure you won't let it happens either via a formula to restrain the parameter or by slapping your users as a memorable warning.

@barthbradley I only pointed out that he did have the parameters and the necessary reference planes to control the arch.  It didn't break here when I changed the width abruptly from 16' to 2' (as long as the width is larger than the arch height) so I am not sure what the problem is.

[Anonymous]

Yeah, so I constrained the ends of the arc to the width reference planes and the arch height plane.   So it should have no choice but to do as I ask.  Haha.  And it does work.  It's just large changes that seem to trigger it to break.  It's the darndest thing.  At first I thought maybe it had something to do with it growing past the host object, but I made that much bigger and still had the same problem.

[Anonymous]

Yeah, I can't tell if it's the arch that's fouling it up or not.  When I click through the error and let it remove the constrains it says are conflicting, then it releases the sides of the trim from the width reference planes so that the vertical trim pieces stay and the reference planes change position.

[Anonymous]

@ToanDN, are you saying then that you can't get the family to break for you when you make a large change?  I'm in Revit 2017 what are you opening it in?  Could it be a bug that is fixed in a later version?  I've tried and tried again and it still breaks for me, specifically when going from 16' to almost anything in the single digits.

Also, good point about the width and arch height, I should put a limiting parameter in there.

[barthbradley]

Yeah, I know exactly what you're going through. Been there. 

Build the family exactly the way I showed you, and you won't have a problem anymore.  Guaranteed. 

[Anonymous]

@barthbradley, K I'm going to re make my reference skeleton and parameters and let you know how it goes.  I love making families, but flexing them gives me anxiety.

[ToanDN]

I tested it in Revit 2017.

[barthbradley]

Here’s a 2017 version.  I have added a trim to it.  I suppose if you tried hard enough, you could break this one.  If you do – you own it. 

[Corsten.Au]

There are ways to add contraints and limitation so that
the family will work no matter what inputs one users put..
cause those limitations will make sure that the family just works..

Bit of learning curve how to implement those constrains... 

Some examples..

a. Constraining Min/Max Values
if ( <condition> , <result-if-true> , <result-if-false> )
Use Constraint for minimum

2. conditional statements like fixing height or width
or particular distances .. giving few options.
1m, 2m, 3m... ( no other inputs valid )

[Anonymous]

@barthbradley

This is delayed a bit, but I really appreciate your help on this issue.  I was looking over the family you sent, and I'm curios why you used this if statement in the h parameter definition:  if(1 = 1, Spring Offset Ctrl, Spring Offset Ctrl) instead of just setting h=Spring Offset Ctrl

What is the advantage here of the if statement?  Basically you set a condition that is always true, but even if the condition wasn't always true, then the then and that values are also the same.  It seems like a real long winded way of saying always use Spring Offset Ctrl.

[Anonymous]

@barthbradley

I'm also curious as to why you base the Spring Offset Ctrl off of the wall thickness rather than some percentage of the opening width value.

[Anonymous]

@barthbradley

I think this family is going to make me lose my mind!   I changed it so that it was like you instructed.  Attached here is both my original family and the family with your instructed changes.   They both behave (or rather misbehave in the same way).  They break if the width is changed abruptly from 2' to say 16'  It doesn't matter how I build them.   It's so annoying because if you just change the width in small increments you can get from 2' to 16', no problem but making the large jump is what kills the thing.  It's completely illogical.

I think it has something to do with the sweep because in both cases if I take away the sweep and just flex the "framework" then there is no error.  Problem is that I cannot make the frame I need without the sweep.  

Also, did you test my original file (of the one attached here)?  Did it break for you when jumping from 2' to 16' or vise versa?  @ToanDN mentioned that it did not break when he made the large jump, but I have tested the family on two other machines in 2017 and it breaks in both places.

Anyways,  if you can think of anything that might be causing this, I would be soooo happy to hear it. 

[barthbradley]

---

@Anonymous wrote:

if(1 = 1, Spring Offset Ctrl, Spring Offset Ctrl) 

What is the advantage here of the if statement?  

---

It makes the parameter unavailable to the user in the project (e.g. it’s grayed out in the project).  

If you find this post helpful, please click on 'Accept as solution'. 

[barthbradley]

---

@Anonymous wrote:

I'm also curious as to why you base the Spring Offset Ctrl off of the wall thickness rather than some percentage of the opening width value.

---

"Spring Offset Ctrl" is not based off of the "Host Wall Thickness". It's just in the same group ("Constraints").  You can group however you like. Further, "Spring Offset Ctrl" enforces a minimum "Spring Offset", which is 6" in my family. You can use whatever minimum you want to enforce by changing the 6 to another number.  But understand that if it’s too small, the arch may collapse in on itself and break – depending on the width of the opening.  “Spring Offset Ctrl” is a safeguard to prevent a user from accidently (or purposely) entering a “bad” value in “Spring Offset”. You need to experiment to determine what that “bad” value is. 

If you find this post helpful, please click on 'Accept as solution'.  

[barthbradley]

---

@Anonymous wrote:

@barthbradley

I think this family is going to make me lose my mind!   I changed it so that it was like you instructed.  Attached here is both my original family and the family with your instructed changes.   They both behave (or rather misbehave in the same way).  They break if the width is changed abruptly from 2' to say 16'  It doesn't matter how I build them.   It's so annoying because if you just change the width in small increments you can get from 2' to 16', no problem but making the large jump is what kills the thing.  It's completely illogical.

I think it has something to do with the sweep because in both cases if I take away the sweep and just flex the "framework" then there is no error.  Problem is that I cannot make the frame I need without the sweep.  

Also, did you test my original file (of the one attached here)?  Did it break for you when jumping from 2' to 16' or vise versa?  @ToanDN mentioned that it did not break when he made the large jump, but I have tested the family on two other machines in 2017 and it breaks in both places.

Anyways,  if you can think of anything that might be causing this, I would be soooo happy to hear it. 

---

Well, I can clearly see that it is not constructed exactly like mine, but I can flex yours. I can define 2 types; one with a 16’-0” width opening, and one with a 2’-0” width opening. But, I suppose I could break it, if I tried hard enough.  And, I can see why it would break too -- because it isn’t constructed like mine.     

I’d suggest re-examining the family I sent you.  Look at how I’ve constrained the arch. I constrained it inside sketch mode with a labeled radial dimension. The arch is NOT constrained by aligning and locking it to the Ref. Line!  Additionally, you don’t have the arch sketch “end tips” properly constrained in the x and y directions.  

As a side note: the Ref. Plane that “d” is pulled from should have its “Is Reference” parameter set to “Not a Reference”. 

If you find this post helpful, please click on 'Accept as solution'. 

[barthbradley]

Still no "Likes" or lil' green check mark from you.  Seriously? What's a guy got to do to be noticed by you? The "Bend and Snap"? 

Just saying....