Filter Criteria Order Matters

Taylor wrote to me to say that he noticed a subtle quirk when he wanted to filter pipe in a schedule. He needed to focus on Mark values that contain M15 and M16 for example. He discovered that the filter would work if he put the criteria in that order but that if he happened to reverse them like this, M16 and M15, Revit no longer found the M15 pipes.

Definitely subtle.

Project Base Point Manipulation

I written before that I occasionally experience something that feels like a "Revitary alignment" regarding features in Revit. I'll see a post at AUGI or get an email or two from friends or clients asking about the same thing or theme. I recently ran into a user that manipulated their project by moving the Project Base Point. Then a post at AUGi meandered into a related conversation.

General Statements

• The Survey Point allows us to show where an imported CAD file's origin is relative to your model (CLIPPED)
• The Survey Point allows us to identify a benchmark location on the site instead of referencing source file's origin (UNCLIPPED)
• The Project Base Point does not ever "need" to be moved (CLIPPED) normally (my opinion/belief/preference)
• The Project Base Point will allow us to move our project on the site to reposition it (CLIPPED) but the file origin isn't changed
• The Project Base Point (UNCLIPPED) will let us identify an alternate location that Spot Elevations and Spot Coordinates can reference

Applied to a Project

Let's say you design a house, import a survey and it's off to the right and above your building. If you use Acquire Coordinates on the survey file you should find the Survey Point (CLIPPED) moves to mark the origin of the source survey data file (sometimes this is quite far away). The Project Base Point (CLIPPED) can be used to reposition the building over the site. Just drag or move it with specific values. What you see moving is the "Project". The file origin is untouched and you should see that the linked survey file isn't moving either. If you import a small origin "marker" file using Auto - Origin to Origin you'll find that it lands at the Project Base Point. Now if you move the Project Base Point (UNCLIPPED) you see that you can move the icon to another location but it still references the "file origin" (see image).

That approach works for a single building on site but is not very effective for multiple buildings on site. The approach I advocate where we create a site file that is coordinated with survey data and serves as the master coordinator for multiple buildings which are linked into this master site file is much more effective and versatile. Since this subject can be confusing enough I advocate using the same approach for any project so I can learn one technique and use it over and over, since it works for any project.

Families with Nested Families and MEP Connectors

While trading some emails with Aaron Maller recently he mentioned that he observed that he could create circuits for nested shared electrical families. I don't recall Autodesk publicly taking credit for adding or allowing this behavior but I find that it has been possible as far back as the 2012 release. I'd try earlier releases too but I don't have them installed anymore. Since I started preparing this post I've discussed it with Jose Fandos and he confirmed that it is possible in 2011 too.

I'm a bit frustrated because I thought I tried to explore this possibility a couple years ago while making some electrical content. Rather than dwell on what I thought wasn't possible I'll focus on what IS possible instead.

Experience tells us there are many components that have a variety of options or configurations that can prove difficult to include connectors in, for example a boiler with its electrical panel available either on the right side OR the left side. When a single connector is placed we are inclined to placing it in the "middle" so we can "connect" it to a power supply. That's easier to accept for electrical connections but not as easy for piping or duct.

When the connectors are native, placed directly in a family, it isn't possible to put two connectors in place but disable one or the other. Revit sees both even if we only use one of them in the project. With two connectors in the model we can define where connections take place more accurately but ultimately we end up with one valid connector (connected) and another lurking as "unassigned" within the system browser. It might not a big deal but Revit's developers encourage to assign everything to systems so this approach means there will always be some we can't assign properly.

If the connector is part of a nested shared family and this nested family is assigned a Yes/No parameter to control its Visible parameter we gain control over not only when it is visible but also whether or not Revit sees a valid connector in the host family when it is loaded into a project. This is a crude example with connectors for pipe, electrical and data circuits, offering a conceptual right and left configuration.

When I use a yes/no parameter to control the visibility of the nested families it is interesting to find that the system browser responds to their condition. As can be expected Revit will delete a circuit or system associated with a nested connector if we choose to turn it off.

