Do U Revit?

Underlay Visibility Issue in Linked Models

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Wed, 26 Nov 2014 03:55:00 +0000

NOTE: This is a re-post from the HOK BIM Solutions blog. Sorry it’s a bit late, playing catch-up!

It appears that this problem has been around since Revit 2011 but I have not personally come across it until a few weeks ago. We frequently separate Furniture and Furniture Systems into their own models on certain projects to improve on model performance and general working efficiency. Recently one team member noticed that underlay behavior differed when these element categories were in a linked model vs. in the host. This issue could potentially affect other categories but we have not attempted to confirm.

When laying out lighting in a Reflected Ceiling Plan view, designers need to reference Furniture and Furniture Systems by overlaying them. When this geometry is in the host model (in the same model as the ceiling), the user simply sets the Underlay option in the view’s property and carries on with their work as shown below:

If furniture and furniture systems are brought into a view through a linked model, things get unnecessarily complicated and the Underlay option no longer works:

If link visibility is set to By Linked view and the source view has the Underlay option enabled, the underlay elements still do not show. The current workaround is to:

a) lower the cut plane temporarily so it crosses the geometry in the linked model;

b) set up a source Reflected Ceiling Plan view in the host model with a low cut plane (ex: at the floor level and only enable Furniture and Furniture Systems). Now set the visibility of the linked model to By Linked view and use this source view.

I think we can all agree that this is something that needs to be addressed sooner rather than later (confirmed to still be a problem in Revit 2015 Update Release 4).

Upgrade Warning

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Mon, 22 Sep 2014 18:28:00 +0000

With Revit 2015 R2 (don’t try to keep up with version and update identification this year, it’s quite comedic!), we are getting some nice little things. One enhancement that deserves a thumbs up in my opinion is the prompt you get when opening a project that needs to be upgraded, since now the user gets the opportunity to cancel and not be forced to wait until Revit is done. This is especially nice when temporary upgrading of links is involved.

I’ve written about this in the past and so has Mr. Stafford, whose post from today got me thinking. I’m torn between wanting a show-stopper dialog that requires a click to continue, versus the new implementation. The former is better from a disaster-prevention standpoint because you have time to pause and think, especially when opening files that go through the upgrade process quickly and the probability of missing the warning is high. However since Revit does not give us any command-line tools for upgrading projects, nor the ability to suppress warnings, this would be quite disastrous for mass file upgrading via the API. In an ideal world, I would rather get a dialog that the user has to click an option to proceed, as long as we also have the ability to suppress warnings for automation’s sake when we know what we’re doing.

Phantom Keynotes 2.0

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Mon, 21 Jul 2014 15:21:00 +0000

Summer is here and life’s getting very busy, long vacation is over (sadly), now it’s time to get back in the swing of things! I just realized I missed re-posting something on Keynotes and Legends, so here we go…more to come, stay tuned.

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

I posted about this topic in the past (see Phantom Keynotes) and it seems that we keep finding issues with Keynote Legends reporting keynotes that don’t seem to exist in the view. I have also written a follow-up post (see More on Keynotes) to discuss other visibility issues and other problems related to this functionality and the current User Interaction shortfalls. Recently some Electrical users pointed me to additional instances of misreporting by Keynote Legends, so this post will summarize those findings. These can be reproduced in Revit 2015.

If the Annotation Crop Region is not enabled, keynotes attached to objects that lie outside the model crop region are still reported, which is completely unexpected. The result is the same whether you use Element Keynotes or User Keynotes. The expected behavior should be that if keynoted objects lie outside of the model crop region, those keynotes should not appear in the legend, regardless of whether the annotation crop region is enabled or disabled.
Another instance of Phantom Keynotes occurs with keynoted elements in close proximity to the view’s model crop region. This issue is exacerbated even more when the tags are far from the objects they are attached to. With the Annotation Crop Region enabled, the keynote still appears in the legend unless the boundary of the Annotation Crop region touches the edge of the keynote annotation. This is completely unexpected and the following series of images illustrate the problem:

If the Model and Annotation Crop Regions are adjusted such that both the model element and the keynote tag lie outside these boundaries, the legend will rightly not report that keynote:

However the Keynote Legend will still incorrectly report the keynote if only the model element is outside of the Model Crop Region, but the Keynote Tag is within the Annotation Crop Region (the legend is actually only concerned about the tag, not the model element):

Please be very careful when using this functionality and double check your work (don’t assume that the Keynote Legend will hide unrelated keynotes for you!). The only workaround at the moment is to pick the keynote tags that shouldn’t be listed in the legend and manually hide them in the view, which is a very ugly workaround. The following process needs to be followed for each view:

Select all instances of the keynote tag in the project;
Remove all keynote tags visible in the view from the selection;
Right-Click and Hide all instances in the view.

The desired and expected Keynote Legend filtering is as follows:

If the keynoted model element is not visible in the view and as a consequence the tag is also not visible, do not report it;
If the Keynote Tag is not visible because it is manually hidden in the view or because it touches or is outside the Annotation Crop Region, do not report it.

To/From Room Door Parameters

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Fri, 18 Apr 2014 23:54:00 +0000

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

Prior to Revit 2014, these parameters were very unreliable and prone to error. With Revit 2014, we saw the introduction of a new family parameter called Room Calculation Point, which can help with reporting consistency. However be mindful of the fact that this setting has to be manually activated, otherwise the information will remain as unreliable as before. You can read more about the topic in this RFO thread.

Here are some facts about how these parameters work without the Room Calculation Point enabled:

If rooms already exist on either side of a wall when a door is inserted, the room on the swing-side of the door will be set as the To Room;
If the door is then flipped, the To/From Room parameters do not update. The user has to make manual adjustments if desired;
If no rooms existed when a door was inserted, the first room added to either side of the door will be set as the To Room;
Both doors and rooms have to be in the same model for these parameters to report. The schedule can reside elsewhere, however manual changes between the two reported rooms have to be made in the host model.

As you can see, the reported information is prone to error and highly unreliable. Another big issue is the fact that door swing direction does not imply “ownership”: a door could be swinging out of a room and technically belong to that space. It is also usually not possible to infer hardware functionality from swing direction and door “ownership” alone.

By enabling the Room Calculation Point, we can at least address data errors. The To/From Room parameters will then update consistently regardless of whether the door is placed before/after the rooms, or whether the swing direction is altered after placement.

As with a lot of things in our industry, there is no standard way of documenting doors: some include information for the room that the door “belongs” to, some include both To/From Room information, while others completely exclude these columns of data. I happen to be of the opinion that the latter is the most prudent choice, although the Room Calculation Point parameter makes me less concerned about data inaccuracy. However be very careful: changing the To/From Room parameter when the Room Calculation Point is enabled, will actually flip the swing direction! This is a behavior change that you really need to be aware of.

If you happen to use the To/From Room parameter to report “ownership” only, you can do so with even greater reliability by employing the following trick. The little leaders are hardwired in the family template to prevent them from crossing the Internal X-Axis:

By shifting family geometry, you can then consistently report “ownership”. In the example below, both the To Room and From Room parameters will always report the room on the swing side of the door. Note that you can flip the To/From direction if you need to, although that would not change how these values are reported in the example below:

The other very positive side-effect of doing this is that now you cannot accidentally flip the door direction from the schedule, since both To/From Room parameters will report the same data. If you want to report ownership based on the outswing-side, simply shift the geometry in the opposite direction. Please note that “ownership” rules cannot be changed at the instance level (ex: you have to commit ownership of a door to always be on the swing side at the family level), so if you need to change this and still use the Room Calculation Point, you will have to double up on your family definitions in a project, or employ some of the workarounds described in this RFO thread.

Filled Regions and DWG Exports

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Thu, 03 Apr 2014 19:04:00 +0000

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

This sounds like an odd paring for a blog post subject, but they are unpleasantly related.

When a view contains the following items and you export to a CAD format, you will likely experience loss of data:

Families with nested Generic Annotation such as Security Devices, Fire Alarm Devices, Electrical Fixtures, etc.
A large filled region covering a big portion of the view, usually to identify areas of work and areas outside of work.

This issue was filed with Autodesk Support and it has been known for at least 3 to 4 years. It seems that regeneration of the nested families fails, which results in the absence of these devices in the export. They are actually still in the view, but since in most cases there is no geometry visible in plan except the nested annotation itself, you end up with no object representation. The following are some workarounds, some more acceptable than others, depending on your situation:

