Announcement

Collapse
No announcement yet.

association with workplane when in array is lost

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    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. :laugh:
    Attached Files
    Arjan Ikink, BIM-engineer at PHB Deventer
    LinkedIn

    #2
    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.
    Martijn de Riet
    Professional Revit Consultant | Revit API Developer
    MdR Advies
    Planta1 Revit Online Consulting

    Comment


      #3
      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 :hide:, 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.
      Arjan Ikink, BIM-engineer at PHB Deventer
      LinkedIn

      Comment


        #4
        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)
        Martijn de Riet
        Professional Revit Consultant | Revit API Developer
        MdR Advies
        Planta1 Revit Online Consulting

        Comment


          #5
          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...
          Freelance BIM Provider at Autodesk Services Marketplace | Linkedin

          Comment


            #6
            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...
            Martijn de Riet
            Professional Revit Consultant | Revit API Developer
            MdR Advies
            Planta1 Revit Online Consulting

            Comment


              #7
              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 = :thumbsup:

              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.
              Freelance BIM Provider at Autodesk Services Marketplace | Linkedin

              Comment


                #8
                @ 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.
                Arjan Ikink, BIM-engineer at PHB Deventer
                LinkedIn

                Comment


                  #9
                  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.
                  Aaron "selfish AND petulant" Maller |P A R A L L A X T E A M | Practice Technology Implementation
                  @Web | @Twitter | @LinkedIn | @Email

                  Comment

                  Related Topics

                  Collapse

                  Working...
                  X