So far I find that I can create systems, connect pipe and duct, draw wires as well as tag the nested shared families. This means that it may be a bit easier now to define a component that has multiple circuits. This can help counter the limitation that a family can only report circuit information (in a tag) for the primary connector when multiple connectors are in a family.

It isn't perfect...naturally.

Nested families with connectors are harder to see and therefore are harder work with. The connectors are only visible when you hover over the location where they are when you are using the appropriate tool, like duct, pipe or wire. That also means we can't use the convenient right click "create pipe/duct/wire" options because we can't see the connectors.

It may also confront us with a need for sub-categories for connector geometry, not for the connectors themselves but any forms we use to host them. It can be easier to find the connectors if we can see the hosting forms but we may not want to see them in every kind of view.

Ultimately I think it's worth exploring further. Perhaps you'll agree?

Schedule Linked Files

We can schedule elements that are in linked files but there isn't a schedule that is only interested in telling us what linked files there are. We can determine which files are linked easily enough while working inside Revit. What if we want to document what files are linked into our model and include this information on a sheet? We can take advantage of the addition of Grids and Levels as elements we can schedule in Revit 2014.

If we assume that all projects will have levels and probably grids a schedule that is assigned to one of those categories can be manipulated to look like it is just a schedule of linked files. Then we can combine that with a Starting View if we want to see it each time our project is opened. Add the schedule to a general information sheet and it can be part of our documentation too.

I created a schedule that includes the fields for RVT Links and at least one for Grids. In this example I used Grids to drive the schedule but Levels are probably a better choice.

When we load a linked file we can supply a unique "Name" value. When we use Reload From or Reload later to update the model we can revise the "Name" parameter to show the current version/date.

Make a custom titleblock family and add the Project and Client related parameters as desired. Load the family and create a new sheet using this special titleblock. Add the new schedule to the sheet. To use this as a starting view activate the Manage ribbon and click the Starting View button. Choose our special sheet view as the starting view.

I used the Clear Cell tool, new in Revit 2014, to remove the link between the schedule name and the header text. This allows us to call the schedule something meaningful in the project browser and show something else in the header of the schedule on the sheet, as shown in the first image in the post. Since schedules can be on any number of sheets it is an easy matter to place it on additional sheets if desired.

A Doors Life

As I mentioned in an earlier post I presented a session called "A Door's Life" at the recent Central States Revit Workshop. It tackles creating a host door family that nests 2 panels, 2 frames and 2 handles. It also features a nested clearance form for clash detection and a variable plan swing angle. The host door permits rotating the 3D panel and hardware to any angle as well, though 0-180 is probably the range that's most useful.

If you are interested in more information this is the handout that attendees received (embedded here).

As the handout will tell you it isn't meant to be the perfect door. It's a demonstration of concepts and how to put them all together. If you're lucky you'll end up with something you can use right away or at the very least have a good idea how to get where you want to go.

Click to Download the completed files for each exercise.

Drafting Views have an Origin

When we create a new drafting view we are presented with an empty view. We are free to begin our drafting exercise anywhere we see fit. It's not obvious but there IS an origin in the view. If we import a simple CAD file that has some lines that define where the 0,0,0 origin is we'll find out exactly where the origin is in the drafting view (use Auto-Origin to Origin).

What does it matter? It may not matter at all. I've often wondered about it since Revit cares about keeping us near the origin of the file for our model views and complains when we import external files that are very far from origin or very very large.

As such I can't help but wonder if we ought to be careful to keep our details near the origin of drafting views too. I have encountered drafting views that have their contents very very far from the origin. It's easy to do, just zoom out a bit and start detailing. It just seems inconsistent with the best practice expectations for model views.

I'm inclined to create a "template" drafting view in a project template to begin drafting views with (duplicate them) with the origin clearly marked, like shown above. I'd welcome someone from the factory chiming in to say this is a good idea or unnecessary.

Revit MEP Circuiting

I created a short video that describes the basic interaction between electrical devices and creating a circuit. It's really meant to help explain what happens when a device is already assigned to a circuit and we select it along with other elements that aren't circuited. The ribbon changes based on our selection and a circuited devices impairs our ability to create a circuit for the other devices that are eligible to create one.

• A device that is not part of a circuit, when selected by itself, will cause the Power button to appear
• A device that is part of a circuit, when selected by itself, will display the additional Electrical Circuit tab
• Multiple devices that are both part of a circuit and not part of circuit will only display the context ribbon relevant for the devices, no circuit tab or power button
• Selecting multiple devices that are assigned different electrical requirements will disable the Power button

When we select devices we need to be sure to glance at the ribbon for clues. Here's a video (no audio, turn on Captions).

I also wrote an earlier post about circuits if you're interested.

Light Fixture Grid Positioning and Wires

I've seen some lighting content that has been modified to make it easier to align with acoustical ceiling tile grid patterns. For example this stock family is the Downlight-Recessed Can.rfa with some reference planes added so we can snap to the grid during placement, or use the Align tool easily afterward.

I didn't bother to assign any parameters to control them. I can use them to fit the fixture in a 2x2 grid or use the Align tool later to position it in the middle of a 2x4 grid. It might not be obvious but I can use one reference in a family to move the family over by selecting another part of the family as my second pick. This means it is easy to just set the reference planes at a fixed position and use the family's own references to move it over if necessary. It just means I don't have to have parameters to decide if the fixture is meant for a 2x2 or 2x4 grid. All this is seems good at first except when it comes time to add wiring to the fixtures.

These helpful reference planes end up affecting where the wire's graphical ends terminate. The fixtures are connected to their wire but they just stop at the extents defined by the reference planes. Not fun when you have to adjust a lot of wires to get closer to the fixture. This means Reference Planes aren't ideal for this task. This is what the family looks like if I use Reference LINES instead.

I've held the same attitude toward adding dimensions in this example too, with much better results as well! We can set the reference lines to Strong (IsReference) and uncheck the Visible parameter. They won't be visible when you select the family but the Align tool will "see" them and Revit will highlight the ceiling grid pattern when you place the fixture too. Fwiw, if you leave it checked they still won't be visible when you select the family.

Fwiw, Model and Symbolic Lines that are Strong References and assigned to Invisible Lines provide the same result. You can uncheck the Visible parameter so they aren't visible when you select the family.

(This is based on working in 2014, it does not work in 2012 or 2013. Nothing seems to resolve it in those versions)

Search the Project Browser

Just a little reminder, don't forget you can search the Project Browser!! Forget what you named a family exactly? No problem just search for what you do remember! The hardest part is remember you can search it! It's just a little right click away.

Linked Files and Visibility/Graphics

When you examine the Visibility/Graphics dialog you'll find each Revit file you've linked is shown in a list under the Revit Links tab. In this example I've linked Building A, B and C into a host model. The Project Browser shows three linked files and Visibility/Graphics shows the same three but also shows one child link beneath the top level row for each link.

The top level row for each link is the definition of the linked file while the child beneath it represents the actual instance that is placed in the model. The single child for each link provides a way to customize the appearance of the individual linked file apart from the parent definition. Ordinarily this would NOT be required. If overrides are necessary it is sufficient and appropriate to just alter the definition (top level) only.

However if for some reason you were to use two instances of Building A and Building C the Visibility/Graphics dialog would look more like this, while the Project Browser would remain unchanged.

The new child rows listed for Building A and C are the result of copying the originals for each to a new location. Each new row provides us with the ability to use Visibility/Graphic overrides for each child differently if necessary. For example, I could turn off the first instance of Building C without affecting the second instance.

As you can see, the upper Building C is off now. I could also use the button that appears in the Display Settings column to override individual instances of the linked files. If I want to alter both copies the same way I just need to change the top level definition. I start by checking the option "Override display settings for this instance", choosing Custom, activating the Model Categories tab and then changing the Model Categories drop down to Custom. Now I can override individual model categories in just one instance of the two copies of the linked file.

The link names you see are not default values, I changed them via the Name parameter in the Properties palette.

When worksets are involved the top level is assigned to the Type Parameter "Workset" and the child has its own instance parameter for "Workset" too. This means the definition can be assigned to a workset but each instance can be assigned to different worksets.

If you see more than one child instance of a linked file and there should only be one child that probably means someone has copied a link inadvertently. If you can't tell then it's likely they used Copy to Clipboard followed by Paste Aligned to Same Place and there are two instances on top of each other. Since it's been so easy to accidentally select a link I see this happen fairly often. It can create some confusion when people are trying to override graphics and their efforts don't seem to work. There may be another copy lurking underneath.

Dropping Files

My son is into "Dub Step" and he tells me "the drop" has special meaning but this post is about dragging and dropping files into Revit. You may be aware that, like other Windows applications and files, you can drag and drop a file from Windows Explorer into Revit and Revit will open the file.

As you have probably noticed I like subtle stuff. Brian Mackey mentioned in his adaptive point session at Central States Revit Workshop yesterday that where we drop the file affects how Revit will respond. If we drop a file on the ribbon Revit will open the file. If you drop the file into the canvas or drawing area, and a project or family is already open, it will likely load the family into the other open file instead. If you really want to open the file just be careful where you drop the file.

In Dub Step terms, "Where's the Drop dude?"

Double Clicking Tags

In Revit 2013 we found a new feature to be quite annoying, double clicking on a room tag would put us in the family editor. That is particularly bewildering to new users. Usually we were more interested in typing in a room name or number. With 2014 we received new options to define how Revit should respond to double clicking on a family.

At the Central States Revit Workshop this morning, Brian Cowles with IMAGINIT mentioned a subtle change that is easily missed. If you leave the setting "Edit Family" as your preference it is almost the same as 2013 except that where you put your cursor is important before double clicking. If you double click on an editable label in the tag it will place you in edit mode for the parameter. If the Move symbol icon is displayed when you double click you'll edit the family. This means you can take advantage of double clicking AND avoid the downside.

Love subtle stuff!

Phase and Poche Materials

As you're likely to know already Revit provides a feature to change the appearance of elements to distinguish between phases of work. When you examine the Materials dialog the "Phase-X" materials were created by the development team and they exist to support the way that feature is intended to work. The templates are configured (OoTB) to automatically "work" if you use the phase features.

When I visit the 2014 Architectural template I find three "rogue" phase materials in the dialog (image above). The four highlighted in yellow are assigned to the Phases Graphic Overrides.

I've no idea what these three other materials are assigned to. When I examine the Materials dialog and the icon for "asset use" (highlighted with the red circle in the first image in this post) the four "good" materials report that the associated asset is shared with 8 materials. The three rogue ones are not using an asset shared with any other materials. Easy enough, I deleted them. Revit will let you delete any of the phase related materials even though the Phase feature is technically relying on them to work as intended out of the box.

In general nobody will use the materials for anything else, not really suited for anything else. They "work" as intended and are preset so they do. The only real interaction anyone needs to have with any of these materials is if something about how they look isn't quite what we want. If we don't think demo elements should be red we can change the material to use something else or increase or decrease the transparency for example.

The other material highlighted in yellow is the poche material (pronounced Poe-shay). It's also a feature that was originally tied to the graphic display of the model when Coarse Detail Level is in effect. However they've made the Poche material assignment a Type Property of 3D views.

You have to assign a material to have it take effect. In the past Poche was hardwired to the effect. Now you can technically use any material in the library instead. Poche isn't required itself to work anymore. Here's an example of it being used on the section through a pavilion model.

Silence the Warnings

If you do something Revit doesn't like it will generate a warning that appears in the bottom right of the Revit interface. Those are warnings you can choose to ignore but they are stored in the Review Warnings dialog to review later. It's a good idea to remember to resolve as many as you can.

If you also get a warning sound when these appear and you find it annoying, you can silence them if you click the sneaky little "speaker" icon that appears in the warning dialog.

