Showing posts with label Process. Show all posts
Showing posts with label Process. Show all posts

Friday, September 15, 2017

My Kingdom for a Dimension...or Two...Three

A Friday thought...

I've spent the last couple years doing a lot more modelling work than I expected to do. If you asked me in years before I'd have told you 80-90% percent of my time was dedicated to training and implementation activities.

Much of the modelling I do these days is from the contractor's point of view, for them. I quite enjoy it. I learn a lot and it keeps me on my toes.

This work is requested often because the documents they are using are not created from models to begin with. Sometimes they are but they (the contractor) have to build based on drawings so they find it informative to attempt to build things in the computer before doing it in the field. Where have I heard that notion before?

Chief among the things that trouble me doing so is the lack of dimensions. If there are lots of dimensions then the issue is their message or rather the lack of clear intent.

All too often I find a slab edge plan is lacking that one dimension, between adjacent slabs for example, that I could really use. In other instances the decision to start plotting the dimensions is based on a datum that involves a fussy site related angle (like based on a property line); when other orthogonal options are available.

I've also seen far more effort and devotion applied to dimensions for parking stripes in a parking garage than for the structural elements that make it possible to paint those stripes eventually. Then you have the dimension value bust. Such as, setting out the building grids reveals a subtle mathematical inconsistency or outright typographical error or override.

Then there are the dimensions that describe how to place something relative to other elements that get installed later during construction. How do we place a concrete column by referencing interior partitions...when those dimensions don't relate back to grids or structural elements? That issue is both missing dimensions and logical progression.

Often I have to endure the game of look over there, as if a hockey puck is getting smacked back and forth, when one says look at those guy's drawing for more information and then the other says the reverse. Slab edges that are required to overlap (per nearly matching details) are a real chore to sort out when you have to flip back and forth constantly and double check against the reflected ceiling plans...oops they're inconsistent with the plans...note to generate an email...

Then there are arcs. Thanks for all the radius and diameter information. Could I get dimensions for their endpoint locations and chord height/width? Better still, could I get something that tells me where their origins are supposed to be? Yes I do realize that one or two might be located somewhere on the outskirts of town. Then again if doing so exposes that issue up front when they are sketched, maybe we could get some other localized notion of how to place them on site too?

Though I've rarely encountered it in real life, I've really learned to appreciate the my documents stand on their own philosophy. In other words, a structural set of documents could be used in isolation to build all the the structural elements required, correctly, even if the rest of the work never got funded. It IS harder to do because it requires concerted effort to coordinate the disciplines well.

Yes I know, it's complicated, building stuff is messy. Now that I mention it, have you noticed, like me, that those ugly fractions people don't like seeing on drawings still crop up everywhere in real life.

Ah well, enough complaining. I've got some slab edges to reconcile. Back to grumbling to myself again. May we all enjoy a dimensionally accurate weekend!

Tuesday, October 25, 2016

Load and Place a Family

Perhaps it isn't obvious enough but Revit is designed to deal with loading and placing a family according to context determined by our actions. Did we start a placement process or an admin process?

The component tools like Door, Window, Component, Detail Component, Air Terminal and so on provide Revit with placement context. The Insert ribbon tool Load Family is an administrative task which does not presume placement as a priority.

IF we start the Component > Place a Component tool first. Choose Load Family from the ribbon. In this context Revit knows we intend to place something but using Load Family tells it we need something that isn't already loaded in the project yet. If we choose to load multiple families it is ambiguous to Revit so it chooses for us which family to offer as the family to place now.

When we use Insert ribbon > Load from Library > Load Family separately it is regarded as an administrative task, i.e. "I need to load some things so they are available to everyone." Personally I have had many situations where I need to load families in this way, not place them immediately. If I do want to place a loaded family right away then I start the Component (or Door, Window etc.) tool first.

Tuesday, October 18, 2016

The Family has been Renamed

This warning message is probably familiar, troublesome and annoying.


I was reading a couple threads at RFO; THIS ONE and THAT ONE.

Apart from workset related issues I've written about before, I believe the underlying cause of renaming is that Revit perceives a family as different. That's not very surprising but I think that the actual difference is the result of different versions (2016 vs 2017) or having Save As used on the family (to put it in a different folder)...AND any operation that involves Copy/Paste, which includes the Insert from File tools.

