Ever see this message?
There are a number of reasons why it occurs. This is one example that can occur when swapping families. Not all families are created equal. Shocker I know...sorry. When you swap one family for another after applying dimensions you run the risk of confusing the dimensions. Let's take this simple family, GM01.rfa.
The Right and Left reference planes have corresponding names and IsReference settings. Now lets look at GM02.rfa
In this family I've made a mistake (on purpose of course), the Right reference plane has a different IsReference setting, it is set to Weak Reference. Technically the family is also a little bit wider than GM01, but that won't matter. If I've added dimensions that reference this family, as soon as I try to swap GM01 for GM02 I get the message I mentioned at the beginning.
The essence of the warning is that something has changed in a way that Revit can't transfer the dimension reference to the new object. The tricky part is figuring out what that "something" is. Sometimes it is how the family is made.
[Edit: Btw, I wrote, and scheduled this to post ahead of time, in response to an question via email and a last night I read a post at RevitForum.org that asks why almost the same thing is happening. Serendipity.]
Friday, September 14, 2012
Thursday, September 13, 2012
Working in the Central File
We are supposed to work in local files. Occasionally people will fire up Revit and end up working in the central file instead. These days it is more deliberate because they have to un-check the Create New Local option to do so.
Revit has been tweaked over the years to deal with central file editing. I've read claims in a couple books recently that working in a central file prevents other users from using Synchronize with Central (SwC). It isn't true in my experience. If I'm working in a local file I can use SwC as much as I need. The person working in the central file on the other hand will be forced to create a local file when they try to use SwC. They'll get this message.
I can work in a central file as long as necessary, as long as nobody else is working on the project in local files too. Isolation is fine, collaboration is where the conflict arises. We encounter the message above when a change has been made via a local file while the central file is being edited. While someone is editing the central file a local file user has been able to add or alter an element and then use SwC. When the local file user completes a SwC and the person working in the central file attempts to use SwC the central file editor will get this message (remember Save is disabled in a Central File).
The message also explains how to resolve the situation, just Save As to save the file with another name, which turns it into a local file. Now SwC will work.
There are some legitimate reasons to work in the central file, just do it in isolation.
Revit has been tweaked over the years to deal with central file editing. I've read claims in a couple books recently that working in a central file prevents other users from using Synchronize with Central (SwC). It isn't true in my experience. If I'm working in a local file I can use SwC as much as I need. The person working in the central file on the other hand will be forced to create a local file when they try to use SwC. They'll get this message.
I can work in a central file as long as necessary, as long as nobody else is working on the project in local files too. Isolation is fine, collaboration is where the conflict arises. We encounter the message above when a change has been made via a local file while the central file is being edited. While someone is editing the central file a local file user has been able to add or alter an element and then use SwC. When the local file user completes a SwC and the person working in the central file attempts to use SwC the central file editor will get this message (remember Save is disabled in a Central File).
The message also explains how to resolve the situation, just Save As to save the file with another name, which turns it into a local file. Now SwC will work.
There are some legitimate reasons to work in the central file, just do it in isolation.
Wednesday, September 12, 2012
View Discipline
Daryl wrote on Monday that the concept of View Discipline isn't documented well. Software documentation tends to be a bit dry, too often a very literal, "Un-checking this turns the feature off". Well that is obvious but "why" would I want to turn it on or off? Unless it is truly self evident, why a feature exists is a bit more involved but much more satisfying help.
The concept of View Discipline appeared with Revit Structure. It was meant to make it simple to alter the appearance of our model to be more in sync with what a structural engineer wants to see. When MEP (Systems as it was called then) appeared a year later they extended the concept to Mechanical and Electrical (plumbing lumped in with Mechanical till release 2013).
Daryl used plan views as his example of how the help documentation isn't accurate. Plan views are not the best view type to see the truth in the help claims. Ducts for example, he wrote, don't show up when the architectural discipline is chosen. They CAN show up, they probably won't be visible because they are above the cut plane. When Mechanical is assigned Revit changes the nature of what plan and reflected plan mean. Ducts at 10'-0" AFF will appear in a plan view with the view discipline Mechanical assigned. They won't with Architecture. They are there, just above the view.
This subtle change occurs because the notion of a plan and reflected plan view means slightly different things to architects and engineers. A reflected plan, architecturally, means that elements that are lower mask elements that are higher, such as a ceiling and light fixtures mask elements above that ceiling. A HVAC plan is different because most engineers want to see the highest duct masking lower ducts. It isn't a reflected plan, it is a plan whose cut plane is, in a way, altered to be above the highest elements and "look down".
Technically the view range settings can be identical but switching to mechanical discipline will show ducts that weren't there a moment ago when architectural was assigned. They were there but the discipline change altered how Revit calculates the display of the elements. Engineers don't generally do reflected plans so Revit made it easier to generate regular floor plans that show their elements in a way they expect to see them.
The combination of View Discipline, Object Styles, Visibility/Graphics Overrides and View Range are all responsible for what we see in a given view (technically there are more). Changing one of them is not going to ensure that we see what we really want. We've got to make sure they all have complimentary settings. There is no real difference between Mechanical and Electrical disciplines graphically, based solely on the View Discipline parameter changing. The views dedicated to each of those disciplines also use V/G and possibly view range settings to make them look correct. If you examine the stock templates you'll find that these views have each others element categories turned off (with V/G) to achieve the look we are after. Apart from the automatic graphically biased changes they make, they really just help us segregate views in the project browser.
In my own way:
Architectural - All model elements treated "equally", according to Object Styles, but with architectural bias with respect to view range and cutting elements.
Structural - Similar to architecture but hides non-load bearing walls and some hidden line behavior with respect to concrete floors/slabs and foundations.
Mechanical - All other disciplines are half-tone and transparent (help says "on top"), duct and pipe and related element categories take priority and behave according to Object Styles. Mechanical elements like duct and pipe will appear in plan regardless of their true elevation with respect to view range, as long as they are within the Primary Range.
Electrical - Same as Mechanical.
Plumbing - (new to 2013) Same as mechanical.
Coordination - Same as Architectural but provides for segregation from it for easier management of views.
Then there is the Sub-Discipline parameter, a Project Parameter that first showed up in Revit MEP templates. I see architecture firms, that have been exposed to RME, using the same parameter now in their architecture templates because of the added (for consistency as well) control over the Project Browser sorting. That's the essence of the parameter's existence, to manage the Project Browser according to the kinds of views each discipline typically creates. Such as Power and Lighting plans for electrical and HVAC Duct vs HVAC Piping.
Keep in mind that views in stock project templates are also configured to only show certain element categories according to the discipline bias implied by their name and discipline parameter setting. The combination of the View Discipline parameter and Visibility/Graphic Overrides is responsible (among other possible view properties) for the final result of what you see in a view.
The concept of View Discipline appeared with Revit Structure. It was meant to make it simple to alter the appearance of our model to be more in sync with what a structural engineer wants to see. When MEP (Systems as it was called then) appeared a year later they extended the concept to Mechanical and Electrical (plumbing lumped in with Mechanical till release 2013).
Daryl used plan views as his example of how the help documentation isn't accurate. Plan views are not the best view type to see the truth in the help claims. Ducts for example, he wrote, don't show up when the architectural discipline is chosen. They CAN show up, they probably won't be visible because they are above the cut plane. When Mechanical is assigned Revit changes the nature of what plan and reflected plan mean. Ducts at 10'-0" AFF will appear in a plan view with the view discipline Mechanical assigned. They won't with Architecture. They are there, just above the view.
This subtle change occurs because the notion of a plan and reflected plan view means slightly different things to architects and engineers. A reflected plan, architecturally, means that elements that are lower mask elements that are higher, such as a ceiling and light fixtures mask elements above that ceiling. A HVAC plan is different because most engineers want to see the highest duct masking lower ducts. It isn't a reflected plan, it is a plan whose cut plane is, in a way, altered to be above the highest elements and "look down".
Technically the view range settings can be identical but switching to mechanical discipline will show ducts that weren't there a moment ago when architectural was assigned. They were there but the discipline change altered how Revit calculates the display of the elements. Engineers don't generally do reflected plans so Revit made it easier to generate regular floor plans that show their elements in a way they expect to see them.
The combination of View Discipline, Object Styles, Visibility/Graphics Overrides and View Range are all responsible for what we see in a given view (technically there are more). Changing one of them is not going to ensure that we see what we really want. We've got to make sure they all have complimentary settings. There is no real difference between Mechanical and Electrical disciplines graphically, based solely on the View Discipline parameter changing. The views dedicated to each of those disciplines also use V/G and possibly view range settings to make them look correct. If you examine the stock templates you'll find that these views have each others element categories turned off (with V/G) to achieve the look we are after. Apart from the automatic graphically biased changes they make, they really just help us segregate views in the project browser.
In my own way:
Architectural - All model elements treated "equally", according to Object Styles, but with architectural bias with respect to view range and cutting elements.
Structural - Similar to architecture but hides non-load bearing walls and some hidden line behavior with respect to concrete floors/slabs and foundations.
Mechanical - All other disciplines are half-tone and transparent (help says "on top"), duct and pipe and related element categories take priority and behave according to Object Styles. Mechanical elements like duct and pipe will appear in plan regardless of their true elevation with respect to view range, as long as they are within the Primary Range.
Electrical - Same as Mechanical.
Plumbing - (new to 2013) Same as mechanical.
Coordination - Same as Architectural but provides for segregation from it for easier management of views.
Then there is the Sub-Discipline parameter, a Project Parameter that first showed up in Revit MEP templates. I see architecture firms, that have been exposed to RME, using the same parameter now in their architecture templates because of the added (for consistency as well) control over the Project Browser sorting. That's the essence of the parameter's existence, to manage the Project Browser according to the kinds of views each discipline typically creates. Such as Power and Lighting plans for electrical and HVAC Duct vs HVAC Piping.
Keep in mind that views in stock project templates are also configured to only show certain element categories according to the discipline bias implied by their name and discipline parameter setting. The combination of the View Discipline parameter and Visibility/Graphic Overrides is responsible (among other possible view properties) for the final result of what you see in a view.
Tuesday, September 11, 2012
Shared Parameters aka Dictionary
A Shared Parameter is like a definition and the Shared Parameter file is like a dictionary.
Consider that a family parameter is confined to a family. It can be seen from within a project but not scheduled or tagged unless it is a built in parameter like those listed under the Identity group (and provided for us by Autodesk).
Consider that a Project Parameter is part of a project and applied to categories of families so that it can be scheduled, but NOT tagged. Like a Family parameter it is "trapped" there, in the project.
A shared parameter bridges both trapped conditions, acting as a definition we look up in a dictionary (the shared parameter file). We store our common definitions there so they can be applied in other projects or families. When you create a family or project parameter using a shared parameter (definition from the dictionary) it is really just another parameter but it has expanded possibilities because it is "shared", the data stored with it can be scheduled AND tagged.
Consider that a family parameter is confined to a family. It can be seen from within a project but not scheduled or tagged unless it is a built in parameter like those listed under the Identity group (and provided for us by Autodesk).
Consider that a Project Parameter is part of a project and applied to categories of families so that it can be scheduled, but NOT tagged. Like a Family parameter it is "trapped" there, in the project.
A shared parameter bridges both trapped conditions, acting as a definition we look up in a dictionary (the shared parameter file). We store our common definitions there so they can be applied in other projects or families. When you create a family or project parameter using a shared parameter (definition from the dictionary) it is really just another parameter but it has expanded possibilities because it is "shared", the data stored with it can be scheduled AND tagged.
Monday, September 10, 2012
RTC Session Datasets for Shared Coordinates
To the people that attended my session at both RTC events.
I apologize for being slack!
It's been months now since Wollongong (May) and only one less since Stone Mountain (June). I'm apologizing because until tonight attendees couldn't actually get the data set files I promised. I've let this issue slip and slide underneath everything else going on and that's not fair. I did try several different times to upload the data but between spotty connections at hotels, the distance and the size of the dataset the upload kept failing. So finally last night we got past that with Bo's help at the BD Group/RTC Events office...thanks Bo!
Thanks for being patient, even if you gave up on me ;)
Session Title: Coordinating Projects with Shared Coordinates
Session in Wollongong, to login for the Materials: CLICK HERE
Session in Stone Mountain, to login for the Materials: CLICK HERE
You'll need to refer to the email you received that provided the login password for the conference you attended.
The only difference between the files offered? There is one project file with "slides" for each location of the conference. The Large and Small project folders contain the same collection regardless of where you attended the session.
I apologize for being slack!
It's been months now since Wollongong (May) and only one less since Stone Mountain (June). I'm apologizing because until tonight attendees couldn't actually get the data set files I promised. I've let this issue slip and slide underneath everything else going on and that's not fair. I did try several different times to upload the data but between spotty connections at hotels, the distance and the size of the dataset the upload kept failing. So finally last night we got past that with Bo's help at the BD Group/RTC Events office...thanks Bo!
Thanks for being patient, even if you gave up on me ;)
Session Title: Coordinating Projects with Shared Coordinates
Session in Wollongong, to login for the Materials: CLICK HERE
Session in Stone Mountain, to login for the Materials: CLICK HERE
You'll need to refer to the email you received that provided the login password for the conference you attended.
The only difference between the files offered? There is one project file with "slides" for each location of the conference. The Large and Small project folders contain the same collection regardless of where you attended the session.
Parameter Related Post Summary
Updated August 1, 2013
Posts from 2005
(2005) What are parameters and why should I care?
(2005) Sharing Parameters - An Overview
(2005) Shared Parameters - Part 3
(2005) Shared Parameters - Part 4
(2005) Making a Shared Parameter File
(2005) When is an Instance really a Type?
(2005) Ignore Good Advice
Posts from 2006-2008
(2006) Walking on Thin Ice
(2007) Family Editor - Parameter Order
(2008) Duct Size Parameter - Inches - Revit MEP
(2008) Dept. of Subtle - Filter Parameter in Tags (really subtle)
(2008) Shared Parameter File - A Little Clarification
(2008) Shared Parameter - No you Can't -Yes you Can
Posts from 2009
(2009) The Order of Parameters - Revisited
(2009) Titleblock Parameters
(2009) Which Group? Choosing a Parameter's Parameter
(2009) Revit Family Style Guide
(2009) Titleblock Parameters
(2009) Dept. of Subtle - Family Editor Parameter and Formula
(2009) Back to Basics: Mark and Type Mark
(2009) Dept. of Subtle - Three Parameter Tips?
(2009) Revit API SDK - AutoParameter
Posts from 2010
(2010) Export a Shared Parameter
(2010) BIM Family Toolkit at Autodesk Labs
(2010) Dept. of Subtle - Parameter Shuffling
(2010) Family Editor - Use a Default Type
(2010) Dept. of Subtle - Omni Class Parameters Missing
Posts from 2011
(2011) Parameters Again
(2011) Parameters Again
(2011) Dept. of Subtle - Family Editor Parameter Lock
(2011) Dept. of Echo - Type Catalog Formatting
(2011) Dept. of Echo - Shared Parameters for Manufacturer
(2011) Family Type Parameter Gotcha
(2011) Revit Content Standards - ANZRS
(2011) Dept. of Subtle - Connectors and Diameter
(2011) No Math Characters in Parameter Names
(2011) Family Category and Parameter Dialog
(2011) Shared Parameter Utility - Revit SP Writer
Posts from 2012
(2012) Connecting Parameters
(2012) Connecting Parameters in Nested Families
(2012) Pushing Parameters Around
(2012) Parameter Grouping
(2012) Shared Parameter Article at AEC Bytes
(2012) The Shared Parameter File has no Relationships
(2012) A Small Collection of Family Editor Advice
(2012) Parameter Pecking Order or Priority
(2012) Shared Parameter Czar
(2012) Which Overwrite is Right
(2012) Shared Parameters aka Dictionary
Posts from 2013
(2013) Working with Type Catalogs
(2013) Associate Family Parameter
Posts from 2005
(2005) What are parameters and why should I care?
(2005) Sharing Parameters - An Overview
(2005) Shared Parameters - Part 3
(2005) Shared Parameters - Part 4
(2005) Making a Shared Parameter File
(2005) When is an Instance really a Type?
(2005) Ignore Good Advice
Posts from 2006-2008
(2006) Walking on Thin Ice
(2007) Family Editor - Parameter Order
(2008) Duct Size Parameter - Inches - Revit MEP
(2008) Dept. of Subtle - Filter Parameter in Tags (really subtle)
(2008) Shared Parameter File - A Little Clarification
(2008) Shared Parameter - No you Can't -Yes you Can
Posts from 2009
(2009) The Order of Parameters - Revisited
(2009) Titleblock Parameters
(2009) Which Group? Choosing a Parameter's Parameter
(2009) Revit Family Style Guide
(2009) Titleblock Parameters
(2009) Dept. of Subtle - Family Editor Parameter and Formula
(2009) Back to Basics: Mark and Type Mark
(2009) Dept. of Subtle - Three Parameter Tips?
(2009) Revit API SDK - AutoParameter
Posts from 2010
(2010) Export a Shared Parameter
(2010) BIM Family Toolkit at Autodesk Labs
(2010) Dept. of Subtle - Parameter Shuffling
(2010) Family Editor - Use a Default Type
(2010) Dept. of Subtle - Omni Class Parameters Missing
Posts from 2011
(2011) Parameters Again
(2011) Parameters Again
(2011) Dept. of Subtle - Family Editor Parameter Lock
(2011) Dept. of Echo - Type Catalog Formatting
(2011) Dept. of Echo - Shared Parameters for Manufacturer
(2011) Family Type Parameter Gotcha
(2011) Revit Content Standards - ANZRS
(2011) Dept. of Subtle - Connectors and Diameter
(2011) No Math Characters in Parameter Names
(2011) Family Category and Parameter Dialog
(2011) Shared Parameter Utility - Revit SP Writer
Posts from 2012
(2012) Connecting Parameters
(2012) Connecting Parameters in Nested Families
(2012) Pushing Parameters Around
(2012) Parameter Grouping
(2012) Shared Parameter Article at AEC Bytes
(2012) The Shared Parameter File has no Relationships
(2012) A Small Collection of Family Editor Advice
(2012) Parameter Pecking Order or Priority
(2012) Shared Parameter Czar
(2012) Which Overwrite is Right
(2012) Shared Parameters aka Dictionary
Posts from 2013
(2013) Working with Type Catalogs
(2013) Associate Family Parameter
Sunday, September 9, 2012
RTC AUS 2013 - Seeking Abstracts
Just to further getting the word out the Revit Technology Conference 2013 - Australasia is now accepting abstracts until Wednesday October 31, 2012. CLICK HERE to Submit.
The abstracts requested, at this time, are ONLY for the conference in Auckland, New Zealand this year, May 16-18, 2013. Separate requests will go out for the other two conferences a little later this year.
If you want to keep track of RTC information you have options; Naturally the main RTC Site, and I have a page on this site dedicated to RTC, You can follow RTC on Twitter RTCNA - RTCAUS - RTCEUR and RTC on Facebook as well as the RTC Blog and Linked in and Instagram. We're working on a single You Tube channel.
Have a couple minutes? Considering attending RTC in 2013, then check out this video (00:01:44) to see what RTC is all about. It was created with footage taken from the event in June (Stone Mountain, GA).
The abstracts requested, at this time, are ONLY for the conference in Auckland, New Zealand this year, May 16-18, 2013. Separate requests will go out for the other two conferences a little later this year.
If you want to keep track of RTC information you have options; Naturally the main RTC Site, and I have a page on this site dedicated to RTC, You can follow RTC on Twitter RTCNA - RTCAUS - RTCEUR and RTC on Facebook as well as the RTC Blog and Linked in and Instagram. We're working on a single You Tube channel.
Have a couple minutes? Considering attending RTC in 2013, then check out this video (00:01:44) to see what RTC is all about. It was created with footage taken from the event in June (Stone Mountain, GA).
Subscribe to:
Posts (Atom)