My son showed me this meme as I was writing this post, sublime timing? I think so...

Two Lines in Schedules

You may be aware that we can force a schedule field to use a new line by pressing Shift + Enter. This permits you to enter new information on a second line but once you finish editing the cell Revit will only show the single row. When the schedule is placed on a sheet you'll see both lines or how ever many you force it to use.

If you do this and need to edit the information again you'll need to use the Left Arrow key to advance the cursor to the next line(s). It's a little quirky. With the lack of fidelity between sheet and schedule editing view you'll also have to experiment with the width of columns to get them look correct on sheets.

Hopefully its obvious but I'll mention it anyway, this Shift + Enter only works on fields that we type values into not those that are calculated or based on other value supplied by the elements themselves, like Family, Type, Height, Width etc. Technically you might be able to enter something but it will still have to provide an acceptable result to the family itself.

Technical Support

Recently a question popped up at AUGI stating the "Worksharing Does Not Work". Several people replied and then the original poster casually mentioned that maybe Dropbox wasn't passing the data back and forth quickly enough. I replied with:

Funny how something major like using Dropbox isn't mentioned at the outset If you'd included that tidbit that would have changed the conversation considerably. When people ask for help in a forum it really helps to provide lots of clues, it's a bit like a detective novel. We need clues to figure out who did it.

YES it takes quite awhile for a files (larger the longer) to upload to Dropbox and then replicate elsewhere. If you plan to do real work using Dropbox you'd better be careful. It is very easy to borrow something that another person has already borrowed because of the latency between upload and replication. When that happens whoever was second or third will lose, lose everything they did because Revit will not let you synchronize your work at all. Your "invalid Schema" error is indicating that the file was not intact when Revit tried to open it. This will happen if the file isn't completely replicated or uploaded.

Dropbox does not know anything about the relationships between our files or that Revit is attempting to communicate between central and local files. It just copies bit for bit from here to there and there. This means that it is all together too easy for Dropbox to kill the relationship unwittingly.

If you can be certain that no two users are actively working on the project concurrently then there is much less risk. That would be something like a "follow the sun" workflow where someone in Europe works on the file until someone in the USA joins as the European's day winds down and the American stops works as the Australian begins and so on. Concurrent workers with files on Dropbox is a love story heading for heartbreak.

If you find yourself asking a question in a forum or sending me an email be sure to offer lots of clues. When we take our car to the mechanic they usually ask for clues. They aren't likely to tell you, "No, don't tell me what's wrong, let me guess!" Ditto for your doctor. You know the old joke, "Hey Doc, it hurts when I do this!" "Well don't do that!" Reworked it's, "Hey Doc, it hurts when I use Dropbox for worksharing!" "Well don't use Dropbox for worksharing!" :)

Loaded and Unloaded Link Icons

In the project browser we'll see either a blue arrow or red X next to a linked file.

You see the Blue Arrow when the link is loaded and the Red X when it is unloaded or not found. That's true until Worksets are used. If a link is assigned to a workset and that workset is closed the Red X will appear, which will indicate that the link is no longer "present or visible", not that it is unloaded but it's much the same, in a way.

If you open the workset again the X doesn't go away immediately. It will if you do a Reload Latest (assuming there are changes to load), SwC or reload the link itself.

Reloading Links and Worksets

In past releases of Revit, prior to 2014, a linked file that is unloaded would get passed along to other users as they used SwC or Reload Latest, the file would be unloaded in their session too. It was a global effect, affecting everyone. In contrast using Reload on a linked file only affected the person doing the reload. Other users would not see the file as reloaded if they used Reload Latest or SwC. That meant Reloading a link was a local or personal change while Unloading a link was a Global change, affecting everyone.

As a result we started assigning individual linked files to their own worksets. This gave us discreet control over the unloading and loading of links through the workset dialog instead. Using Close and Open for a Workset is regarded as a local or personal change and doesn't spread out to other users on the team.

In 2014 I find that both Reloading and Unloading a link is now propagated to other users when using SwC or Reload Latest. They are now both global transactions.

