Results 1 to 9 of 9

Thread: association with workplane when in array is lost

  1. #1
    Member ikinks's Avatar
    Join Date
    March 10, 2011
    Location
    the Netherlands
    Posts
    162
    Current Local Time
    10:54 PM

    association with workplane when in array is lost

    So, I'm trying to build an industrial sliding door family from scratch, and the basics are good and all, but I noticed some weird behavior when I insert a nested family. It's a workplane based family, the height from the ground level is controlled by a instance parameter. Tested it and it works, but the next step is to put this nested one into an array that is controlled by some sort of ((width * 2) / 750 + 1) formula. Tied the family to a refplane within a group, set out the start and end point for this array and designate the parameter to the array. Still works.

    But whenever I change the height of the initial workplane the nested family doesn't move. Go back into the group editor, select the family, only to find that it's not associated to any workplane. Even when I reset the workplane to it's default it doesn't move, so only the align tool helps me partially.

    Partially, because that nested family is also controlled by a family type parameter, and when a different family is selected it loses it's constraints with the workplane.

    I attached the RFA in progress, in case the story above didn't make sense to you.
    Attached Files Attached Files

  2. #2
    Moderator
    "Mark Twain"
    mdradvies's Avatar
    Join Date
    December 16, 2010
    Location
    Boxtel, Netherlands
    Posts
    4,553
    Current Local Time
    08:54 PM
    Next time I would create a Face Based Family. You can then easily host it on the rail and be done with it.
    For now, change the height of the door so that the alignment breaks.
    Align and lock the ORIGINAL component to the refplane for Door Height (D). You now get a stepped array with the first component on refplane D and the last at the previous height.
    I'm assuming you used Array > Move to Second. Select the SECOND component and align and lock to refplane D. Now you're done.

  3. #3
    Member ikinks's Avatar
    Join Date
    March 10, 2011
    Location
    the Netherlands
    Posts
    162
    Current Local Time
    10:54 PM
    Quote Originally Posted by mdradvies View Post
    Next time I would create a Face Based Family. You can then easily host it on the rail and be done with it.
    Never used the face base families before , so learned something new today! Looks like it actually works out, thanks.

    For now, change the height of the door so that the alignment breaks.
    Align and lock the ORIGINAL component to the refplane for Door Height (D). You now get a stepped array with the first component on refplane D and the last at the previous height.
    I did that earlier this morning (and picked the last component in the array), but when you change nested family via the family type parameter things start over again. 'Constraints are not satisfied' is the message that's bugging me the last 24 hours.

    I'm assuming you used Array > Move to Second. Select the SECOND component and align and lock to refplane D. Now you're done.
    FWIW, I used move to last. The maximum spacing allowed is 750mm.

  4. #4
    Moderator
    "Mark Twain"
    mdradvies's Avatar
    Join Date
    December 16, 2010
    Location
    Boxtel, Netherlands
    Posts
    4,553
    Current Local Time
    08:54 PM
    Yeah, you're right. It is doable though, since I just made it work. Downside is: I had to throw out most of the constraints and dims... You are overconstraint somewhat which causes the error. Just can't figure out where it's going wrong (due to lack of time).
    You might come a long way if you expand the error box and start deleting some stuff manual. Look for dimensions / constraints. This eventually leads you to the problem, but my guess is that using a Face Based family is way faster... (and don't forget that there's a good chance you will run into the same problems when you reapply your constraints)

  5. #5
    Forum Co-Founder Alfredo Medina's Avatar
    Join Date
    December 7, 2010
    Location
    Orlando, FL, USA | info@planta1.com
    Posts
    2,788
    Current Local Time
    04:54 PM
    I tried to look at this, but it is very hard to read parameters in Dutch.
    Comment: is it really necessary and important to create the angles over the top rails? Is it really necessary to model the rails and vertical mullions with round corners as small as 2.6 mm? (13/128")? It seems like over detailing for a door. Some of these details could be included as detail components, if necessary, to simplify the model, or taken care of by just data in the door's properties. Oops... here go again with the long debate about modeling everything or not...

  6. #6
    Moderator
    "Mark Twain"
    mdradvies's Avatar
    Join Date
    December 16, 2010
    Location
    Boxtel, Netherlands
    Posts
    4,553
    Current Local Time
    08:54 PM
    Quote Originally Posted by Alfredo Medina View Post
    I tried to look at this, but it is very hard to read parameters in Dutch.
    Comment: is it really necessary and important to create the angles over the top rails? Is it really necessary to model the rails and vertical mullions with round corners as small as 2.6 mm? (13/128")? It seems like over detailing for a door. Some of these details could be included as detail components, if necessary, to simplify the model, or taken care of by just data in the door's properties. Oops... here go again with the long debate about modeling everything or not...
    hahaha, well depends on your work I guess. If I'm not mistaking Ikinks is in the stable business where these doors are standard. So I would say yes.
    Nevertheless: doesn't really matter for the problem at hand... The horizontal bar over the door opening cannot be changed to another type without the L-corners above it break constraints...

  7. #7
    Forum Co-Founder Alfredo Medina's Avatar
    Join Date
    December 7, 2010
    Location
    Orlando, FL, USA | info@planta1.com
    Posts
    2,788
    Current Local Time
    04:54 PM
    The issue with this common problem that occurs when we try to have an element that swaps or turns into another one by using a family type parameter is that we tend to overdue the process, creating more constraints than necessary, causing the "over constrained" problems later.

    Example of bad workflow:

    1)You load the first family item (for example, a generic model "angle", in this case), then you align it, lock it, in x, y, z, etc. Then you create a Family type parameter for generic models, then you select the "angle" and apply a label to it, to relate the angle to the family parameter. Then you create an array, etc. This is OK.

    2) Then you load another family item of the same kind, for example "angle 2". Then you place it at the same place as "angle 1", align it, lock it, in x, y, z, etc... Then you select "angle2" and apply the same label to it. Bad.

    3) Then you load a third family item, or more, and for each item you repeat all the same steps you did in #2.... Bad.

    4) Then you try to create types: Type 1 works with angle 1, Type 2 works with angle 2, Type 3 works with angle 3, etc... Result = Constraints not satisfied!

    Example of the good workflow:

    1) Same step # 1 above.
    2) Load family item (angle 2) into the host family. But don't do anything with it. (Don't place it anywhere, just load it and hit cancel).
    3) Then you load a third item, or more, and for each of them you repeat the steps in this new #2 (just load it).
    4) Do your types. "Type 1" works with "angle 1" , "Type 2" works with "angle 2", etc.... Result =

    For the good workflow to work, make sure that the items that you intend to swap (angles in this case) share some essential things, such as the same template, same origin point, orientation, similar set of parameters, etc., so that they make sense when you swap them by changing types. If something does not work, don't start adding additional constraints in the host family that just complicate the situation even more. Open the item that is causing trouble, and modify it in its own file, then load it again in the host.

  8. #8
    Member ikinks's Avatar
    Join Date
    March 10, 2011
    Location
    the Netherlands
    Posts
    162
    Current Local Time
    10:54 PM
    @ Alfredo: I think I followed your good workflow, but to be sure I'll start again and have a go with your write-up, just in case I took a wrong turn somewhere. And for the discussion 'is it necessary to model every bit', my answer is yes for several reasons:
    (1) it's a good practice for me to get the hang of family creation, to get some fingerspitzengefŘhl (how I love that word );
    (2) some people here at the office say 'it can't be done, you can't model a 3D family in a way that it shows up correct in a 1:10 or 1:5 scale without adding lots of 2D linework', in which I'm trying to proof them wrong;
    (3) as Martijn already mentioned, this type of doors are very common in our business, so when I can create a universal type of family it'll save me and my co-workers lots of time in the future;
    (4) it might show up a little more realistic in renders.

  9. #9
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    7,726
    Current Local Time
    03:54 PM
    Regarding Face Based, nested families, and arrays: Be advised that their are "workplane issues" surrounding this combination that are Known by the Factory, and currently not fixable. You may succeed in "constraining" the arrayed Nested Face Based Family to a workplane, but if you tab-select the nested instances, they wont actually be hosted to the same "face" as the original anymore. It becomes more evident if you try to make a parametric Lav Array, with a sink that cuts a hole out of the countertop. Pre-2012, there wasnt a good way to make the entire sink parametric, and the entire sink swabble (nested family), and have it still cut the hole out of the countertop. The holes had to be in the array group, not in the nested family as a void. Which killed being able to swap the families out.

    In 2012 they havent fixed it, but some added functionality to let families be cut in the project environment made it work-aroundable.

Similar Threads

  1. Broken Revit File Extension Association
    By Scott Hopkins in forum Architecture and General Revit Questions
    Replies: 3
    Last Post: June 1st, 2015, 07:13 PM
  2. Unintended Association
    By iru69 in forum Architecture and General Revit Questions
    Replies: 10
    Last Post: May 20th, 2011, 11:32 PM
  3. Lost without you!!!
    By LeanneZ in forum Out There
    Replies: 4
    Last Post: March 22nd, 2011, 08:03 PM
  4. level association
    By elton williams in forum Architecture and General Revit Questions
    Replies: 3
    Last Post: March 10th, 2011, 03:27 AM
  5. Workplane Visibility?
    By Fishtail8 in forum MEP - General
    Replies: 1
    Last Post: January 28th, 2011, 10:24 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •