Disk Space (Length?)

So you probably came across these highly informative messages at some point:

What Revit is usually trying to say is that there isn’t enough disk space and it cannot sync with central. The above were displayed on the same project, whose units were set to Imperial, so I’m not sure why Revit had a metric fit there for a moment. It appears that disk space is perhaps being measured per length of track on the disk? Ah shucks, don’t try making sense of it, just know to look at how much hard drive space (or perhaps network disk space) you have next time your users get these gems!

Disk Space (Length?)

A Stinkin' Simple Railing - Part 1

When long-time users pour so much passion and energy trying to make Revit better through constant feedback, they eventually get burned out and exhausted when they do not see significant change, version after version. Sadly, I find myself in that situation and it is getting harder to stay positive about Revit, even though it is still my preferred software of choice (how about that for leverage?). The way Autodesk have been treating its development these last couple of years is nothing short of appalling. They seem to have forgotten the “works like an Architect thinks” mantra and sadly too often Revit seems to work like a clunker and thinks like a delusional Architect instead. The API keeps improving, which is great, but I expect a heck of a lot more from the exposed part of a platform that is briskly coming up to its 14th birthday since becoming commercially viable. If software age is more like dog years, one can safely say that Revit is no teenager.

In the spirit of (desperately) trying to stay positive, I’d like to write about all the problems with the “new” railing tools. Nowadays for Autodesk, “new” means less than 20% completion. I wish I had that luxury myself, so I’ll just roll around in envy for the time being.

I documented these while trying to build a simple, wall-mounted handrail commonly found in fire escape stairs. Since there are too many issues to list and document in one post, I’ll do it in multiple parts so I can be of service to my loyal readers. Some might not see this as being positive but in my book, the first task on the path to improvement, is to acknowledge your problems. I will suggest workarounds and best-practices where possible.

Some bugs have been resolved in Revit 2014, but not all projects I deal with are in that version (actually as of now, very few are). Template versioning has become a real headache where things work differently depending on what template version a project was started from: the upgrading process alone is unlikely to guarantee nirvana. Note that everything I’ll be posting about has been confirmed through Autodesk Support.

BUG #1	Occurs up to
Posts in “old” railing on “new” stair	Revit 2013 SP3*

STATUS: Resolved in Revit 2014 SP1 *only if you start a project from a 2014 template.

If you had a previously working old railing definition that used posts to define extensions and you used it on the “new” assembled stair, the posts do not display in plan. Your existing projects are not going to get fixed through an upgrade to Revit 2014. In this case you’re going to have to re-build them with a different railing definition. As you can see below on the left, the railing works on old sketched stair definitions but not on the assembled stair. If you start a project from a new 2014 template and copy & paste the faulty railing definition shown on the right, it works. Why not when upgraded? I have no clue.

 

BUG #2	Occurs up to
Terminations not visible in plan	Revit 2014 SP2

STATUS: Unresolved

Termination families do not represent themselves in plan views but when you hover over the railing, you see the invisible outline of the termination family. Visibility should be controlled through the family subcategory and detail levels, but this is not happening. So if you were thinking creatively of using a termination as a railing extension to get around other buggy behavior, forget it.

 

BUG #3	Occurs up to
Align tool on supports doesn’t work right	Revit 2014 SP2

 

STATUS: Unresolved

The align tool does not work correctly on supports when handrails are sloped. When they are flat everything is fine, but if it slopes (which is the most common), the support is moved by the incorrect distance and it takes several subsequent alignments to get it close to where you want it - it never properly aligns, just keeps getting closer and closer. Workaround: Use the move tool in lieu of Align.

Stay tuned for more bugs and “as designed” issues. Happy New Year!

A Stinkin' Simple Railing - Part 1

AU 2013

Are you ready for AU 2013?! I am very excited to be attending and participating once again. This year it is a little bit more special since I’ll also be part of the Global HOK BIM Summit on Monday before AU kicks off. It will be great to put some of the best BIM brains in one room and talk face to face.

This will also be the first time I’m presenting a class on my own, so we’ll see how that goes! The topic wasn’t an easy one for me to fully grasp, and I hope to make it easier for the 380 registered class attendees to understand (Navigating Through the Storm Using Coordinate Systems in Autodesk Revit). See you soon!

AU 2013

Copy/Monitor & Batch Copy for MEP Update

