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.

Transfer Project Standards and Shared Coordinates

These two are not friends. They are even less friendly when worksets are involved. In earlier releases the project base point and survey point were assigned to Workset1 (2012 and older). In a post some time ago I mentioned a support issue that IDEATE's techs encountered where a user assigned them to a different workset and eventually deleted that workst. It resulted in unpleasant crashing.

If you look closely in 2013 and 2014 you'll find they are assigned to a workset called Project Info and we can't change that anymore.

Unfortunately the more mundane information like the project name, number, issue date, client name and address and many more are also Project Info.

When we use Transfer Project Standards hoping to share the same mundane project info with related linked project files (seems a reasonable expectation) Revit wants to transfer project base point and survey point information too. You'll get this dialog when you fire up Transfer Project Standards (TPS).

This is what my dummy project looks like before using TPS, note the Survey Point's coordinate values and position.

Here's what it looks like after TPS is done. The project base point and survey point have reversed their orientation to one another and they are very far apart now (I zoomed in closer though), far enough that the walls are tiny and hiding under the project base point icon.

If two files are already sharing coordinates they aren't immune to this "feature" either. In my testing I find that the coordinates still get messed up if I use Transfer Project Standards and Overwrite in order to pass along the other project information. It appears that the safest thing to do once Shared Coordinates are established is... DON'T Transfer Project Standards AND leave Project Info selected.

I think that the Project Base Point and Survey Point should be more isolated so they have their own Project Setting based workset, not shared with other Project Info. I'm glad they made it harder (impossible) to reassign them to a different workset to eliminate the other problem I mentioned earlier but they've introduced a new quirk as a result.

I find it mildly amusing that Transfer Project Standards acronym is TPS...reports anyone?

Linked Ceiling Hosted Light Fixtures and MEP

A ceiling hosted light fixture can cut the host ceiling. When an architect uses one of these fixtures the ceiling surface the Revit MEP user has to work with actually has a "hole" in it. This means that they can't put their own light fixture in the same spot because there is no ceiling there.

Technically that's an oversimplification. We CAN put a fixture in the same location but there isn't a face for Revit to detect easily. If you try to use the Downlight - Recessed Can family it's origin is too far from a ceiling's grid pattern to let us put it within a tile. We can put it in randomly and then move it to the correct location. We'll get yelled at though, the light isn't properly hosted now.

If we do the same sort of thing with the troffer family (2x4 fixture) it will be a bit more tolerant as well as not losing its face association.

This sort of discipline collaboration isn't tons of fun.

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.

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!

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!" :)

Revit MEP - Free Size Parameter

If you use the Free Size parameter instead of Size you might notice a subtle anomaly.

In elevation views where we only see one dimension of a duct Free Size does not switch between WxH and HxW, the Size parameter does switch. In other views they both display width x height. In section or elevations that show the profile of a duct both dimensions are measurable and each parameter is consistent, they default to Width x Height.

It does seem like an oversight on their part, they ought to be consistent whether we use Size or Free Size.

Synchronize with Central and Referencing Elements in Linked Files

A post yesterday at RFO reminded me I've not written about this situation before. Generally Revit supports applying dimensions to elements that are in linked files (tagging too). If we go down that road a paradox of sorts can occur as several of us are working. RFO member AnthonyB did a nice job of explaining the conditions he encountered. The following is based on his example, applying dimensions to linked walls:

Model A has walls and Model B has dimensions. Larry adds some new walls to Model A and uses Synchronize with Central (SwC). Then Larry opens his local copy of Model B and adds dimensions to his new walls followed by using SwC.

Meanwhile Darryl already had his Local File of Model B open doing other things and Larry's changes all happened while he was working in this file. When Darryl uses SwC to share his changes he gets a warning message like this one.

Further, since Larry added a couple tags on walls, in the link, Darryl's message includes something like this one. The host elements (walls) are not present so Revit wants to toss the tags too.

We must take extra care when we choose to reference elements in linked files. If your project uses this approach you'll need to let others know that they should use Manage Links, select each affected link and click Reload BEFORE using SwC. This will ensure the elements that your current project file is supposed to see, will be. Be careful out there!

