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! 

[Anonymous]

Ah ok, you acted what L.Maas said..
Ok, it was just to understand if something different could have been done.. Ok, with array parameter, I should adopt this strategy, now I know it...
I still don't get some of the logic about arraying elements in the families... Do you have any advice when creating them?
For example: Should the array contain a reference plane/line or not? Or has to be a separate array from the object itself?

[ToanDN]

---

@Anonymous wrote:
I still don't get some of the logic about arraying elements in the families... Do you have any advice when creating them?
For example: Should the array contain a reference plane/line or not? Or has to be a separate array from the object itself?

---

One rule is what we has discussed above.

Another is the second instance's constraints need to set carefully (plan and elevation) because they drive the rest of the array.

For your specific example, ref planes/lines can be included in an array, technically.  But if they need to be included with every array instance then they should have been placed in the instance family already.  

[barthbradley]

---

@ToanDNwrote:

 ...ref planes/lines can be included in an array, technically.  

 Yes, but why do it? What's the logic here? I can't think of it. 

I'll add to your points, that the array itself should be constrained. That is: once it's grouped & associated; follow up by aligning and locking the second or last instance (depending on how it's appended) again -- and then test it by flexing it. IME, arrays take some finessing to get them to behave properly.   One thing I know for sure will break an array, is improper constraining.  The arrayed component's dimensions should to driven by parameters -- not by host ref. planes. Those associations lost upon arraying. 

That's my 2 cents worth. 

[ToanDN]

You should have included "...technically. But..." in the quote. That would show where I stand.

[barthbradley]

Sorry @ToanDN. I wasn't dinging you. I was just using your quote to make my point.  I agree with all you said.  

[Anonymous]

Thank you for the answers,

I like when people spend sometime on a subject and give me their opinion about that problem!