When Load from Library > Load Family is used I only see it occur when worksets are being used (see the links at end of this post). The families merely having some different parameters (either instance or type) generates the dialog asking how we want to deal with the existing definition.

Using Revit 2017.1 and passing a family from one project to another I observed the following:

Family is renamed but no warning message:
If the family being introduced is an older version (upgraded) of one already in the model
If the family is same version but has had Save As used on it, i.e., to put it in a new folder location

Family is renamed and the warning appears:
If the family is an older version or Save As version AND Insert from File is used

Family is not renamed:
If the Family is copied from same library folder to a new folder
If the Family is from the same library folder
If the Family (existing) is reloaded from older version before using Copy/Paste or Insert from File.

The issue can be avoided if we are meticulous about using families from the same library and version. If we load office details from a detail library project file using Insert from File and the families (some or all) involved are based on older versions while newer versions are already present in the project we'll incur the renaming penalty.

The detail library should be updated, have the newer versions loaded first so they will be the same as those in the active project. If we need to keep the detail library in more than one version then we'll have to decide how to manage that and for how long. Merely upgrading the detail library model does not appear to be sufficient to avoid the issue.

I ought to mention that I can load a family and let it upgrade. Then if I use Copy/Paste to pass it along to another project file it does not get renamed unless the existing family in that project is based on a different version than the one I just upgraded. Upgrading a family does not seem to create the same problem that using Save As does for a family, at least not in the context of Revit treating it as a rogue family competing for the same name/existence in the project.

Regarding the workset issue I wrote three posts about previously, they describe how families can get renamed when worksets are being used and more than one person loads the same families and synchronizes their work in a specific way. The posts are:

FIRST post
SECOND post
THIRD post (references the first two as well)

Thursday, May 19, 2016

Tags Dimensions and Linked Files

I've mentioned this subject in the past. I'm writing to bring it up again and to focus on how Revit deals with tags and dimensions differently when we apply them to elements that are in linked files.

First as a reminder, when a linked file changes and a user reloads that link in their Local File other users are not necessarily seeing the same version of the Linked File. That's because reloading a link is a local change, a personal action, that doesn't get passed along to the Central File when we use Synchronize with Central (SwC).

Let's imagine User A has reloaded a linked model and they've placed tags on doors and rooms that they observe are now present in the link. User A uses SwC to share this new tagging effort. Now User B, who already has a Local File open, decides to use Reload Latest or SwC to share something they've done or see what work other users have contributed.

It's important to note that User B did NOT use Reload in Manage Links or via right-click on the linked file in the Project Browser FIRST. As a result User B gets the warning in the next image. Don't be confused by the mention of Coordination Monitor which can be confusing. It can make us think we're dealing with something that has been involved with the Copy/Monitor tools.


The Tags are Orphaned, they've lost their relationship with the linked file's elements they are supposed to identify. You can see one tag is highlighted in orange in the image above. In the next image we can see what the floor plan really looks like in the linked file (and what User A sees). It's not quite the same as what User B thinks it looks like is it?


Let's now imagine that User A continues to work by adding the dimensions you see in the image above too. After they finish doing that they use SwC.

User B now decides to use SwC or Reload Latest, AGAIN without using Reload on the linked file. Their reward is a larger collection of warnings (see next image). The first three warnings are dedicated to the dimensions User A added to their Local File. There are no equivalent elements in the version of the linked file that User B sees so Revit's only recourse is to delete them ... or ... choose Cancel ... which is actually a better choice. If User B cancels and then Reloads the linked file first that will eliminate the warnings entirely.


The remaining warnings are focused on the newly orphaned door and room tags that can't find their parent elements. If we select one of the orphaned tags we can either use Pick New Host or Reconcile Hosting. The former will need us to pick a door to associate the tag with. The latter will open the Reconcile Hosting browser which shows us everything that has been orphaned so far. We can select individual items and right-click to use Pick Host or Delete the tag if that's a better choice.