Can't Select DWG

With Revit 2014 came new selection filtering for linked files and pinned elements.

If you find yourself scratching your head when you can't select a DWG file you just imported...remember that Revit will often pin the DWG. If you've turned off both selection options that'll make selecting the DWG doubly difficult! Been there done that!

View Templates are Mean

If you do something that prompts Revit to pop up this kind of warning (this one is about Spaces)...

You'll be tempted to answer Yes with the expectation that Revit will show your spaces. Well you'd be wrong if your view is assigned to a view template. As in this example if you place a space (using Revit MEP features) you'll get this warning next.

Aggressive view templates will deny the override that the warning dialog implies. It's like asking your mother if you can do something and she says yes but then your father says no. It makes sense but the warning message can be confusing, at least initially. You still have to edit the View Template so it will show whatever category you really want to see.

Thin Lines and Printing Sheets

Reading reports (at RevitForum.org) of the Thin Lines feature affecting the output when printing from sheet views. In my own quick test I'm seeing the lines of the titleblock being printed respecting Thin Lines being on which isn't good.

The model views appear to be printing correctly, just the title block's own lines seem to be affected. When I printed a model view using Thin Lines the result was the same as with Thin Lines off. In other words, working as we've come to expect, the Thin Lines feature had no impact on printing. Or, we've not noticed it before.

When we use Temporary Hide Isolate we get this dialog to ask how we want the feature to be regarded. If Thin Lines is meant to be able to get printed then perhaps the same sort of warning/option ought to be offered?

Any readers that can confirm this too? Seems like an undesireable "feature".

Model Elements on View Worksets

The gang in Autodesk Support and Development seem to have isolated at least one clear cut cause for this quirky situation where a model element is associated with a view workset. It shouldn't be possible ordinarily. Apparently this sequence can be blamed:

1) The user selects and enters an edit mode for an element on a view workset, for example this might include plan regions, detail groups, or filled regions.

2 )Instead of using ‘Finish Edit Mode’ or ‘Cancel Edit Mode’ the user instead clicks Undo to exit edit mode.

3) Now back in the project, the user starts adding model elements, such as walls. The walls are placed on the current View workset instead of the active User-Created workset (until the user opens the workset dialog or changes the active workset).

Ryan reports that 2014 has been worked on to help address this situation better, if a user takes the steps above Revit will reset the active workset properly now.

The fix for these poor elements has been (and remains) to use Cut to Clipboard and then Paste > Aligned to Same Place. Just make sure the correct workset is active.

You can read the original post at The Revit Clinic, thanks Ryan!

It also explains how to fix the issue in older versions of Revit.

Fittings Do Not Look Right

A troublesome thread popped up at RevitForum.org the other day and DMapes came to the rescue. I haven't encountered this peculiarity before, and now that I know about it it's a bit surprising that I haven't. I guess I've just been lucky.

When you use the Underlay setting in Revit MEP you run the risk of altering the way your pipe fittings (duct fittings too in views using Detail Level: Coarse) scale and/or look. Here's a good and bad side by side.

The pipes on the left are good but those in the view on the right are smaller and halftone, as a result of using the Underlay setting.

Set to None the fittings look correct, but using the same level the fittings are associated with as the underlay equals sadness. It doesn't seem to mind if you use other levels as the underlay though. Careful with your underlay!

Reusing the Same Grid Names

A reader saw a post by Brok on the HOK BIM Solutions blog and he wrote to me about this tip. His name is Mr. Smith, yeah uh that's his name, Mr. Smith... Well anyway the tip is this. We can use the right click option to insert unicode control character when editing the grid name parameter.

If we choose one it won't print but it will make Revit think that this grid #1 is different from this other grid #1. Pretty sneaky.

Mr. Smith's name has been changed to Mr. Jones to protect Mr. Smith.

P.S. My 2014 prediction is still that Revit will still be called Revit.

Revit HotFix for 2012