NOTE: This is a re-post from the HOK BIM Solutions blog

In the previous post, I made a partially correct statement and want to elaborate more on it. I said that re-hosting doesn’t work, but turns out it just failed in my particular test files due to some special circumstances. In general it should work.

When re-hosting fails

In the test files, ceiling-based fixtures were used. When this model was linked and I ran Copy/Monitor, Revit took that ceiling-based fixture and modified it without my knowledge (no warning was ever issued). The copied fixture was not the same version as the original one and it turned into a pseudo-version of a face-based family that is different than a true face-based family: Geometry was on the bottom of the face rather than the top, and there were “remnants” of the original ceiling-hosted fixture, such as a “Ceiling” reference plane. When I tried re-hosting the pseudo face-based fixture, Revit complained and wouldn’t do it.I suspect that the above is due to the trick that Revit is trying to play. Here is the original fixture:

The following is the modified copy/monitored fixture. There is a perfectly valid reason Revit did this, because in the host model there is no ceiling geometry:

However a true face-based family would be like the following image. Note how geometry is built on the top face and there is no “Ceiling” reference plane. I think this is the reason that Revit is unable to re-host the family shown above.

When re-hosting works

When copy/monitored fixtures are face-based from the start, Revit does not need to do modifications on the fly as described above. In this case, re-hosting works as expected. So if you are faced with copy/monitoring of hosted fixtures other than face-based, such as ceiling or wall-hosted, make sure to use the type-mapping feature, so hosted fixtures are substituted with pre-loaded face-based families.

Final thoughts

There is definite room for improvement in linked model workflows, especially for the MEP disciplines. The recommendations for transferring light fixtures from a design model to the final documentation model are as follows:

1. Use face-based families whenever possible and name hosted fixtures clearly so they can be recognized and substituted;
2. Use the batch-copy feature and specify the type mapping so hosted fixtures can be substituted with pre-loaded face-based fixtures;
3. If you are not going to monitor fixtures for changes in location, do not use the dedicated Stop Monitoring tool. Instead, remove the link and re-link again when needed. This way copied fixtures can be moved around freely without the need to re-host them.

Copy/Monitor & Batch Copy for MEP Update

Copy/Monitor & Batch Copy for MEP

NOTE: This is a re-post from the HOK BIM Solutions blog

The Copy/Monitor tools tend to be a Love/Hate relationship in that very order. In fact we have recently been using the batch copy functionality because we sincerely love it due to its flexibility. But that love is fading quickly due to some unexpected repercussions.

A common scenario to employ this tool on, has been when a Lighting consultant/designer is working in a separate model (for design purposes only, not for documentation) and our Electrical Engineers need to circuit these lighting fixtures and document them in their power and equipment drawings. These fixtures need to be hosted in the electrical model for proper circuiting. Copying and pasting fixtures one by one from the linked lighting model is highly inefficient. Opening the source model to copy and paste into the documentation model also doesn’t work due to hosting issues (most of these families are face-based and cannot be pasted) and also due to the fact that Paste >> Aligned to Same Place uses the Internal Coordinates to determine location and this is not always consistent between models. On a side note, best practice dictates that you link other discipline models via Auto – Origin to Origin to avoid these problems.

We have received several reports and anecdotes of performance degradation when copy/monitored fixture counts are high, so we have been disabling monitoring soon after the copying is complete and resume with manual coordination from that point on.

Unfortunately when you stop monitoring by using the dedicated tool, MEP categories become pretty much useless as they can no longer be modified!

EDIT: Refer to this post. If you try re-hosting, you have to use the workplane positioning option, which is not desirable. I am not sure why Revit even asks you to do this because copy/monitored elements do not have a host in their properties.

There seems to be no work-around, short of deleting all fixtures and starting over, which is really bad. Lesson learned: Do not stop monitoring with the dedicated tool! If you want to stop monitoring, remove the link. Once you do this, none of the MEP categories will behave as shown above and you can freely move them around and re-monitor at will. These categories then pretty much start behaving as Levels, Grids, Columns, Walls and Floors, which we can stop monitoring at any point without experiencing the same repercussions.

At least we now have a plausible workflow for future projects and the love for the batch-copy tool has been (cautiously) restored.

