I hope that you will take as much value and inspiration out of this blog, as I have from the following blogs and sites. Even though I am not affiliated with any of these blogs and sites, I believe that one has to give credit where credit is due, so here goes:
1. http://buildz.blogspot.com/
2. http://paulaubin.com/category/blog/
3. http://therevitkid.blogspot.com/
4. http://forums.augi.com/
5. http://www.revitforum.org/
(Please note that the aim of the blog is not to provide training, or to say that the content is the only way of achieving a design or drafting goal. I am sure that many users have found better workarounds to certain challenges and they are more than welcome to tell us if they have).
My first entry will focus on the brilliant concept of assemblies, and investigating the practicality thereof. I will not be designing in these posts. Look at these entries as testing sessions, seeing how far one can take a concept without breaking it.
We will use a very simple curtain wall system to play around with and test the assembly functionality
I have selected all of the elements in my view. Remember that a curtain wall is a System family, in other words, it is created within Revit's project environment. A Curtain System is created using 3 core element categories: Curtain Grids, Curtain Panels and Mullions. If we would like to create an assembly from the element categories of the curtain wall, we will need to filter our selection.
Curtain Grids cannot be part of an assembly, so we will deselect its checkbox. We will also exclude the Walls category.
From the current selection's Modify/Multi-select tab, we will now be able to create an Assembly from the Create panel in the ribbon.
A name for the assembly needs to be provided. It is always a good idea to think about the naming convention of these assemblies before it is created, as Revit will rename and increment numerical numbers in the assembly name for any other sequential assembly. For the purpose of this entry, I have named the Assembly: Shopfront 1_South.
It is important to understand that the assembly will be "grouped", so if we try and select a single Curtain Panel, the entire assembly will be selected. However, the behaviour of the assembly is completely different to the behaviour of a Model or Detail group.
With the assembly selected, we can Create Views for the assembly. Now the big question is: What views can we create?
There are quite a lot of options for the type of views as well as the schedules that one can create from the assembly itself. We can specify a scale for these views as well, but be aware that the scale for these views (upon creation) will be global. In other words, if we specify a scale of 1:50, all of the view type checkboxes that are checked, will be at a scale of 1:50. After the views have been generated, the scale of selected views can be changed without affecting the other assembly views. Depending on the amount of information required, you will even be able to create a schedule for your Curtain Panels, and Mullions.
Revit will now create all of the selected views, and group them in our project browser, under the Assembly category, Shopfront 1_South assembly type.
Only the selected items included in the Assembly will show in the views.
We can tag these assemblies as well. The Assembly Tag is located in the Annotations folder of the OOTB (Out Of The Box) Revit library.
We have the option of tagging the assembly itself, or the Curtain Panels inside of the Assembly, by hovering your mouse cursor over an element and pressing tab until the assembly element highlights. In the assembly view, if you try to now add information to the selected assembly element, you will notice that the Instance Properties are not editable, nor are the Type Properties. This is due to the fact that these elements are assigned to the Assembly itself.
To add or change information to these elements, we have to Edit the Assembly, select the assembly element, and only then the Instance- and Type Properties will be editable.
Let's investigate if bi-directional associativity still exists within the assembly views. I will be working in both the project's South elevation as well as the assembly's Shopfront 1_South Detail View plans. When Curtain Grids are deleted in the South elevation, the change propagates to the Shopfront 1_South Detail View as well. A "warning" does appear, but is only a notification that the Curtain Grid will be deleted within the assembly. Happy? I am.
Should a Storefront Door be added, all assembly views update. Happy? I am.
Should Curtain Panel types change, the change is applied to the schedules. Happy? I am.
We now need the same assembly to be located in another location. A simple Copy command should suffice, shouldn't it? Unfortunately not.... An assembly is not a group. Thus a new assembly type is created for the copy.
The new assembly type will be named according to the naming category of the assembly being copied. In this case, the naming category was Curtain Panels.
Can you not just change the type of assembly for my copy? Unfortunately not. An assembly is not a group. Remember the Curtain System explanation in the beginning of this entry? "A Curtain System is created using 3 core element categories: Curtain Grids, Curtain Panels and Mullions". Due to the latter, the nested parts or elements of the Curtain System will not allow a type change to occur.
So let us test this with a Component family, i.e. something created not within the project environment, but rather in the family creation environment. I have created a new assembly for a double flush door, and called the assembly name: "D01" (Tip: Even through there are pro's and con's, on smaller projects assembly views can be used to generate door legends). The previously explained steps were followed to create assembly views for the D01 assembly.
The assembly view was placed on a normal Revit sheet, even though one can create a sheet from the assembly view itself. Previous Revit versions would only allow you to place assembly views on assembly sheets. The door was annotated and the annotations propagated through to the sheet. Happy? I am
If we edit the D01 assembly and change the type of door from a double flush to single flush, the change dynamically takes place. One will obviously get a warning notification of dimensions becoming invalid, as their references for the double flush door does not exist anymore in the single flush door family. Happy? I am.
If a new door is added, and a new assembly is created for that door (D02), would Revit still not allow me to change the assembly type, as we saw with the Curtain Wall example?
No, it does not. Happy? Not really. Should I run to the corner of my office, crawl into the fetal position and cry? No. Accept it and man up. An assembly is not a group.
What if we create a copy of my D02 assembly? Yes, we do get a warning that my assembly copy will receive a new name, however, it still remains part of the same assembly type: D02.
An interesting thing happens when we access our door schedule. Our Count field states we only have one double flush door in our project, while we clearly have two.
Within our door schedule, when entering the Formatting tab and selecting our Count field, by checking the Calculate totals checkbox you will be able to calculate the schedule field total either by Assembly Instance, or Assembly Type. By selecting Assembly Type, the correct amount of double flush doors will show. Happy? I am.
With a fortunate miss-click in the Edit Assembly command, I changed one of my D02 assembly door opening orientation by mistake. When accepting the change, a strange thing happened. Because the door opening direction has changed, Revit has created a new assembly type. Because in actual fact, it is.
Do not confuse the assembly type functionality in Revit with the architecturally correct method of indicating door type and opening orientation. Revit still recognises that something big (the orientation of the assembly) has changed, and thus it needs to create a new assembly. Kind-of makes sense, doesn't it?
Personally, the more I try and delve into the programming, the why, how, what and where of Revit, the more respect I have for the creators and developers of Revit. That, or I am just starting to think like they do...
The D05 assembly door schedule will only show assemblies belonging to D05. Happy? I am.
However, the following situation makes me unhappy. What if I had two D02 assemblies, with different Mark values? Changes to instance parameters unfortunately do NOT update assemblies. Even though I changed the door Mark value, my schedule still shows that both of my doors are of the mark: 85. Even though this has been a wishlist item for quite a long time, it hasn't been addressed yet.
More often than not I use reverse engineering only to find out why something happened, and then I ask myself the question: Is it worth the amount of time and work to find out what happened to each and every assembly and fix what is needed by retracing my steps, or: Shall I save myself time and frustration by recreating an assembly from the updated elements? Obviously this way of thinking will differ from project to project, but it is something to ponder on.
I hope this blog entry made some sense and more importantly, made you think about the different ways to apply a functionality in Revit to challenges you face in your daily routine. Please feel free to post some comments or even share your experiences. We might even discover a new workaround! Wouldn't that be revitalizing?
No comments:
Post a Comment