Keep in mind, once this orphaned status occurs it sticks. Merely reloading a linked file afterward isn't going to fix it. We'll be forced to deal with Reconciling Hosting. In some situations it might be faster to delete the tags and use Tag All to place them all over again.
This might be an opportunity for an enterprising developer to write a routine that looks at orphaned families and picks the closest possible host? Better still...Autodesk?
My recommendation, if you MUST use tags and dimensions on linked files?

Develop the habit of reloading the necessary linked files BEFORE using SwC or Reload Latest.

If you get the warning messages in the images above, use CANCEL. Make a note of the elements the warning(s) is(are) focused on. Most likely the warnings are being issued because you need to use Reload on the linked files first.

I'd also consider a moratorium on applying tags or dimensions to linked elements while the link is being changed aggressively. For example, if we know that the link is going to undergo some massive redesign we should just agree to stay away from tags and dimensions until it settles down again.

It's also a good idea to let other people know that you have changed an integral linked file so they can all use Reload (link) to catch up together.

Friday, May 06, 2016

Create a Local File - How Often

Every time...

I no longer reuse Local Files. My attitude and habits have changed a little over the years. I wrote this POST in 2008 and then THIS on in 2011. I've touched on the subject many times within the context of other workset related posts.

I treat my Local File as ephemeral...temporary... I make use of the Open File option Create New Local each and every time I start working on a project again; yes even if I just stopped working earlier to have lunch or join a conference call.

Thursday, April 21, 2016

Revit 2017 - Enabling Worksharing

The process for enabling worksets has changed with this release because Collaboration for Revit (C4R) has been incorporated into Revit directly. This allows someone to subscribe and begin using it quicker. They might even be able to do so without any (or much) EyeTee intervention.

The first evidence that there is something different is on the Collaborate ribbon tab; there is a Collaborate button next to the disabled Worksets button. There is a new Communicate panel too.


In the past enabling worksets began with clicking on the Worksets button but now we start by clicking on Collaborate. This takes us to the fork in the road necessary to permit sharing the project via A360/C4R whether we are able to use it or not, just in case. If the file hasn't been saved before clicking Collaborate we get a message asking us to do that.


Then the Collaborate dialog appears asking us to specify which method of sharing the project we need; Collaborate within your network or Collaborate using A360.