This means it may not be necessary to bother with the Workset approach to manage the links now since it was originally put into practice as a workaround to avoid the reloading/unloading link "dance". By dance I mean, everyone gets a link unloaded and then we all end up trying to get the link reloaded each time we SwC or Reload Latest because someone else has unloaded it. This change doesn't eliminate the dance entirely. It just makes it easier to get the link re-established by one user so everyone else can see it again.

If you prefer to treat the unloading (and therefore the reloading) of a link as a personal or local change then the practice of one workset per link remains useful.

Overlay VS Attached

A question posted at AUGI started out simply by asking if this concept is the same at AutoCAD. I replied, "Exactly the same concepts". Then another member expanded on my reply and it seemed to muddy the water for the person who wrote the original post because when they replied it sounded like it was still unclear. I wrote this longer reply and decided to put the explanation here too.

Choosing between attached or overlay is to determine how Revit should regard a link when the host file is linked into yet another file. For example, if File 1 is linked into File A and set to "attached", when File A is linked into File B, File 1 will also also be loaded into File B. If File 1 is changed, when its host File A is reloaded in their host File B, File 1 changes will also be seen, if its own changes have been saved before Reload is used. Both files are read independently during a Reload. You will only find the host File A listed in File B's Manage Links dialog however. Written another way, when a link is reloaded, it's attached nested links will also be reloaded.

When Overlay is chosen instead File 1 does not get loaded into File B. No circumstance will cause it to appear nor will we be aware of changes within the link.

We should use the "Attached" setting when we link a file into another file AND expect its own linked files to show up as if they are native elements in the file too. Changes in either the parent or child will appear when the parent file is reloaded into its host or if the host file is opened after changes have occurred in either.

In practice, if we create an architectural model (parent) that uses linked files (children) for repeating units they will need to be set to Attached if we want the units to appear when the "parent" architectural model is linked into a structural model. When we pass along our model to the structural engineer we will need to send both the "parent" architectural model and the "child" repeating units. When we link in their structural model we should use "Overlay" so Revit does not try to load their structural model when the structural engineer links our architectural model into their own model.

Clear as mud?

Concrete Steps

Revit doesn't seem to like generating a smooth underside for some stair configurations. A post at AUGI asked about making what seems like simple concrete steps. Yes, they do look simple. The stair (and railing) features sure have a lot of buttons, dialogs and subtlety. There is definitely no easy button unless you are satisfied with whatever the stair looks like after you place two points to create a straight stair. This is the image that the original post included at AUGI.

Years ago I picked on Autodesk because the stair and railing features couldn't easily be used to make the stair in their building's own ground floor atrium/foyer. They've moved since and there aren't any featured stairs now. Coincidence? [evil grin]

Revit doesn't mind creating the steps if we choose the "Stepped" option.

This is what the sketch looks like.

Keep in mind that the "end" of a stair like this needs a riser not a boundary sketch segment. That's why the sketch line at the top of the steps is black, not green. Creating a stair that ends at a landing can be a bit counter-intuitive, I wrote a post about that condition some years ago too, it's called "A Flat Slope".

A little bit later I was doing something with a floor slab edge and it occurred to me that I could use a slab edge profile to create the steps too. So this is the result of a profile family applied to a Slab Edge type and then applied to three sides of the floor edge. I made the top step the floor so I'd have three edges to work with. If I wanted a joint between the floor slab and the step I could just make the top step a floor and create another floor behind it for the building's floor slab.

Here's the section through the steps and floor (on the left) and the profile family in the family editor (on the right).

The section of the step profile shows that it extends under the slab. I did that so I could use Join Geometry between them and clean up the lines between them. Assigning the same material to the Slab Edge type means that the concrete pattern flows between them nicely. The view from below the steps reveals the nice sloped slab edge that results from the slab edge profile. Compare that against the stepped version and this one looks more realistic from a construction perspective.

Now all I need to finish it off is a short foundation wall to close up the space behind the steps and the edge of slab. Something to consider for those little steps you need for your next project.