The nice thing is that you can specify type mapping and only batch-copy one fixture type at a time. Just make sure that if you want to use this as a pure copy tool with no monitoring, to then remove the link soon after. You can re-link it back in, but this is currently the only safe way to stop monitoring without putting future revisions to the position of these fixtures in jeopardy. Autodesk has recorded this behavior but there is no estimate when this will be addressed.

Copy/Monitor & Batch Copy for MEP

More on Keynotes

This is a quick follow-up post to this one on the topic of keynotes. I have to confess that this is one of my least favorite tools in Revit. Not because of the potential of using keynotes in documentation, but because of the overall lackluster implementation in Revit, which tends to leave a lot of holes in the workflow.

We have also been plagued by too many visibility and collateral issues in the past:

• Pre-Revit 2013, keynotes didn’t work properly in dependent views (never posted here about it after reporting the issue, but it was resolved in Revit 2013);
• Borrowing of Sheet Worksets when keynoting elements in Linked Files as explained here at the Revit Clinic in pre-Revit 2014. This has been addressed in the current release as explained here, which is my primary reason for upgrading existing projects to 2014;
• Besides the visibility issue noted in my previous post, keynotes buried in design options, even if not visible in the view due to V/G settings, still schedule in the Keynote Legend (thanks to Trey Klein for this one!);

I’m sure there are other issues, such as the inability for multiple users to edit the keynote text file, API limitations that prevent developers of Keynote plugins to reload a modified keynote text file as soon as it is modified, and the list goes on.

Steve Stafford has a very good post on the topic if you’re into using this functionality. My biggest point of contention with keynotes is the over-use of User Keynotes, which increase “laziness” in updating Revit families in content libraries to actually include keynote information and discourage abiding with firm standards (assuming they exist). There are instances where keynotes need to be placed on the fly such as in addition & renovation projects containing demo plans, where you’re mostly assigning “actions” to collections of elements rather than definitions/”nouns” to singular elements. However in most cases, I encourage users to first assign a keynote value to their families, and then place Element Keynotes instead.

If you’re a heavy keynote user, you absolutely have to use a plugin. Mr. Stafford references a very good one by Steve Faust of Revolution Design, called Keynote Manager. I believe this is the first plugin ever built to address keynoting inefficiencies and is nowadays a very mature and full-featured product. I have been toying around with another one recently from KiwiCodes called Keynote Browser. It is still not as fine-tuned as the Keynote Manager, but could be a slightly cheaper alternative if you don’t need as much functionality, although at the moment Steve’s solution is much more solid and reliable.

More on Keynotes

Phantom Keynotes

NOTE: This is a re-post from the HOK BIM Solutions blog

We have had several users report that some items in Keynote Legends could not be tracked down in any sheet view, even after verifying that keynoting default settings are correct. This issue had me scratching my head for a while until I figured out what was going on.

Here’s a typical scenario where this could occur: You have a core & shell project that was documented and under construction and the model gets copied as a new project for the Tenant build-out phase. As the model cleanup process commences, users start reporting that they cannot find some keynotes that are being reported on the legend.

While troubleshooting, I noticed that when enabling the view's underlay, the phantom keynotes showed up together with the tagged elements, which then led me to tweak the view range and ultimately discover how these project files were started and what the root of the problem was: when the view range was adjusted, keynoted elements were no longer visible, but still reported in the Keynote Legend. As you can see in the image below, a plumbing fixture was keynoted and properly listed in the legend:

In another view, the cut plane and top plane were lowered until the element and keynote were no longer visible in the view::

In the above image, you can also observe that right-clicking the family type also reveals that the object is not visible in the view, yet it reports in the legend. Note that hiding the element and/or tag in the view makes the legend update accordingly, but in the above example the legend is misreporting.

This has been confirmed as a bug and slated for a future fix. In the meantime, please be careful and use this example to help in your troubleshooting efforts.

Phantom Keynotes

Cut Representation of Slanted Columns

NOTE: This is a re-post from the HOK BIM Solutions blog

We have confirmed a bug with the cut representation of sloped Structural Columns in views set to a Coarse Detail Level. (EDIT: the bug seems tied to the symbolic linework that shows only in Coarse). This issue occurs in Revit 2014 SP1 and in prior versions as well.