When we choose Collaborate within your network Revit enables and creates two User-Created Worksets called Shared Levels and Grids and Workset1 (like in the past) but it doesn't open the Worksets dialog (like it used to). This allows us just to get on with our work using the Active Workset (Workset1 by default). If we need to create additional worksets then we'll find the Workset button is enabled, just click it to open it (Workset dialog, as in the past.

The Communicator button is tied to using C4R. It is a separate window (dialog) that can display information about your project team activity, if you're sharing the project using A360. Imagine concepts from Worksharing Monitor combined with Instant Messaging features and that's what you've got. FWIW, it used to be able to dock inside the Revit UI but it doesn't do that now. If you've got two or more monitors you'll probably prefer it on one of them instead anyway. This is what it looks like if I'm not logged into A360 and not using it to share this project.


At some point we'll need to Save the file and like in the past we'll be warned that this is the first time we've done that since we enabled worksets; click Yes.


Remember, if you'd like to set the default Open option to Specify remember to use Save As instead of Save. You only get a chance to do that with Save As. This allows us to choose which Worksets Revit should load before it opens the project entirely. This can have a significant impact on how long it takes to load a project.


At this point we are still working in the Central File, which isn't practical to share the project nor is it advisable. I can determine that by looking at the Save icon on the Quick Access Toolbar (QAT), it is disabled and the Synchronize and Modify Settings button next to it is enabled. The project's file name listed on the Title Bar doesn't include my user name either. By the way, we need to SwC to relinquish our ownership of the User-Created worksets properly. The only way to do that is to use SwC (Synchronize and Modify Settings), via the dialog that appears. The Synchronize Now button does NOT do that.


Now that worksets are enabled and relinquished we need to close the project so the team can get started by creating their Local Files. When I browse to the Central File to start work I need to make sure that Create New Local is enabled and double check the Open option is assigned to Specify.


Remember doing so will cause this dialog to appear before Revit begins opening the project further.


Okay, now get to work; in your Local File!

Monday, April 06, 2015

Survey Point - Post 3 - Five Minutes with Shared Coordinates

I created a video that goes through the process I described in the previous two posts. It is set to a four and half minute song by Michael Lee Firkins called "The Window". If you've never heard his music I believe you owe it to yourself to check him out, very talented and unique sounding guitarist and song writer.

Survey Point
Survey Point - Post 2


Tuesday, March 31, 2015

Detach from Central versus Save As - Make this a Central Model after Save

Both techniques allow us to create a new central file from an existing file that has enabled worksets already.

Save As - Make this a Central Model after Save - respects the Edited By information the project has stored. This means if other users have borrowed elements then you'll find those users among the Owner/Borrower column in the Worksets dialog after creating your new central file.


This distinction means it may be possible (though unlikley) to allow users to synchronize their work with the new central file. They'd have to use the Browse button in the Synchronize with Central dialog to point Revit to the new location of the central. I used italics on may be possible because there are so many variables that could prevent it from succeeding that I don't want to provide false hope. If people have not continued to alter or create new elements in their own local files, while this new central file is created, then it may be possible, worth attempting perhaps if you are in some sort of recovery mode.

Detach from Central - completely severs the relationship the file had with the file it came from (usually a central file) and any local files that may exist, as well as ALL ownership information (stored in Edited by parameter). It is a fresh start, utterly.

Btw, this post was prompted by a question at RFO this afternoon. It became evident that this subtlety is something I've not written about, I thought I had.

Monday, March 19, 2012

Working from Home

This question comes up all the time during training sessions. Some firms cut it off at the knees, "No work at home, sorry". They don't allow employees to take work (at least computer files and such) home at all. You still take your brain with you (hopefully) so it's not like you can't be thinking your way through a problem eh? You'll just have to commit it to digital in the office.

First question I ask, "Is anybody else involved?" Usually the answer is, "Yeah, probably, maybe..?"

There are a couple solo options, meaning if you go home and want to work AND there are other people involved you can't leave until they ALL finish and you have to be the first one back in the office in the morning. Everybody else needs to be aware you intend to work on the project this way.

If more than one of you want to do this on the same evening...skip to the end for the Remote Desktop option.

Brute Force Technique (aka - "It's my world, you're just living in it")

Heading Home
Copy the file and any necessary linked models and go home
Open the project file using Detach from Central
Save the file using a new name
Fix any broken links
Work till you drop - copy the file(s) to flash drive

Heading to Work
Copy the file to your flash drive
At the office open the project file using Detach from Central
Save the file using the original central file name
Fix any broken links
Work till you drop and go home

Keep in mind that if anyone else does this too, on the same evening, the first one that gets into the office and creates the new central file wins, the other loses. You'll be stuck trying to copy/paste your changes into the project.

Slightly Less Brute Force Technique
You can also do essentially the same thing with your local file if you wait until everyone else uses SwC and leaves.
In your local file open the Workset dialog
Check all the workset types so they are all listed above
Select them all and make them editable
You'll own all the worksets which means nobody will be able to do anything until you return. (This means you can just take your local file home and work "at risk" because the central file can't be found but nobody else can borrow a workset anyway, you've got them all.)
Return to the office in the morning
Put your local back in place
Use SwC to relinquish all the worksets and update the central file.

Same warning stands, only one of you can do this and get back to the office and succeed with SwC, the second place user will get a unhappy message that Revit can't reconcile changes.

The Multi-User from Home Scenario
The better way to do this is to use Remote Desktop and leave your office computer on when you leave. Use Remote Desktop to run Revit on your office computer from your home computer. This lets you leave everything at the office except for you. Performance may vary but it is usually workable if you have a wired connection to the internet. It really depends on how your house and office are connected to the internet but only keyboard and mouse clicks are passed back and forth along with screen data.

Remote desktop (or something similar- computer access/sharing tool) takes a bit more EyeTee savvy...

Friday, March 02, 2012

Design Review

I'm writing about both the process and the software. Autodesk has been shipping Design Review along with the rest of its products for many years now (though its name has varied some). Ask the average AutoCAD user or Revit user if they know what it is or if they've used it and the answer all too often is, "What's that?" This is the PC version's icon.


There is an iPad compatible version of Design Review too. Here's the sample house project file open on my iPad.


Awareness is one hurdle, not insurmountable, perhaps easier to resolve than a couple others, willingness to use it and the practical issues of reviewing full size paper versus on screen review. Obviously there is some reluctance to review drawings on screen, on the computer. It isn't limited to so-called Luddites who don't like computers either. I've encountered drawings coming off the plotter only to see some obvious typo or other problem that we clearly missed on screen for days, weeks or even months. The size of the typical monitor makes it hard to compete with a full size print in hand. Even with very large screens there is some perception of not seeing everything.

The Document review process with design review looks roughly like this:
  • Revit team exports sheets to DWF
  • Open each sheet DWF file in DR
  • Add markups and comments
  • Save the file
  • Revit team imports sheet markup files
  • Deal with markups and comments
  • Add responses if necessary
  • Save their work in Revit which updates the DWF file too.
  • Reviewer can open the DWF and see the action taken on their markups and comments.
The document reviewer can open the DWF sheet files and check progress on picking up changes.
The DWF files just need to stay in the same folder while the team is resolving the markups.
Once the markups are all resolved the links can be removed and the files archived and the process can repeat for the next review cycle.

To make the review process easier and more like paper we really need to use the largest screen that we can manage. I'd love to see something like the screens they show off in the renewed Hawaii Five-0! If you'd like to make something like that a reality in your office have a look at PEAU Productions (thanks to Scott at Clark Construction for the link). Check out this VIDEO from their You Tube postings. Based on what I've seen on the site you can have a pretty darn big multi-touch experience for under $2K.


While I'm encouraging you/us to reconsider how we go about reviewing projects and documents, I do have to temper this post a bit, the process isn't perfect. But then again what process is?

It is necessary to avoid opening and/or editing DWF files while they are linked into Revit for responding to the markups. We are supposed to be able to check on progress but in practice we often run into permission issues between Design Review and Revit's work sharing process.

Coincidentally, as I was working on this post I saw that David Baldacchino wrote a post yesterday that describes some flaws and frustrations that you may encounter if you choose to give this process a shot. I wish his comments weren't valid. I suspect if we saw more active use of Design Review we'd see greater emphasis placed on streamlining the workflow more.

You might also consider Bluebeam PDF Revu CAD as a more robust plot/markup/review tool. It (Bluebeam) does not permit the linking into Revit that Design Review does so that relationship is still stronger even if a bit quirky.

I encourage us to all move closer to the data, as close as possible to minimize the chance or missing things as well as reducing inefficiency. For people comfortable with Revit much can be done directly in the software to manage this. For those that are not, then Design Review offers a path than can help keep it digital and more closely connected to the model and data.

Saturday, September 12, 2009

Project Submittals - Do You Require 3D Submittals Now?

With all the hoopla about BIM and IPD one thing I have not heard much about (actually I can't recall anyone discussing this within earshot) is the submittal process. I get the feeling that for most it is still business as usual; catalog cuts, 2D drawings and "can we get an approved or reviewed stamp ASAP?".

Seems to me that it is a natural expectation, or logical next step, that we start requiring 3D submissions from our project's array of contractors. I alluded to the importance of doing so in an earlier post when I mentioned the serious coordination issues associated with theater/stage construction. We were just using AutoCAD and not even modelling solid parts back then. We looked at Pro/E and were put off by the specialized hardware and the shockingly high seat price (shocked us anyway).


I remember clearly asking how I would use Pro/E to create our submittal drawings, which depict how our equipment would work in the building. I was amused when the reply was, "I supposed you'd model the parts of the building you are touching." This was in 1996-7, just when Revit was a mere flash in the minds of Leonid and Irwin. Seems logical now but then it was practically laughable that I'd model the building to virtually install our equipment. If the building was already a model...hmmm, different story or reaction perhaps? A few years later, after I'd left to join an architecture firm, they started to use Autodesk Inventor after dabbling with Mechanical Desktop.

I just mocked up the images posted here in less than 20 minutes, 5 for the rigging component, using a dwg file I downloaded from their site as a guide for the form. Then a few minutes to layout the building form and structure and finally the rest fussing with views.

What are you doing?