Announcement

Collapse
No announcement yet.

Casework

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

    #11
    We just rebuilt everything Casework in our office. (By we i mean me, lol). Here is whats different for us. All of the edits below are critical for the system to function correctly, so i would think about them.

    Originally posted by Munkholm View Post
    Agreed!

    Here´s some suggestions for additional parameters:

    Material and Finishes
    Cabinet (Shared, Instance, Material)
    Door (Shared, Instance, Material)
    Drawer (Shared, Instance, Material)
    Hardware (Shared, Instance, Material)

    Dimensions
    Plinth Height (Shared, Instance, Length)
    Cabinet Height (Shared, Type, Length)
    Add in:

    Height A (Type, Shared, Length)
    Height B (Type, Shared, Length)
    Height C (Type, Shared, Length)
    Height D (Type, Shared, Length)
    Height Toe Kick (Type, Shared, Length)
    Depth Toe Kick (Type, Shared, Length)
    Countertop Height (Type, Shared, Length)

    Here is why this is paramount: Cabinets with one door, one drawer: The sizes change. This is the *I* in the BIM. havnig them shared and typed, you can schedule the different types, which we now do. All of these things DO change project to project. Countertop Height: Its not very BIM-ish to have it in the counters, but you have to. Millwork specialists want to call out the Cabinets by the height of the WORK SURFACE, because thats where the code requirements are. For that, Countertop thickness needs to be in here.

    Our Millwork Legend calls out that A-D are the heights of Doors and Drawers, always starting at the top (single door = Height A), 4 drawers uses all 4. The technicality is this:

    In each family, one of them has to be Instance (reporting). But it works fantastically.

    Construction
    Door Type (Shared, Type, Family Type)
    Drawer Type (Shared, Type, Family Type)

    Graphics:
    Show Door (Shared, Type, Yes/No)
    Show Drawer (Shared, Type, Yes/No)
    Show Plinth (Shared, Type, Yes/No)

    Best Practices
    I´d suggest that doors and drawers should be nested families, unshared, casework category.
    Id suggest Handles, Doors, and Drawers all be Shared. If someone makes a custom Cabinet door, you want them having to edit every Casework family to load them in? No Way. All of our Handles are Shared, and- we havent done the nested doors and drawers yet- but it is in the plans, and they will all be shared.

    Also need Yes/No (Type, Shared) for:

    Lock Doors
    Lock Drawers

    We also have all of Casework Type Catalogged now. There are simply too many sizes, and not having them TC'd, when you load one you get 30 types you dont want.
    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


      #12
      Aaron, that´s all sounds pretty good to me! I think that your "Toe" parameters is the same as the suggested "Plinth" parameter (the "base" that the cabinets are placed on), if Toe is the correct English term, then Toe it is.

      And could you clarify what the "lock" parameters are for ? Real key locks on the doors/drawers, or are we locking something in the family?

      Think that I´ll have to sleep on the shared doors vs. nonshared doors... If only the parameters would sort alphabetically once in the project environment...

      Thanks for the input :beer:
      Klaus Munkholm
      "Do. Or do not. There is no try."

      Comment


        #13
        The locks are for just that. I have Face based locks on all the doors, and all the drawers, with parameters to make them present or not. We have real needs for this, in Healthcare work. Same with Sharing the doors and hardware.

        As i said earlier, im not terribly concerned with what the RFO standard ends up as, since i have ours in the office and it wont change. But, in our office anyway, those things are non negotiable. I cant think of a single good reason to have them not shared, aside from the alphabetical thing. And sorry, its just not a good enough reason.

        Currently we have no less than 21 Base Cabinets, 16 Uppers, and 5 full heights. Lets assume only half of those variations end up in a job. Heck, lets say one third. So when someone makes a custom cabinet handle or door panel, they have to open 14 families to load it in to? And then everytime it gets updated, they have to open all 14 again?

        Yikes!
        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


          #14
          I'm also in for making ALL nested components shared. This at the very least let you see what components are used when scheduling. Maybe not useful in the project for which you created your family but it is very clarifying when you reuse a family after it has been sitting in your library for a year or so.

          This doesn't go for just Casework but for any category (that's why I originally posted this remark in that other thread).
          Martijn de Riet
          Professional Revit Consultant | Revit API Developer
          MdR Advies
          Planta1 Revit Online Consulting

          Comment


            #15
            I would agree that 75% of the time, they should be Shared. There are SOME times i dont want them shared, because im nesting them simply for family simplicity in constraints. For example: I have a KONE Elevator family. Each track is a Nested Component, as is the Motor. They arent shared. Why? Im not specifying them individually, im scheduling and calling out an elevator. They arent selectable from a Parameter, or anything. Heck, theyre ONLY nested because its easier to constrain the geometry to a reference plane and have it flex for variations in size.

            I dont think you can say one way or the other what the default should be, but in this case is clear cut (for me anyway). If it actually pertains to the architecture, as in... Something i might change, select, alter globally, IE its more than nested to deal with revits issues.... It gets shared.
            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


              #16
              Originally posted by Twiceroadsfool View Post
              I would agree that 75% of the time, they should be Shared. There are SOME times i dont want them shared, because im nesting them simply for family simplicity in constraints. For example: I have a KONE Elevator family. Each track is a Nested Component, as is the Motor. They arent shared. Why? Im not specifying them individually, im scheduling and calling out an elevator. They arent selectable from a Parameter, or anything. Heck, theyre ONLY nested because its easier to constrain the geometry to a reference plane and have it flex for variations in size.

              I dont think you can say one way or the other what the default should be, but in this case is clear cut (for me anyway). If it actually pertains to the architecture, as in... Something i might change, select, alter globally, IE its more than nested to deal with revits issues.... It gets shared.
              You're right, that is the acception to this... Didn't think about that one. Although, it can happen I don't want elements altered but still make them shared just to be able to get a quick look at the family components without having to open it in Family Editor.

              So, how to describe this in a Style Guide???
              Martijn de Riet
              Professional Revit Consultant | Revit API Developer
              MdR Advies
              Planta1 Revit Online Consulting

              Comment


                #17
                Originally posted by mdradvies View Post
                So, how to describe this in a Style Guide???
                After some thorough thinking, I totally agree on the points you´ve both made! And think that it would be easiet to descripe with a few scenarious of when to share and when not to... Like Aaron prety much allready did

                To get these great brainstorms going for the other categories, I´m wondering if there´s any *Headlines* that are missing in the OP of this thread ?
                Klaus Munkholm
                "Do. Or do not. There is no try."

                Comment


                  #18
                  Aaron, why are you suggesting the Toe Kick, Countertop and Lock parameters to be Type parameters? They don´t really affect the cabinet Types in any way, and should be Instance IMHO.

                  Edit: Added recent suggestions to OP.
                  Last edited by Munkholm; February 28, 2011, 08:38 AM. Reason: Edit:
                  Klaus Munkholm
                  "Do. Or do not. There is no try."

                  Comment


                    #19
                    I personally dont prescribe to the "masking region and geometry off" philosophy. Its just not that big of a performance hit to show the modeled geometry in Plan, over showing a Masking region. Plus the masking region cant get material tagged, etc. So i show modeled geometry and symbolic/model lines, where necessary.
                    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


                      #20
                      Personally I´ve been showing the geometry for tall cabinets only - Base cabinets I always show as hidden below (counter top), and wall hung cabinets I always show as hidden above (cutplane) - So for me it´s not related to performance at all....

                      What are others doing ?

                      BTW Aaron, what do you think of type vs. instance in post #18 ?
                      Klaus Munkholm
                      "Do. Or do not. There is no try."

                      Comment

                      Related Topics

                      Collapse

                      Working...
                      X