Delete/hide the filled regions before exporting;
Change the filled regions to Solid Fill and everything will export as expected. You will then need to open each exported file and change the hatch to something other than solid within the CAD editing software;
Do not use component families with nested annotation. This is obviously not an acceptable solution for MEP (#2 or #1 seem to be the only viable solutions), but might be acceptable for Interiors, where they can simply show these devices through the use of Generic Annotation families placed directly in the view. These can be scheduled within Note Blocks if required, however this workaround means you cannot make these objects visible in other views to properly coordinate your work, or see them in elevations, sections and 3D views.

There is no good workaround for this issue and the best is probably #2. Let’s hope the Factory can get this fixed sooner rather than later.

Revit on Mobile Devices

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Tue, 01 Apr 2014 05:00:00 +0000

These days everything revolves around the “cloud” and mobile devices, so it comes as no surprise that Autodesk announced the availability of Revit 2015 in the App Store and Google Play.

They really worked hard this year to keep the new version devoid of too many new features and fixes. Some users felt quite disheartened when they saw how little their hard-earned subscription money had yielded, but soon realized that this was a well-planned maneuver by Autodesk to increase Revit’s circulation amongst smartphone aficionados. The Marketing geniuses at Autodesk pointed out that subscription has not increased that much if you think about it, since you can re-use all your Revit 2014 learning resources for the forseeable future. Publishers are quite upset as this will likely hurt their sales, but popular authors of Revit guide books are quite happy since they can now enjoy a lavish vacation with their families instead of updating their work. In fact a few have even suggested that publishers simply start printing books in binder format so they could just slip in a couple of pages each year moving forward, and just change the binder cover with a new pretty picture that clearly cannot be done in Revit.

Rumors on the Internets hint towards efforts by hackers to even make Revit 2015 run on the “Jitterbug” or your old Nokia flip phone. I’m quite excited about this potential development, which could increase the use of Revit exponentially and also aid in breaking any existing generational barriers. I’m still quite skeptical about how they’ll manage to get the download package to fit, but I think if they removed broken and incomplete features, the application would probably fit with some extra space to spare.

In the meantime Graphisoft continues in the struggle to capture market share. They think that the cloud has promise as well, and are now playing catch-up to Autodesk once again.

Close sources of mine (sorry, I‘m not about to go Snowden on them) think that this is a huge, visionary move by Autodesk. I frankly disagree, as evidenced by my overall lack of amusement, which is further emphasized by my deliberate omission of any exclamation marks in this beautiful piece of writing.

Revit 2015

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Fri, 28 Mar 2014 17:13:00 +0000

What’s new?

Not much.

Commentary

I give up.

Manufacturer Content - Lighting

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Sun, 23 Mar 2014 21:05:00 +0000

I originally wrote the following on the HOK BIM Solutions blog and have since received some additional comments/observations that I would like to add here before re-posting (thanks a lot to Dan Stine!):

Revit does not support absolute photometry (i.e. LED IES files). This probably has to do with the format of the IES file where there is a -1 in place of the wattage value for an LED file and Revit is not currently able to handle this, which means you cannot produce renderings for LED Photometry.
An IES file describes how light is emitted from a fixture and takes into account all geometry, color, reflectivity and all other characteristics of the fixture. The reflector is only required to be modeled if you’re using a light source to make the fixture look more believable, or through using a self-illuminating material on the lens (the post below will describe all this in detail). These are also invaluable for lighting calculations, not just renderings.
Once an IES file is used, the family remembers the information and a link to an external file is not necessary. This is similar to the behavior of MEP families in 2014 which contain embedded lookup tables (note that even though it appears that the Photometric Web File parameter can be connected to a custom text parameter, it does not seem to work. A support request was filed to confirm if this is a bug).
Things get more complicated when doing lighting analysis such as with ElumTools, which require lighting content to be created with specific standards:

Nested light sources must be shared
Light source ignores all geometry in the host family
Light from nested families “sees” geometry in host family (e.g. shadows from the arms of a chandelier)

Another challenge with rendering in Revit is reflectance. The Daylighting Analysis for Revit uses a formula based on the RGB values of the appearance asset for a given material. ElumTools uses a similar technique (which can be overridden in their Material Mapping dialog) but is based on the RGB value used in the Revit Material Dialog’s Graphics tab.

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

I will reluctantly kick off this post first with a little rant: is it too much to ask from a Lighting Manufacturer, that their BIM content render appropriately? I think not!

I am sure (hopeful, really) that there is good lighting content out there, but I’d like to take you through a specific journey that in my opinion, was unnecessarily painful and is probably quite representative of today’s common reality. So here we go…a user needed to do some “quick” renderings of an interior, utilizing a fixture by Focal Point called “Equation”. Based on the marketing brochure, this is what these should look like:

Here’s the resulting render using the Architectural family downloaded from the manufacturer’s website (for the purpose of this post, I kept the exposure settings constant so you can easily see the relative differences):

It is clear that the family is built incorrectly. The overall geometry might be close enough (it wasn’t to my liking either, so what you’re seeing in this post is a rebuilt version, where I broke it down further so materials could be assigned to different parts of the family, including the internal reflector), but lighting is not emitting through the fixture. Editing the family revealed that the lighting definition was not set to Photometric Web. The MEP version of the family did have the lighting set to an IES definition, but who do we really expect to do an interior rendering? In my opinion, if you have photometric definitions for your fixtures, you should use those definitions exclusively, no exceptions.

After downloading and adding the IES definition to the Architectural family (which was ceiling-hosted…more on that later on), we end up with this:

This is clearly darker than the original version, so the luminance of the original family far exceeded reality. Now, I understand that we’re not designing a lighting strategy/layout based on a rendered image, but we do expect the result to be perceived as close to the built reality as possible. The IES definition gets us closer, however we still need to do something about the fixture itself. The quickest, most efficient technique is to use a self-illuminating material for the lens, which results in a decent render if the fixtures are far from the camera, but would not be suitable for close-ups due to their “flat” appearance. In the example below, the material’s Luminance setting was set to 300:

Self-illuminating materials add to the general brightness of the image beyond what you get out of the IES definition, but there’s really nothing we can do about that, except tweaking the resulting render exposure to get it close to how we perceive the scene should look like.

For a more realistic look, the fixture needs to be built differently. You need to rough-in the internal reflector, place a tubular light source to mimic the lamp as closely as possible, and then nest the family into another one so you can set the additional Photometric Web light source. Since the family I was editing was already hosted, I nested in an empty family into it instead:

The most noticeable and perplexing issue are the inconsistent artifacts around some of the fixtures. I was able to reduce them a bit by shortening the light source, but they would not go away completely (I think this is a bug, but have not yet confirmed…comments welcome!).

The other issue are the harsh shadows, which are a result of the lens material being incorrect (used frosted glass) and can be easily tweaked as we’ll see shortly. With this method you add a significant amount of light to the scene, above and beyond the Photometric Web definition. The image on the left uses the tubular light source only with no Photometric Web. I noticed that I was using the original family’s metallic paint for the reflector and once replaced with a non-metallic white, the scene improved slightly:

Tweaking the lens material was necessary to get this scene closer to the lighting atmosphere resulting from these fixtures, although those pesky artifacts mean that post-processing cleanup is still required to get a presentation-worthy product.

Just in case you’re curious about the lens material, here are the settings I used after some trial and error (click to enlarge).

What an adventure! I really don’t think it should be this painful to make a “quick” rendering using manufacturer-provided content, especially when dealing with lighting. We really need to be able to drop in such families, complete with appropriate material settings, and move on with our design work, rather than requiring a total rebuild, tweaking of their materials and several test renders.

Lighting Content Building Tips for Manufacturers

Start with a non-hosted lighting family so you can use the light source that is built-into the family template to emit light from the fixture. This also gives you the flexibility to simply nest into any other hosted family template, rather than rebuilding each one from scratch and making change management difficult for you and your users!
By doing #1, the end user can then decide whether using a self-illuminating material for the lens is a better solution and they can simply edit the family to remove the light source (emitting from the fixture) if that is the chosen path;
Nesting into a hosted template means you can now also use the Photometric Web definition in addition to the other light source used to make the fixture appear to emit light. If an IES file is available, the fixture should not use anything other than these definitions. Also, make them downloadable together with the families, not separately! It is torture to figure out which IES file belongs to which fixture and which configuration. See #5 to manage these better;
Include proper materials!
Use Type Catalogs instead of making a plethora of individual families. It is more difficult for you, and for us, to manage them otherwise;
Don’t miss building the reflector and the cavity within the fixture where the “emitting” light source will reside. If you only consider the exterior of the fixture, your end users will have to spend a lot of time re-building them in order to produce acceptable renderings. And once they find another manufacturer that does a good job with their content, guess what is bound to happen?

Creating Non-Hosted Families from Hosted Versions

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Thu, 20 Mar 2014 00:54:00 +0000

I just recently discovered this gem and it seems there are a few people that know about it. Perhaps it was discussed in a forum or some other place, but since I never came across this nice little tip, I thought of sharing it here.

In this post, I talked about a “pseudo face-based family” and this week while I was not even thinking about Revit or anything work-related for that matter, I just had a thought and wondered whether the hosting extrusion could be deleted (I know, my brain is weird sometimes!). So I tested this out and then realized that the resulting family is no “pseudo-anything”, but simply built into a host-less template with the Work Plane-Based option enabled.

So the highly-intuitive process (sarcasm anyone?) of taking a family that is built in a hosted template such as face-based, wall-based, ceiling-based, etc. and produce a non-hosted copy is as follows:

Place an instance of the family you want to hack in the drawing area. You can insert multiple ones at the same time;
Save the file and close it;
Open a new Revit file from no template. This ensures it is completely empty and Revit will thus create this hacked copy when we do step #6;
Link the previously saved model into this new file;
Go to the Collaborate Tab>Copy/Monitor>Select Link and pick the linked file. Once in C/M mode, click Coordination Settings and make sure that the family types you want to hack are set to “Copy Type”;
Click the Copy button and pick the families you want to hack;
Finish and exit from this mode when you’re done.

The copied families that Revit created are hacked versions and no longer built inside of hosted templates. Now simply edit the families, delete the extrusions, set them to not be work plane-based and save them…done!

Now I ask, if Revit is able to do all this, why not give us a stupid button instead of this frustratingly long and obtuse workaround?!

Data Management

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Sat, 08 Mar 2014 18:49:00 +0000

Data management is something we struggle with constantly, and the more we collaborate across the globe and beyond the walls that contain a single office, the more complex it becomes.

I don’t typically post advertisements here, so I’ll keep it short and add my commentary (what, you thought I wouldn’t have anything else to say?!). Imaginit have made a free video available about this topic, demonstrating how Autodesk Vault could address multiple workflows. The first 15.5 minutes of this video are dedicated to an AutoCad workflow, whereas the rest address a hybrid workflow which also includes Revit Server and their related product, Clarity.

To be honest, Vault has never really struck a chord with me because it was built primarily to manage a multitude of files that need to be accessed by one user at a time. This issue goes completely out the window with Revit projects, where the only useable component becomes linked file control. We can already do this in a multitude of ways (ex: Newforma InfoExchange transfers) and Vault just seems like too much complication for in-house collaboration. The only thing that could have some promise is family management and the ability to reference “published” files (as opposed to “live” files) between office locations. For example HOK offices collaborate a lot amongst each other and we utilize a series of techniques, depending on team setup. A simple method entails server to server nightly file copies to be used for linking purposes. This simply automates the transfer of linked files between offices, whereas with external consultants, teams initiate file transfers on a weekly basis via InfoExchange. Vault appears to have some potential to achieve this as well, but just seems like too much technology to manage. Why complicate when you have something that is quite simple and works already?

In the last few minutes of the video, we see a glimpse of Clarity. I think the software has a lot of potential and nice features, such as the Room Data Sheet reporting functionality which is all interlinked with other reports, but unfortunately I believe Imaginit has slammed the doors shut for most companies thanks to the (excessive) price point. I think the enhanced security features that can be added to a Revit Server infrastructure are quite powerful, such as limiting external team access to certain projects. However it is much, MUCH cheaper to simply install a couple of additional virtual servers to host a dedicated Revit Server infrastructure to handle confidential projects.

Imaginit also have a nice e-learning portal called ProductivityNOW. They make some resources available free of charge such as white papers, seminars, tips & tricks, etc., while others are restricted to paid members. So go ahead and check it out, you might find something useful there too!

Disk Space (Length?)

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Mon, 03 Mar 2014 17:02:00 +0000

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!

A Stinkin' Simple Railing - Part 1

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Mon, 30 Dec 2013 19:24:00 +0000

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!

AU 2013

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Sun, 01 Dec 2013 19:22:00 +0000

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!

Copy/Monitor & Batch Copy for MEP Update

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Fri, 22 Nov 2013 03:27:00 +0000

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:

Use face-based families whenever possible and name hosted fixtures clearly so they can be recognized and substituted;
Use the batch-copy feature and specify the type mapping so hosted fixtures can be substituted with pre-loaded face-based fixtures;
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

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Thu, 21 Nov 2013 03:13:00 +0000

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.

More on Keynotes

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Sat, 21 Sep 2013 16:51:00 +0000

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.

Phantom Keynotes

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Wed, 18 Sep 2013 03:16:00 +0000

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.

Cut Representation of Slanted Columns

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Tue, 10 Sep 2013 02:53:00 +0000

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.

RU going to RTCEUR 2013?

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Mon, 05 Aug 2013 12:57:00 +0000

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.

Upgrading Models and update to Revit Make Local

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Mon, 22 Jul 2013 00:10:00 +0000

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.

Revit 2014 Essentials

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Sat, 29 Jun 2013 17:19:00 +0000

I was recently contacted by one of the authors of Autodesk Revit Architecture Essentials 2014 and offered a few copies to review and mention here on this blog. So there you have it: disclaimer – check!

The copies have been put to good use around some HOK offices, so thanks to Tobias for that. As we ramp up on the use of Revit 2014, our users will surely consult this resource and find it of great value when brushing up on their knowledge and exploring new features.

There are also datasets available on the companion web page, which are very useful in supplementing the text (by the way, why is the price on the publisher’s site close to double that on Amazon’s?!). You can also get in touch with the Essentials series authors on the Mastering Revit Facebook page, where you’ll find other very well known authors of the Mastering series as well.

So who is this book for? To quote the authors:

“…for architects, designers, students, and anyone else who needs their first exposure to Revit Architecture or has had a an initial introduction and wants a refresher on the program’s core features and functionality…This book is designed to help you grasp the basics of Revit Architecture using real-world examples and techniques you’ll use in everyday design and documentation…”

Aaron Maller contributed some wise words in his Foreword. In general I like the approach to how chapters are laid out by discussing basic system family usage first and then moving on to more complex concepts, such as component families. I personally would have put the Rooms chapter before having that discussion. Don’t get me wrong, editing and creating component families is an essential skill to move from mere Revit “User” to “Ninja” status, but even prior to mastering it, one should be able to crank out useful floor and color plans, reflected ceiling plans and other types of views.

The desire to discuss component families early on is appreciated, but after dealing with Revit for a few years now, I find it useful to have an overall conceptual discussion about all types of families first so users build an awareness that everything in the model is in fact a family, but have the component family discussion later when they have mastered the essential skills to become productive in the office, capable of setting up views and composing sheets, annotating, and so on. It is not an easy task to agree on a sequence of chapters and to this day, I cannot get my brain to agree with itself on how it laid out the key chapters of my concise Revit beginners course, with moments of “what was I thinking?” still occurring from time to time.

On page 332 there is a good discussion on staffing a BIM project, followed by outlining the roles of the team members on subsequent pages. This is valuable in helping those that have yet to take the leap understand how their current process will be affected.

Anyway, if you are in charge of training users or have never touched Revit before, this book will be a good way to get you going. A digital edition is also available if you prefer. Good luck!

Positioning of Linked Models – Part 1

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Thu, 27 Jun 2013 05:30:00 +0000

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

Much has been said about this topic and it continues to be a source of confusion for users of all levels.

When linking models, unless Shared Coordinates have been properly set up between them all, you cannot position them using this method. It seems to be a common myth that linking models by shared coordinates will “just work” and they will land where expected. Think about it: if you never told Revit how various models relate to each other (distance and rotation), how is the software supposed to just know?

First off, let’s get the terminology straight and lay out some facts.

Fact #1

Every CAD software uses Cartesian Coordinates to locate objects in digital space. You start with a fixed Origin (0,0,0) and three Axes (X,Y & Z). In traditional 2D CAD packages, the Origin and Axes are exposed to the user through visual means, whilst in Revit they are not as “in your face”, but make no mistake: they are still there! This fixed system is essential to position elements in space such as points, lines, planes, surfaces and solids.

To find the fixed Origin in a Revit project, you can either use the older, harder way (link a CAD file that contains some linework drawn at 0,0,0 with Auto – Origin to Origin) or the easier, newer way: Use an unclipped Project Base Point and pick Move to Startup Location in the right-click context menu.

Just in case you forgot how to turn this on, see the image on the left (V/G dialog; make sure at least Architecture is selected in the filter list).

NOTE: In AutoCad, the fixed Origin and Axes are called the World Coordinate System. In Revit we refer to them as the Project Internal Coordinate System.

Fact #2

When you link with the Auto – Origin to Origin option, the Project Internal Coordinate System of the linked models will be aligned to that of the host model. So if at project startup reference models were linked haphazardly (ex: with Auto – Center to Center or arbitrarily shifted around after linking), you are guaranteed to end up with incorrectly positioned models. To circumvent this problem, we can set up Shared Coordinates in each model, share them through “acquiring” or “publishing” tools, and then link with this option. Note that a successful outcome doesn’t happen auto-magically on its own!

Fact #3

In most CAD software, you will find the concept of a User Coordinate System (UCS), which is another Cartesian Coordinate System similar to the World Coordinate System (WCS). A user can define any number of named UCSs and these are positioned in space relative to the WCS. Now you can probably understand why the WCS is fixed since you must have an anchor point in 3D space for relative positioning to work.

When we talk about Shared Coordinates in Revit, we are talking about their equivalent counterpart in 2D CAD: User Coordinate systems. We can define multiple named systems in the Site tab of the Location Weather and Site dialog. Named Shared Coordinate systems (Sites) are located relative to the Project Internal Coordinate System. In Plan views, Project North is defined by the Y-axis of the Project Internal Coordinate System, while True North is defined by the Y-axis of the Shared Coordinate System (the named “Site” per the dialog below):

When you link with the Auto – By Shared Coordinates option, the Shared Coordinate system of the linked models (for the current named “Site”) will be aligned to the Shared Coordinate system of the current named “Site” in the host model, given that Shared Coordinates have been properly set up between models. If you try to link models that have yet to be synchronized (by publishing or acquiring Shared Coordinates), Revit will not allow you to use this option:

Revit has always strived to describe functionality using terms that are familiar to the building industry, but I think that the ones used while manipulating coordinate systems do not work well for most common model linking scenarios. Since terminology is so different from that used in generic CAD programs, it makes things harder to visualize and understand sometimes, especially for users that started in 2D CAD. The main problem with named UCSs in Revit being called “Sites” is that if a consultant is linking parts of a building to parts of the same or another building, they probably do not think of “Sites” for this exercise!

The primary reason for the current implementation is to give us the ability to place multiple instances of the same building around a site (ex: the same home floor plan peppered around a housing development). For most typical project workflows, we just need one “site” definition for the purpose of locating links in 3D space and usually don’t even bother changing the stock site name “Internal” to something else.

In Part 2 of this post, we will look in more detail at some of the most common linking scenarios and discuss strategies to set up Shared Coordinates and linking Best Practices.

What You See is NOT What You Get

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Tue, 11 Jun 2013 17:54:00 +0000

You’re probably familiar with the acronym WYSIWYG. It’s one of the beauties of Revit, where what you see on screen is what you get in your prints. For the most part, that has been true prior to Revit 2013.

I’m surely late to the game in writing about this and it probably makes this post totally useless, but I suppose if I struggled so much to figure out how to fix the following problem in Revit 2013 and Autodesk Support themselves were unable to point me to the correct Hotfix (being told the usual canned response that the development team is aware of the problem but we cannot tell you when it’ll be fixed yada yada yada, even after pushing back to try get more detail), then I assume some soul out there might benefit from these ramblings too. This has been known for a while as you can see here.

Revit 2013 was no longer acting WYSIWYG when specific conditions were present. If certain elements were behind others that were set to 100% transparent and were totally “blocked” by said elements, then you see them on screen but you don’t get them in print. Bad, very bad, especially for Healthcare documentation and Interiors in general.

As you can see above, I said “on some machines”, but this problem actually affected all machines which were just updated to Update 2 but not with the hotfix.

It turns out in my random testing that my machine and another user’s worked fine and you guessed it…I had updated these manually a looong time ago in an effort to cure other problems with 2013, but forgot all about it (you know, the drawing area jumping into the ribbon? Yeah that one, but this hotfix isn’t so hot for that problem). I finally put 1 + 0.5 + 0.1 + 0.35 + 0.05 = 2 together and figured this hotfix actually worked to resolve the above symptom.

Anyway, I also checked that the recent Update 3 (for OneBox)incorporates this hotfix as well, so just skip it altogether and install Update 3 as fast as you can. There are separate downloads for the stand-alone packages.

I sincerely do appreciate the effort that most give at Autodesk Support when you file a Support Request, but sometimes I just cannot figure out how something like this wasn’t documented properly in their internal system and a conclusive resolution offered right away instead of having to deduce it myself. Oh well, that’s enough from grumpy Dave!

Opening Linked Models for Editing

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Fri, 07 Jun 2013 23:46:00 +0000

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

One of Revit’s annoyances is the inability to open a linked model for editing and keeping it loaded in the host project, all at the same time. This leads users to believe they need additional sessions of Revit in order to refer to the fully aggregated model and edit the link/s at the same. Doing so causes various problems, such as reducing available RAM consumed by the additional sessions (0.35 to 0.4GB/session observed) and the potential to run out of network licenses for other users.

Revit’s UI gives us the option to open a link but at the same time, forces us to unload it. Somehow Revit seems incapable of having the same file in memory (based on filename) both as a link and opened independently in the same session. To make matters worse, most of our linked models are workshared, so opening a link in the way shown above is highly discouraged as you would be directly opening the central file. Revit does have safeguards for situations like this and does not let you directly do a Sync with Central if another user has synced since you opened the central file. Regardless, the current workflow of dealing with linked models is highly problematic and not sufficiently well-developed by the Factory.

Luckily we can work around the current limitations when the linked files needed for editing are workshared. We can in fact achieve this in the same session without unloading or requiring the user to open a separate Revit session by following these simple steps:

1. Make sure to not use the right-click option shown above (obviously!)

2. Navigate to the original linked central file and open through Revit’s Open dialog in the same session. If it is a valid Central File, Revit will automatically create a Local File by appending your username to it and happily open it for editing.

3. Alternatively, use the Revit Launcher (an HOK custom tool) to create a Local File for the linked model in question and open as usual.

NOTE: If the link to be edited is not workshared, you are out of luck and need to open it in a separate session if it is important to you to keep it loaded in the aggregated model.

Commentary

There is no doubt that this functionality needs to be polished further. The current implementation might be a reflection of various technical reasons/limitations, but should not be a reason to leave things in their current state. Here are some thoughts:

Revit should be capable of opening non-workshared links directly and leave them loaded in the aggregated (host) model.
If the link is workshared, Revit should recognize this and serve a UI that offers the same options when selecting a workshared file in the Open dialog so we can 1) open a detached copy, 2) create and open a local file so we can make changes and sync them with central (default), and 3) offer the option to open the central file directly.
Give users the ability to edit a link in-context (in-place), whether it is workshared or not. This is not necessary functionality, but would be very nice to have.