Recently people reported a Windows update causing the blue annotation symbols and temporary dimensions to change their color in Revit 2012 versions. I saw it too. Autodesk has release a hotfix to resolve the .net version issue that created the situation in the first place. The Revit Clinic wrote about the hotfix earlier today. You can go to the site to check out the ReadME file and download the HOT FIX HERE.

Revit MEP Heating and Cooling Loads Results

I received an email from a Revit MEP user asking about results that don't seem to make sense. I'm writing about this because after some experimentation it seems odd to me too. This doesn't involve a complex model, just a simple test they did using a single room. I attempted to mimic their emailed explanation fully realizing that there are myriad possible things I could do differently. Despite the possible variables I was able to reproduce what they were concerned about.

Still Curious?

When they set up a test and then changed one variable (Outdoor Air) the resulting report shifts peak cooling month by one month (their result).

These are the test conditions: Walls surrounding a Space such that it is 100 SF. I placed a floor, ceiling and roof but I don't know that they did that. I used these settings for Occupancy, lighting and power.

These are the energy settings I used for the first report.

These are the energy settings I altered for the second report, only changed the Outdoor Air setting, nothing else.

These are the two reports side by side. Report on the left is the one without Outdoor Air changes and the one on the right is after changing Outdoor Air. Notice the two month advance? There are also subtle Dry and Wet Bulb values.

Their question to me and mine now as well is, "Is it reasonable to expect a so called simple change like this would cause such a jump in the calculation time frame?" I've recommended they reach out to the Autodesk Revit support team so they can examine their dataset first hand. Seems odd to me though.

I should also mention that I changed the Outdoor Air for both the Zone that the space belongs to and the Energy Settings dialog. I didn't seem to matter when I tried changing only one of those for the Outdoor Air.

Comments?? Did I miss something obvious?

Trey Suppress Spaces

Okay this is a follow up to redux. Erik pointed out that we can still override the dimension style to ignore the project settings and Suppress Spaces. Here's what a string of dimensions look like with no overrides in play.

Here's what the same string looks like with overridden dimension style and Suppress Spaces on. Notice that the dimensions are tighter (good) and the prefix and suffix are closer too (not a better look though).

This means that we can still get what I though we lost. It seems the Suppress Spaces option is limited to altering the prefix/suffix while the dimension style needs to be overridden to get it.

Since I can put a space in between the prefix and dimension value, same for suffix, I'd prefer that the style could use the more obvious Suppress Spaces option and let the dimension stay connected to project units. I'd be far more likely to use it that way than ever use it to mess with prefix and suffix which I seldom use in conjunction with a real dimension value either, definitely the exception rather than the rule.

Manage View Templates Button Disabled

If your Manage View Templates button is disabled it means that you've got no view templates to manage. That troublemaker "someone" deleted them all. Time to find that someone? You can start rebuilding from scratch if you just right click on a view name in the Project Browser and choose Create View Template from View.

If you have some great View Templates elsewhere you can usually use Transfer Project Standards to get them. Keep in mind that View Templates can touch a lot of settings, for example linked RVT files. If the project you are bringing outside View Templates into doesn't have equivalent features in play then the templates may not be able to do everything they did in the other project. It might not be a problem for this project but it's probably worth double checking.

Show History and a Rogue User Name

I wrote a post recently mentioning that we can use Show History on any file. I saw a post at AUGI that asked how users that claim they've never opened a file might show up in the Show History data. When you use Publish Coordinates to a project file you are altering that file when you save the changes and that change is recorded in the Show History data for it too.

Move with Disjoin

Using the Move tool and checking Disjoin is equivalent to "cut to clipboard" (in effect delete) and then "paste from clipboard". This is necessary to break a wall or line away from other walls or lines that may be connected. Without Disjoin the other walls or lines will attempt to stretch to stay connected.

It is not really just moving the existing elements but recreating them in a new location. This means the elements will get new Mark parameters, assuming Revit numbers them automatically, like doors for example.

If you really need to separate walls or lines (ducts or pipes too) you can move without using the Disjoin option and then manually pull the other elements away from the wall using their own grips instead. A bit more work but maybe less than renumbering elements?

Something to keep in mind.