Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 32

Thread: Casework

  1. #11
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    8,212
    Current Local Time
    01:39 PM
    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.

    Quote 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.

  2. #12
    Administrator Munkholm's Avatar
    Join Date
    December 7, 2010
    Location
    Kingdom of Denmark
    Posts
    4,144
    Current Local Time
    08:39 PM
    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

  3. #13
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    8,212
    Current Local Time
    01:39 PM
    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!

  4. #14
    Moderator
    "Mark Twain"
    mdradvies's Avatar
    Join Date
    December 16, 2010
    Location
    Boxtel, Netherlands
    Posts
    4,553
    Current Local Time
    06:39 PM
    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).

  5. #15
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    8,212
    Current Local Time
    01:39 PM
    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.

  6. #16
    Moderator
    "Mark Twain"
    mdradvies's Avatar
    Join Date
    December 16, 2010
    Location
    Boxtel, Netherlands
    Posts
    4,553
    Current Local Time
    06:39 PM
    Quote 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???

  7. #17
    Administrator Munkholm's Avatar
    Join Date
    December 7, 2010
    Location
    Kingdom of Denmark
    Posts
    4,144
    Current Local Time
    08:39 PM
    Quote 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 ?

  8. #18
    Administrator Munkholm's Avatar
    Join Date
    December 7, 2010
    Location
    Kingdom of Denmark
    Posts
    4,144
    Current Local Time
    08:39 PM
    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 28th, 2011 at 08:38 AM. Reason: Edit:

  9. #19
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    8,212
    Current Local Time
    01:39 PM
    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.

  10. #20
    Administrator Munkholm's Avatar
    Join Date
    December 7, 2010
    Location
    Kingdom of Denmark
    Posts
    4,144
    Current Local Time
    08:39 PM
    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 ?

Page 2 of 4 FirstFirst 1234 LastLast

Similar Threads

  1. Applying outlets to casework
    By stl4310 in forum Architecture and General Revit Questions
    Replies: 7
    Last Post: February 18th, 2011, 06:19 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
  •