Family array problem with family selector

[Anonymous]

Hi,

I've been creating some family with nested objects for a while, and I still don't get the logic with switching different types in it...

In this door, for example, I created an array to make them divided by a number parameter, and works fine with a single family type.... (left picture), but when I switch for a different panel type, it gives me a warning "constraints are not satisfied" and lies with the wrong array.... I checked that:

- Every nested family has the same type parameter assigned in the main family

- Every nested family has the same reference origin lines (so that they "share" the same placement origin")

What can I do to achieve that? Any ideas on that?

Thank you! 

[L.Maas]

Upload your family so we can have  look what you have so far.

[Anonymous]

Thank you, see what I'm missing!

[L.Maas]

I think the issue is that inside the array when you select family type you are going to switch between different families.

Switching within a single family works.

Probably the issue is that the other family elements will have different GUIDs so that will complicate Revit to maintain the constraints.

In your case I would advise to construct the different panels within a single family. You can use the visible parameter within the family to hide certain parts of the panel

[Anonymous]

I thought what you suggested in the beginning, we set this and other door families in the company with the same structure, in order to be consistent....
The panel with different visibility parameter could have been too complex for the basic Revit user, this approach is a good balance between flexibility, family size and usability....
I managed to do that with the simple family istance (user can easily switch between the door panel without breaking the family apart...), I don't know how to make it in an array... There's
A way to do it, I saw that, but currently I don't know how to reproduce that.. 😛

[kittugs143]

Hello,

With your attached family I have tried and it is working totally fine no problem in the array.

I hope you might develop that different panel type within the door family, so that is the problem when you give array it does not work properly and maintain some angle which we do not require,
Now make the panel type as a different family and load into door family then it works.

I hope by this method helps you if not just let me know.

Best regards,

G.Sivakrishna

Product Specialist - AEC

www.sivakrishna2013.weebly.com

If you find my post interesting, feel free to give a Like.
If it solves your problem, feel free to click Accept Solution.

[Anonymous]

@kittugs143

I took a look at your edited family, and I don'think that I understand what was your strategy...

I mean, I checked in the array, you simply duplicated the panel door family and replaced with the old one, but you actually didn't set back the "family" parameter... If you try to change the panel family, it doesn't give you an error because it simply doesn't change anything.....

[Sahay_R]

@Anonymous - go into your family and with the Preview Visibility on (look at the bottom of your screen) switch out the panel types and constrain them. Keep testing as you do so.

[barthbradley]

My suggestion is: don't array a family that is controlled through a Family Types parameter. This is problematic, IME. Instead, associate the nested family's parameters -- the ones that control it's sizing -- with Host parameters.  In other words: let the Host make the "family type".  

[Anonymous]

@Sahay_R alreday done that (it's my usual test to this kind of stuff) ... works well if you ACTUALLY don't change the size or the number of the panels in the properties... If you only switch the panel type, it would have worked....

But since you supposed to create several width sizes with different panel sizes, it would break each time....

[Anonymous]

@barthbradley

Actually the size of the single panel is associated to an host parameter in the host family (The basic dimension parameter are associated in the host family, and then there is another parameter with a formula to make them divide).. 

I don't follow your suggestion... can you explain better?

p.s. I experienced that selection nested objects is always a tricky choice to make in a family.. I didn't expect these problems with the array...

[ToanDN]

@Anonymous

Create another family and nest the two panel families in it.   Set up Family type parameter label there to select types.  Associate parameters as usual business.  Then, nest this family in your door family.  Array should work now because the type change happens at the source, not at the door family.

Another advice when you working with nesting family: set parameters of the nested families as Instance, not Type; types are driven by the parameters of the parent family.

[Anonymous]

Ah now I got it.. I tend not to do that, since this are panels used throughout all the catalog, but if it's the only way to make it work,
I will try and see.. I'll keep you update on this

[ToanDN]

See this revised family.  I didn't associate all parameters but they should work.

[barthbradley]

Not sure how to operate this family, @ToanDN. It broke for me.  Does it come with instructions? 

[ToanDN · Accepted solution]

This one does not break.  Try again.

[barthbradley]

Hunky-dory, @ToanDN. I think you deserve the cigar. 

[barthbradley]

@Anonymous: Be aware that when you use a Family Types Parameter in a Family; the drop-down will populate with every shared Family of that Category Type inside your Project.  In other words: if your Family Type Parameter is for "Doors", then the drop-down will populate with every shared Door Type that is in the Project it's loaded into.  This can lead to some grief.  As odd as this may sound, I'd recommend re-categorizing your Panel Family to a category you don't normally use. For instance, maybe "Nurse Call Devices" (unless, of course, you're designing hospitals).  Since the Panel Family is not shared, changing the Category shouldn't affect anything (e.g. Schedules, Tagging, etc.). Just be aware that there are Visibility and Graphic differences between Family categories. Cutting behavior is one.  

That's my forewarning, FWIW. 

Good Luck. 

[Anonymous]

@ToanDN Can I ask you what was my mistake? How did you make it? I'd like to know that, so next time It'll be good.. 🙂

@barthbradley I know this kind of nested families (I used to put this things in casework, usually) should go in a different categories, but then I could have inconsistencies among the family tree, and people could not find the panel (the basic user don't know much about the family categories, I experienced..) so, long story short, I'd be naming the panels in a way they should select only that group of "doors" with that code, avoiding from selecting the wrong families... hope it'll be better 

[ToanDN]

---

@Anonymous wrote:

Can I ask you what was my mistake? How did you make it? I'd like to know that, so next time It'll be good.. 🙂

The reasons your original family didn't work because when you swap the instance of the array from one family to another, the constraint now reading a different reference plane, and it breaks (@L.Maas did give you a similar comment).  What I did to mitigate the issue is nesting all of your panel families in one "parent" family so that you only swapping types, not families.