Wire End Woes

d.baldacchino@sbcglobal.net (Dave Baldacchino) — Tue, 23 Apr 2013 16:48:00 +0000

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

If you have never seen this issue before and are an electrical discipline user, you are extremely lucky. When adding wiring to electrical or lighting fixtures built in a face-hosted template, sometimes wires jump around in a frenzy every time a fixture is moved. This is obviously unacceptable, but luckily there is a fix. Let’s break it all down.

Symptoms

You place fixtures, add wiring and all is well. Then you make a change and move some fixtures (because that’s what designers want), and the wire ends are sent off flying all over the place. You think about hurting someone, but keep your cool instead.

Analysis

So what causes this? Thanks to a tip from Autodesk Support and further digging, it turns out that there is a potential bug in the face-based Generic Model template, which is probably the one used for your families. When the internal origin of the family is in a different location than the ref. planes that define the family origin, you see the above behavior, where wire connectors jump to the “projected” location of the electrical connector.

Below we can see two instances of the Lighting Fixture above with a wire added between them. The wire end connections match up with those of the fixture, but the wire end graphics are goofy.

When the fixture is moved, the wire connects to this “projected” connector location and thus appears to disconnect and jump around.

The Fix

To fix the problem, make sure the origin defined by the intersection of two ref. planes is at the exact same location as the family’s internal origin. This way the true connector location is used to connect the wire end instead. The positioning of family geometry in relation to the origin is not important for this to work properly. Here is the proof:

Happy circuiting!