The Structural Column family in the following example was set to not show pre-cut in plan views. When the Detail Level of plan views is set to Coarse, the cut representation is inaccurate. In this example, the slanted column (End Point Driven) was modeled in an elevation view from Level 1 to Level 5 and later stretched past these extents. A view associated with Level 1 (Fig. 1 – click to enlarge) was modified to have the same cut plane location and bottom plane as another view associated with Level 4 (Fig. 2 – click to enlarge). We expect the cut representation to be unaffected by the view’s Detail Level, however as you can see the column cut representation is incorrect when this is set to Coarse:

Fig. 1

 

Fig. 2

Also slanted columns, stairs and probably other categories, are not respecting the view’s Depth Clipping settings and are shown in full projection below the cut plane. Until this bug is resolved, please use caution and avoid setting your plan views to Coarse Detail Level when locating interior objects and equipment around slanted columns.

Cut Representation of Slanted Columns

RU going to RTCEUR 2013?

I had the pleasure of attending RTCNA 2013, which was held in gorgeous Vancouver, Canada. The best part was obviously meeting and hanging out with my peers from HOK, including some old and new friends. There is no substitute for meeting in person and it was great to do so after months of web meetings and conference calls.

As expected, RTC was worth its weight in gold. The level of most classes & labs and their presenters, were totally worth it. This is the conference you should seriously consider if you’re an intermediate to advanced user. But so should you if you’re a newbie to Revit! Autodesk University caters to a lot more than just Revit, so the abundance of Revit classes tends to be, shall I say, a little watered down in comparison, which is why year after year, advanced users tend to leave somewhat disappointed with the content. In the end, you cannot really compare them against each other as they are distinctly unique.

I truly wish I could attend the inaugural RTCEUR 2013 in Delft in late September. The venue is fantastic and I have no doubt that our EU BIM counterparts will have a slew of great classes and labs to impress with. It is going to be refreshing to see some presenters and material originating outside the US, not to mention how great it would be to hang out with David Light once again! There’s still time left to register, so if you’re still thinking about it, don’t! You will not regret it.

RU going to RTCEUR 2013?

Upgrading Models and update to Revit Make Local

It is that time of the year when users start transitioning projects to the newer version of Revit. The first service pack was released this week and most now feel comfortable making the transition.

I am always amazed at how many out there still use the Revit Make Local utility I created years ago, which was last updated in April 2010. I’ve received numerous comments and emails over the last years requesting an update. I have even had a few come to me last week at RTC in Vancouver to thank me and asked nicely when I was going to update it to work with Revit 2014! So I finally cracked down under the pressure and spent some time brushing up on AutoHotkey again (I need to build some scripts at work anyway) and made the necessary changes. You can download the latest Revit Make Local V5.1 and try it out. Please note that I have only tested in 2013 and 2014 OneBox, but it should work on stand-alone and past versions as well. It is becoming a royal nightmare to support all versions of Revit because there are so many variations between them (varying journal file and executable paths, different journal contents, the arrival of OneBox, and now also the obsolete Programs folder in 2014!). So this might truly be the last update, but if it does require more work in the future and I decide to indulge, I will drop parts of the script that support older versions to simplify things.

This brings me to the real intent of this post. Why do users still like this utility instead of the built-in local file functionality? Because besides the fact that local files do not go into their dedicated folders, there is absolutely no safeguard from accidental upgrading. It is astonishing to me that we still don’t have anything built-in to address this issue. The current upgrade dialog is only displayed after upgrading starts and does not present us with the opportunity to cancel, not even the “X” button at the top-right corner.

There are possible hacks to find which Revit version and flavor was last used to save the file (this avoids the use of a naming convention as required for the Revit Make Local utility), but there is nothing visible to the user in the operating system that displays the file version. You have to open the file in Revit to find out.

Revit is typically very verbose. It issues plenty of warnings and dialog boxes to keep users informed and usually even demands their input. However when it matters most, it doesn’t even pause and ask for user feedback. We really need to be consulted when an older file is about to be upgraded so we can take a decision and not just inform us after the fact!

The upgrade process is a massive painful exercise when you have a ton of linked files, especially if you forget to close the appropriate linked file worksets (I just close all of them when upgrading). I think we need a dialog like this that provides the following options:

Note: The above mock-up was created with Pencil.

What do you think? If you agree, I encourage you to send feedback to Autodesk directly and reference this post.

Upgrading Models and update to Revit Make Local