It's a teaser blog title. I have no idea what is in Revit 2019, or rather until I read THIS POST.
I'm looking forward to exploring the new features myself once I actually have time to download it.
As for not knowing what was coming like in the past. My access to their review program was screwed up last spring/summer and I haven't been able to log into the site ever since. I had someone looking in to it but their tech support efforts...well suffice it to write I haven't been able to log in. Bummer...
I hope you, dear reader, enjoy the new features in Revit 2019. I, like many of you, will get to experience them with fresh eyes!
Oh, Revit 2018.3 was released the other day too so look out for that update. As always, go slow with installation and rolling it out...make sure your existing projects are in a position to tolerate the potential for some issues before upgrading any projects. I wish you pleasant upgrades.
Double oh, a little birdie told me Paul Aubin and Bill Debevc (okay Bill told me) are going to do a podcast on the new features. Also Paul has a Lynda video on the new features.
Wednesday, April 11, 2018
Tuesday, February 20, 2018
Copy Monitor - A Different Way?
Morning musing...
It's my observation that there is a prevailing mostly ambivalent attitude toward the Copy/Monitor (C/M) features. I've said before that I think the order of the tabs in the Options dialog are based on the likelihood that we'll use them. Specifically they are listed left to right: Levels, Grids, Columns, Walls and Floors.
C/M isn't hard to use but once it is in play we've got some new rules and warnings to contend with. The process depends on us identifying the elements we want to live in the C/M system. I understand the logic of that choice. Revit asks us to tell it what is important enough to us to engage the system.
Perhaps we need a completely different way to attack the problem? One that doesn't require the advance work. One that is more a reaction to work as it is created and shared, that merely exists.
I wonder if it would be more betterer if we could run a Level or Grid check as a process. The application would compare elements and compile a report, observations and differences. It could be something we read afterward or presented in a dialog for immediate action.
For example, it could just start with: "Hey Steve, there are 27 grids in your model and 30 in theirs. You should look at them." Take it slightly deeper, "Hey Steve, there are three grids that share the same name but are not in the same location."
Does it matter that they used to be in the same location and they aren't now? The application would have to start storing records for past results to do that but it could be useful to determine when or how things got off track. The rules or conditions that are interesting need to be defined.
This sort of element review and comparison doesn't have to be limited to the five that Copy/Monitor were designed for originally (overlooking the MEP elements that have been added in some fashion). It still requires two or more elements though; mine, yours and theirs. The redundancy is annoying but it does provide us with flexibility within our own models.
I imagine much of what I'm describing (and more) is possible via the API and Dynamo. It just needs someone to decide it is an interesting enough thing to do.
It's my observation that there is a prevailing mostly ambivalent attitude toward the Copy/Monitor (C/M) features. I've said before that I think the order of the tabs in the Options dialog are based on the likelihood that we'll use them. Specifically they are listed left to right: Levels, Grids, Columns, Walls and Floors.
C/M isn't hard to use but once it is in play we've got some new rules and warnings to contend with. The process depends on us identifying the elements we want to live in the C/M system. I understand the logic of that choice. Revit asks us to tell it what is important enough to us to engage the system.
Perhaps we need a completely different way to attack the problem? One that doesn't require the advance work. One that is more a reaction to work as it is created and shared, that merely exists.
I wonder if it would be more betterer if we could run a Level or Grid check as a process. The application would compare elements and compile a report, observations and differences. It could be something we read afterward or presented in a dialog for immediate action.
For example, it could just start with: "Hey Steve, there are 27 grids in your model and 30 in theirs. You should look at them." Take it slightly deeper, "Hey Steve, there are three grids that share the same name but are not in the same location."
Does it matter that they used to be in the same location and they aren't now? The application would have to start storing records for past results to do that but it could be useful to determine when or how things got off track. The rules or conditions that are interesting need to be defined.
This sort of element review and comparison doesn't have to be limited to the five that Copy/Monitor were designed for originally (overlooking the MEP elements that have been added in some fashion). It still requires two or more elements though; mine, yours and theirs. The redundancy is annoying but it does provide us with flexibility within our own models.
I imagine much of what I'm describing (and more) is possible via the API and Dynamo. It just needs someone to decide it is an interesting enough thing to do.
Wednesday, January 17, 2018
Five Minutes with Shape Editing a Bay Roof
I posted this screencast in response to a thread at the Autodesk Forums. Figured I might as well share it here too. I used shape editing to create the bay roof condition shown in this image.
It's based on an image of a DWG roof plan that was shared in the original post in the discussion. The sketches of the main and bay roofs look like the following image. It also shows the sketched Split Line elements I added to make raising the bay ridge up easy.
Here's the screencast I created to post at the forums.
FWIW, I made the main roof partially transparent so I could see the walls more easily. In the video I commented about using the Two Cut Plumb setting with a 12" value. The Shape Editing disables that for the bay roof but it did start out with that setting in play so it all worked out as I intended even though I was confused about it at the time.
It's based on an image of a DWG roof plan that was shared in the original post in the discussion. The sketches of the main and bay roofs look like the following image. It also shows the sketched Split Line elements I added to make raising the bay ridge up easy.
Here's the screencast I created to post at the forums.
FWIW, I made the main roof partially transparent so I could see the walls more easily. In the video I commented about using the Two Cut Plumb setting with a 12" value. The Shape Editing disables that for the bay roof but it did start out with that setting in play so it all worked out as I intended even though I was confused about it at the time.
Thursday, December 21, 2017
Sketching Tangent Lines
A post based on my responses at the Autodesk Forum: Tangent Circle to Tangent Circle.
It could be easier...
I see Revit behaving this way, they regard the first point as ineligible to being tangent because it depends on the bearing of the line, With that assumption or bias, the first point is necessary to make a tangent condition possible. I can easily snap to a location on the circle (a pulley for example) that couldn't be tangent to the next pulley.
AutoCAD deals with this in a clever fashion (when we invoke the tangent snap) by fixing (changing) the first point to be tangent after the second point is placed. If we aren't careful with our second pick point (snap tangent too) the tangent line might end up on the opposite side of the pulley.
In contrast, Revit handles it naively, because it regards our first point as ineligible to tangents because it isn't considering this particular end result: "I want to draw a line tangent to two circles". AutoCAD appears to know this by virtue of snapping tangent for the first point so it can adjust the final bearing, and attachment to the circle, of the line.
To get around this naiveté, I place the first point on the pulley where it looks like it can be tangent, to my eye. The second point snaps to tangent with the icon. I return to the first point and grip/drag it away and back to let the snap icon appear, to fix it for tangent, just to see if I was close. If my guess wasn't accurate, it is now.
After reading a reply to my comments I did a quick sketch in AutoCAD and then did the same sketch in Revit using the same pulley sizes and offset from one another (see Footnote). The tangent lines have the same x/y properties for start and end as the AutoCAD version, that I made using its snap tangent.
This is the native DWG sketch and properties screen captures for each element.
This is same information but for the Revit drafting view exported to DWG. When I create an External Reference of the exported Revit drafting view it lands right on top of the native sketch. If you look really closely you'll see a value is slightly different in the Revit version. I think that might be my fault, sketching. Regardless, I think close enough is fair.
Footnote: Regarding a drafting view aligning with a DWG file after export: It might not be obvious but drafting views have an origin. To test that claim link a DWG, that has a marker at the WCS origin, into one and you'll see where the origin is. I did that before I did any sketching so I'd know how to place the pulleys in the same place. That made it possible to compare the tangent lines after exporting it to DWG.
Also the Start and End X/Y values are reversed. That's either just how Revit interprets the vector of each line segment or it's because of the direction I chose to sketch them in Revit. In AutoCAD I started at the smaller pulley. I didn't make sure to sketch in the same way in Revit, sloppy scientist.
It could be easier...
I see Revit behaving this way, they regard the first point as ineligible to being tangent because it depends on the bearing of the line, With that assumption or bias, the first point is necessary to make a tangent condition possible. I can easily snap to a location on the circle (a pulley for example) that couldn't be tangent to the next pulley.
AutoCAD deals with this in a clever fashion (when we invoke the tangent snap) by fixing (changing) the first point to be tangent after the second point is placed. If we aren't careful with our second pick point (snap tangent too) the tangent line might end up on the opposite side of the pulley.
In contrast, Revit handles it naively, because it regards our first point as ineligible to tangents because it isn't considering this particular end result: "I want to draw a line tangent to two circles". AutoCAD appears to know this by virtue of snapping tangent for the first point so it can adjust the final bearing, and attachment to the circle, of the line.
To get around this naiveté, I place the first point on the pulley where it looks like it can be tangent, to my eye. The second point snaps to tangent with the icon. I return to the first point and grip/drag it away and back to let the snap icon appear, to fix it for tangent, just to see if I was close. If my guess wasn't accurate, it is now.
After reading a reply to my comments I did a quick sketch in AutoCAD and then did the same sketch in Revit using the same pulley sizes and offset from one another (see Footnote). The tangent lines have the same x/y properties for start and end as the AutoCAD version, that I made using its snap tangent.
This is the native DWG sketch and properties screen captures for each element.
This is same information but for the Revit drafting view exported to DWG. When I create an External Reference of the exported Revit drafting view it lands right on top of the native sketch. If you look really closely you'll see a value is slightly different in the Revit version. I think that might be my fault, sketching. Regardless, I think close enough is fair.
Footnote: Regarding a drafting view aligning with a DWG file after export: It might not be obvious but drafting views have an origin. To test that claim link a DWG, that has a marker at the WCS origin, into one and you'll see where the origin is. I did that before I did any sketching so I'd know how to place the pulleys in the same place. That made it possible to compare the tangent lines after exporting it to DWG.
Also the Start and End X/Y values are reversed. That's either just how Revit interprets the vector of each line segment or it's because of the direction I chose to sketch them in Revit. In AutoCAD I started at the smaller pulley. I didn't make sure to sketch in the same way in Revit, sloppy scientist.
Wednesday, December 20, 2017
Dimension Inline and Dynamo
(Edit: If you download and apply an update to his Rhythm package after 1/17/2018 you'll have this node too)
From time to time I've heard people ask about putting the dimension value on the line (inline) instead of above the dimension line the way Revit prefers. The only way we can do it within Revit is to manually grip and drag the dimension value down to the line.
More recently I read a thread at the Autodesk Forum asking about this. The premise in their situation is that it is a significant roadblock to using Revit for one of their client's projects, it doesn't meet their drawing standard unless the dimensions are inline.
I was trading messages with Aaron Maller and mentioned it to him. Aaron was trading messages with John Pierson and a few minutes later I learned it is possible with Dynamo and a custom node. This morning he shared this with me, as well as replying to the thread. Nicely done John! We are sooo connected these days.
From time to time I've heard people ask about putting the dimension value on the line (inline) instead of above the dimension line the way Revit prefers. The only way we can do it within Revit is to manually grip and drag the dimension value down to the line.
More recently I read a thread at the Autodesk Forum asking about this. The premise in their situation is that it is a significant roadblock to using Revit for one of their client's projects, it doesn't meet their drawing standard unless the dimensions are inline.
I was trading messages with Aaron Maller and mentioned it to him. Aaron was trading messages with John Pierson and a few minutes later I learned it is possible with Dynamo and a custom node. This morning he shared this with me, as well as replying to the thread. Nicely done John! We are sooo connected these days.
Thursday, December 07, 2017
How Often to Synchronize with Central - SwC
Grist from a recent support conversation..."How often should we use Synchronize with Central (SwC)? We have some users doing it every minute."
Well....every minute seems a bit much...but...
The number of people actively working on a file affects the truth of the statement too. Every 30 minutes, for example, is too infrequent in my opinion. My own habit is to SwC as often as I complete any given task. I tend to take small bites, tasks that are 1-10 minutes, and SwC as soon as they are done.
More frequent SwC is less data transmission than every 30 minutes, potentially. Replacing or reloading a title block for 1,000 sheets is not a small task and probably ought to be done at lunch, advising people to create new local files afterward. Otherwise each sync will need to needlessly update each local file's copy of the sheet's title block too, for everyone. If that is done while they are all away they just inherit the new version of the project with their new local file.
It's all relative though because the transaction comparison between syncing that kind of change and closing a model and opening it later is subtle. In fact opening a file again might be slower, but reasonable, depending on how many people are involved. It can be justified though, especially if they are out of the project anyway such as out for lunch or after hours etc.
I think it is more important to be aware of other users also using SwC, than imposing a specific time requirement. When more than one person uses SwC at the same time Revit has to parse those changes and it does so, more or less, in a single threaded manner, not like a multi-thread OS (though they are improving that all the time) doing simultaneous tasks. It has to reconcile changes and move to others once it is satisfied it can finish successfully. The more people forcing Revit to do that at the same time the slower it gets for everyone. That's where the advice to schedule or increase the time between SwC came from. One client decided to build their own tool so users can see if someone is syncing. A button on their Quick Access Toolbar parked next to the SwC button is red when someone is syncing and green when nobody is. Green means go for it.
Any sort of "Every 30 minutes" rule is often an over simplification, a rule meant to be easy to implement. In practice it can be just as harmful as helpful. If I slip and go 60 minutes or longer then that starts to slow down SwC times for everyone else too. Pushing and pulling data through a pipe takes time, smaller chunks of data generally take less time and less time to reconcile with the model too.
I'd focus on developing awareness of other users syncing as the priority and it's increasingly important the more users that are working on the same project file.
Well....every minute seems a bit much...but...
The number of people actively working on a file affects the truth of the statement too. Every 30 minutes, for example, is too infrequent in my opinion. My own habit is to SwC as often as I complete any given task. I tend to take small bites, tasks that are 1-10 minutes, and SwC as soon as they are done.
More frequent SwC is less data transmission than every 30 minutes, potentially. Replacing or reloading a title block for 1,000 sheets is not a small task and probably ought to be done at lunch, advising people to create new local files afterward. Otherwise each sync will need to needlessly update each local file's copy of the sheet's title block too, for everyone. If that is done while they are all away they just inherit the new version of the project with their new local file.
It's all relative though because the transaction comparison between syncing that kind of change and closing a model and opening it later is subtle. In fact opening a file again might be slower, but reasonable, depending on how many people are involved. It can be justified though, especially if they are out of the project anyway such as out for lunch or after hours etc.
I think it is more important to be aware of other users also using SwC, than imposing a specific time requirement. When more than one person uses SwC at the same time Revit has to parse those changes and it does so, more or less, in a single threaded manner, not like a multi-thread OS (though they are improving that all the time) doing simultaneous tasks. It has to reconcile changes and move to others once it is satisfied it can finish successfully. The more people forcing Revit to do that at the same time the slower it gets for everyone. That's where the advice to schedule or increase the time between SwC came from. One client decided to build their own tool so users can see if someone is syncing. A button on their Quick Access Toolbar parked next to the SwC button is red when someone is syncing and green when nobody is. Green means go for it.
Any sort of "Every 30 minutes" rule is often an over simplification, a rule meant to be easy to implement. In practice it can be just as harmful as helpful. If I slip and go 60 minutes or longer then that starts to slow down SwC times for everyone else too. Pushing and pulling data through a pipe takes time, smaller chunks of data generally take less time and less time to reconcile with the model too.
I'd focus on developing awareness of other users syncing as the priority and it's increasingly important the more users that are working on the same project file.
Tuesday, December 05, 2017
Revit Coordinate Systems Video
A lengthy exchange at Autodesk's User Forums about this subject reminded me that I've meant to create a short video to describe how they relate to each other for quite awhile. This morning I saw our cutting boards drying next to the sink and realized they could serve as metaphorical coordinate system planes (Project and Survey) work in Revit. I am curious if readers find it helpful.
The original post at the forum dealt with a few projects that had been modelled very far from Revit's Internal Origin/Startup Location. I looked at one of the project files and found the Survey Point and Project Base Point had been moved very far away while unclipped. The modelling started there, really far far away. They started to experience some of the negative symptoms that can occur and started looking for solutions...thus the original post. The short answer is they needed to move their model closer to the origin. No other way around it.
The original post at the forum dealt with a few projects that had been modelled very far from Revit's Internal Origin/Startup Location. I looked at one of the project files and found the Survey Point and Project Base Point had been moved very far away while unclipped. The modelling started there, really far far away. They started to experience some of the negative symptoms that can occur and started looking for solutions...thus the original post. The short answer is they needed to move their model closer to the origin. No other way around it.
Monday, December 04, 2017
Consulting Work - December and January Schedule
I've been very fortunate over the years to find project delays, postponement or cancellations easy to deal with. This year each of those things have happened at the same time. As such I'm putting it out there that, to use the phrase from the very British TV show "Are You Being Served?", "Mr. Stafford are you free? Why yes I'm Free!"
I'd be pleased to hear about training, implementation, modelling ...anything Revity...that I can help with! Just send me an EMAIL.
Thanks for reading!
P.S. Really hoping this isn't indicative of a cycle returning...
I'd be pleased to hear about training, implementation, modelling ...anything Revity...that I can help with! Just send me an EMAIL.
Thanks for reading!
P.S. Really hoping this isn't indicative of a cycle returning...
Thursday, November 30, 2017
Link DWG and Named UCS
Working through a couple support issues recently it turned out that the presence of a Named UCS prevented us from linking a DWG using By Shared Coordinates. Revit would force the DWG to link using Center to Center instead. We tried all the things to resolve it first until we remembered to check this too.
This has been a part of Revit for a long time, the "REVIT60" in the name is the Revit version when it first appeared, Revit 6.0. When we use Publish Coordinates on a DWG file Revit creates this UCS so it can be used from within AutoCAD to ensure any external references that need to align with it will do so. We can delete the Named UCS in AutoCAD by right-clicking on the name.
We have more than one site related DWG for each project to align within Revit. We used Acquire Coordinates on our benchmark file. When all the related DWG files share the same WCS origin we can tell Revit to use By Shared Coordinates when linking them.
An obtuse but factually correct message appears telling us the files don't share coordinates.
Aligning the file based on its WCS is precisely what we want so each of the files align in Revit, possible, again, because we used Acquire Coordinates on the benchmark file first. That aligned the Shared Coordinates with it so the other files could stack on top of each other properly when we linked them.
There are many subtle things that can affect the linking process with DWG files, add this to the pile.
This has been a part of Revit for a long time, the "REVIT60" in the name is the Revit version when it first appeared, Revit 6.0. When we use Publish Coordinates on a DWG file Revit creates this UCS so it can be used from within AutoCAD to ensure any external references that need to align with it will do so. We can delete the Named UCS in AutoCAD by right-clicking on the name.
We have more than one site related DWG for each project to align within Revit. We used Acquire Coordinates on our benchmark file. When all the related DWG files share the same WCS origin we can tell Revit to use By Shared Coordinates when linking them.
An obtuse but factually correct message appears telling us the files don't share coordinates.
Aligning the file based on its WCS is precisely what we want so each of the files align in Revit, possible, again, because we used Acquire Coordinates on the benchmark file first. That aligned the Shared Coordinates with it so the other files could stack on top of each other properly when we linked them.
There are many subtle things that can affect the linking process with DWG files, add this to the pile.
Monday, November 27, 2017
Mr. Revit OpEd at The Whiskey a Go Go
This provides ample distraction from writing as much as I used to. I can hit ALL the THINGS!!
Yes, I've been earnestly playing the drums again. When I moved to California the three piece band (Angry Neighbors) I had been part of for roughly ten years found themselves without a drummer. They've kept themselves busy since, most recently as part of a group they call Harmonic Dirt.
For many years steady travel for work made it impractical for me to be part of a band here. I haven't needed to travel nearly as much for the last couple of years and I realized I could make it work. So far so good.
Last May I joined a band called Parker Street Gypsies. It is led by and features songs written by Michelle Kasajian (vocals/guitar). Armando "Mondo" Lopez (guitar/vocals) contributes songs as well. Add in Charlie Peck (bass guitar) and yours truly to provide the foundation and we make four. We've been rehearsing regularly working toward playing in front of people more often. Our first time out was at the O.C. County Fair.
Our next gig is THIS Saturday, December 2nd at The Whiskey a Go Go.
We open for The Baby's, a favorite 70's band of mine (and many others)!! I'm looking forward to seeing and hearing them as well hoping to meet their drummer Tony Brock. His playing was/is a strong influence on my own approach to the drums. I think my favorite album is Union Jacks but I tend to waffle on favorite anything.
Believe it or not, there are FIVE bands leading up to The Baby's performance Saturday night; they are: Parker Street Gypsies (us), Alinea, Nation of Salvation, Union of Saints, and Kirk Randall & the Back Beat. We play last but just before The Baby's set.
Despite what you may read or hear live music is still out there waiting for you to experience/enjoy. Musicians are still struggling, as ever, to satisfy their muse and play for you/us, no matter how much the business has changed.
If you are in the LA area and looking for something to do on Saturday night we'd love to have your support. The Whiskey is an all-ages club, as well as being a famous venue for music historically.
We love to rock!
P.S. At the recent Autodesk University several of us musician types got together one evening after the primary events had wrapped up. We played some tunes at a local rental studio, some were planned in advance and many others weren't. Some turned out pretty well and others...well it was fun to play...
The AU Band consisted of: Robert Green (guitar,vocals), Guillermo Melantoni-Cortabarria (bass guitar, vocals), Steven Shell (guitar,vocals), Shaun Bryant (vocals), Kate Morrical (vocals), Jim Balding (Cowbell-aka Whiskey bottle) and Kelly Cone (vocals)..oh and me. This is a nice shot of Jim Balding helping Steven Shell play guitar or vice versa.
We didn't have a cowbell so JB made do with a Four Roses whiskey bottle that somebody conveniently emptied so it could be used. This was my second year playing with them, good fun!
Yes, I've been earnestly playing the drums again. When I moved to California the three piece band (Angry Neighbors) I had been part of for roughly ten years found themselves without a drummer. They've kept themselves busy since, most recently as part of a group they call Harmonic Dirt.
For many years steady travel for work made it impractical for me to be part of a band here. I haven't needed to travel nearly as much for the last couple of years and I realized I could make it work. So far so good.
Last May I joined a band called Parker Street Gypsies. It is led by and features songs written by Michelle Kasajian (vocals/guitar). Armando "Mondo" Lopez (guitar/vocals) contributes songs as well. Add in Charlie Peck (bass guitar) and yours truly to provide the foundation and we make four. We've been rehearsing regularly working toward playing in front of people more often. Our first time out was at the O.C. County Fair.
Our next gig is THIS Saturday, December 2nd at The Whiskey a Go Go.
We open for The Baby's, a favorite 70's band of mine (and many others)!! I'm looking forward to seeing and hearing them as well hoping to meet their drummer Tony Brock. His playing was/is a strong influence on my own approach to the drums. I think my favorite album is Union Jacks but I tend to waffle on favorite anything.
Believe it or not, there are FIVE bands leading up to The Baby's performance Saturday night; they are: Parker Street Gypsies (us), Alinea, Nation of Salvation, Union of Saints, and Kirk Randall & the Back Beat. We play last but just before The Baby's set.
Despite what you may read or hear live music is still out there waiting for you to experience/enjoy. Musicians are still struggling, as ever, to satisfy their muse and play for you/us, no matter how much the business has changed.
If you are in the LA area and looking for something to do on Saturday night we'd love to have your support. The Whiskey is an all-ages club, as well as being a famous venue for music historically.
We love to rock!
P.S. At the recent Autodesk University several of us musician types got together one evening after the primary events had wrapped up. We played some tunes at a local rental studio, some were planned in advance and many others weren't. Some turned out pretty well and others...well it was fun to play...
The AU Band consisted of: Robert Green (guitar,vocals), Guillermo Melantoni-Cortabarria (bass guitar, vocals), Steven Shell (guitar,vocals), Shaun Bryant (vocals), Kate Morrical (vocals), Jim Balding (Cowbell-aka Whiskey bottle) and Kelly Cone (vocals)..oh and me. This is a nice shot of Jim Balding helping Steven Shell play guitar or vice versa.
We didn't have a cowbell so JB made do with a Four Roses whiskey bottle that somebody conveniently emptied so it could be used. This was my second year playing with them, good fun!
Friday, September 29, 2017
Phases are Deleted - Electrical Issue - Cancel placing a wire
A client shared this issue with me a couple of weeks ago and Autodesk has acknowledged it as a bug. If you've already installed 2018.1 it has been patched, so the scary bit that follows has been dealt with.
The issue: Place the first node of a wire and then cancel (press ESC key for example) before placing the second node. Afterward, people find that their project's Phases are no longer available. In other words, the phases are not listed in the Phasing dialog box nor in the Phase parameter for elements, when examining the Properties palette. Also, the buttons that allow us to create new phases are disabled in the Phases dialog.
Bad bug! Fixed in version 2018.1.
The issue: Place the first node of a wire and then cancel (press ESC key for example) before placing the second node. Afterward, people find that their project's Phases are no longer available. In other words, the phases are not listed in the Phasing dialog box nor in the Phase parameter for elements, when examining the Properties palette. Also, the buttons that allow us to create new phases are disabled in the Phases dialog.
Bad bug! Fixed in version 2018.1.
Thursday, September 21, 2017
Fixture Units don't Update
I read a post at RFO that said the value for Fixture Units added up along a pipe run were correct at the pipe (in properties) but that tags attached to those pipes did not report a matching value. My first thought was that the system's Calculations parameter was assigned to something other than Flow. So I mocked up a quick test (using version 18.1.1.18 - 20170907_2315(x64) - 2018.1.1). Three families, two with the same Fixture Units assigned and one rogue.
I changed the middle fixture to be the same as the outer two and the pipe properties responded, the tag didn't (2nd from left). I took a look at the Calculations parameter for the Sanitary Piping System. This is using a stock Imperial Plumbing template. It's already set to Flow.
I switched it to None, clicked Apply, and the tags responded with this (Performance does the same).
I changed it back to Flow, clicked Apply, and the tags responded again but now they report the correct values.
I thought that there might have been a subtle change within the Mechanical and/or Piping settings that I missed when Revit 2018 arrived. I don't think there is though.
If you're counting on Fixture Units being added up and reported correctly in tags, you'll need to keep an eye on this. I've been able to wake up the tags by toggling between Calculation Settings for the Pipe System.
Added: Temporarily adding a pipe or altering the connected pipes also cause the tags to wake up. Also, just to make things stranger, changing the fixtures again I find the information displayed in properties of the pipe does not respond either, nor does a schedule of Pipes. However, if I have a Piping Systems schedule that does update as changes to fixtures are made.
I changed the middle fixture to be the same as the outer two and the pipe properties responded, the tag didn't (2nd from left). I took a look at the Calculations parameter for the Sanitary Piping System. This is using a stock Imperial Plumbing template. It's already set to Flow.
I switched it to None, clicked Apply, and the tags responded with this (Performance does the same).
I changed it back to Flow, clicked Apply, and the tags responded again but now they report the correct values.
I thought that there might have been a subtle change within the Mechanical and/or Piping settings that I missed when Revit 2018 arrived. I don't think there is though.
If you're counting on Fixture Units being added up and reported correctly in tags, you'll need to keep an eye on this. I've been able to wake up the tags by toggling between Calculation Settings for the Pipe System.
Added: Temporarily adding a pipe or altering the connected pipes also cause the tags to wake up. Also, just to make things stranger, changing the fixtures again I find the information displayed in properties of the pipe does not respond either, nor does a schedule of Pipes. However, if I have a Piping Systems schedule that does update as changes to fixtures are made.
Tuesday, September 19, 2017
New Book - Delivering COBie Using Autodesk Revit
A team of authors led by Bill East (COBie inventor) has finished a book dedicated to COBie and Revit. His team consists of: Shawn O'Keeffe, Richard Kenna and Emma Hooper.
Bill writes:
You can Order your Copy HERE.
Bill writes:
"This is the first comprehensive COBie How-To Guide! We explain the implications of COBie requirements on your professional standard-of-care. Next, we describe the architectural and engineering design best-practices we adopted to help us capture COBie as part of our standard design process. We show you how to unlock the power of the Revit COBie Extension and Classification Manager Add-Ins to automate COBie file production details. And we show you how to share your new found knowledge with your team, company, and stakeholders."David Philp, Global BIM Director, AECOM reviewed the book and had this to say:
"This book offers a comprehensive and real-world insight to the COBie value proposition but most importantly it demonstrates HOW this can be practically achieved. This book is an essential read for anyone that is interested in effectively capturing and using project information. If you want to better understand how to deliver COBie from a Revit environment then this book is a must.”David Light, Autodesk Senior Customer Success Manager also reviewed the book and said this:
"Finally, the AEC industry and the Revit user has an unparalleled guide for helping you understand, as well as deliver COBie from Autodesk Revit!The authors of “Delivering COBie Using Autodesk Revit,” Dr. Bill East, Dr. Shawn O’Keeffe, Richard Kenna, and Emma Hooper look forward to showing you how to make COBie an integral part of the standard design process for yourself and your team, company, and stakeholders. The pre-release spiral-bound “workbook edition” is now available for individual Revit users. The version for purchase by libraries, institutes, and companies available 15-Sep-17.
Delivering COBie should not be scary, as noted, the guidance provided in “Delivering COBie Using Autodesk Revit'” is designed to help AEC industry deliver COBie on any building, as easily as possible.
East and the authoring team provide a detailed history of COBie, so you understand the background of why COBie? It helps demystify some urban myths around COBie, allowing you to better understand the value of this industry standard digital exchange format. The book runs through best practice tips for model development, model configuration and data preparation for Autodesk Revit.
The guide leads the user onto the configuration of the free Classification Manager and the COBie Extension. Lastly, 'Delivering COBie Using Autodesk Revit' teaches the reader how to apply various concepts on a Dormitory Project example, through shared best practice from recognized industry experts, explaining how to prepare the Revit model for repeatable COBie deliverables."
You can Order your Copy HERE.
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!
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, September 12, 2017
Clipped or Un-clipped - That is the Question
The question asked: "Steve, should we leave our coordinate system icons clipped or un-clipped?"
My Answer: As we know, the Project Base Point (PBP) and Survey Point (SP) can be un-clipped. If they are untouched we'll find them clipped.
When these are clipped the symbols for each of these are attached to the coordinate systems they belong to. That means moving either while clipped will alter the coordinate system. If this is done unintentionally, or by someone who does not realize they have been adjusted intentionally already, the coordinate system(s) will be changed.
Therefore I'd say it is not unreasonable to leave these in their NOT clipped or un-clipped state at all times, especially after they have been adjusted intentionally to align models or survey data. If they are not clipped then accidental movement of these icons do not alter their related coordinate systems. It merely changes the symbol's position relative to their coordinate systems.
I regard these symbols as markers or annotation when they are not clipped. In this state they are harmless to our coordinate machinations. Clipped they pose a danger to our careful adjustments to align models and site information.
My opinion: Keep them Not clipped, un-clipped.
My Answer: As we know, the Project Base Point (PBP) and Survey Point (SP) can be un-clipped. If they are untouched we'll find them clipped.
When these are clipped the symbols for each of these are attached to the coordinate systems they belong to. That means moving either while clipped will alter the coordinate system. If this is done unintentionally, or by someone who does not realize they have been adjusted intentionally already, the coordinate system(s) will be changed.
Therefore I'd say it is not unreasonable to leave these in their NOT clipped or un-clipped state at all times, especially after they have been adjusted intentionally to align models or survey data. If they are not clipped then accidental movement of these icons do not alter their related coordinate systems. It merely changes the symbol's position relative to their coordinate systems.
I regard these symbols as markers or annotation when they are not clipped. In this state they are harmless to our coordinate machinations. Clipped they pose a danger to our careful adjustments to align models and site information.
My opinion: Keep them Not clipped, un-clipped.
Thursday, September 07, 2017
Shared Coordinates - Autodesk Reference Information
It's September already...no posts in August...time flies.
This post is brief, merely a referral. If you struggle with understanding Revit's coordinate system then THIS LINK, at Autodesk's Knowledge Base (KB) site for this subject might be helpful. I like the images and some of explanations or interpretations it offers.
Check it out, it may help!
Edit: I wrote this on Sept. 7th originally, received an unflattering comment about it, returned it to draft, revised it, and restored it to published on Sept. 14th.
I was lazy. I thought the information was an addition to their formal help documentation. When I saw the comment I read through the KB article again and realized that it was written by an Autodesk User Group member and submitted to their Knowledge Base system, which happens to be curated by different people than the product documentation group. I might quibble with some subtlety of it here or there but its approach may help someone get a grasp on the bigger picture. Just keep in mind that its claims are not gospel, nor written by Autodesk's own people.
This post is brief, merely a referral. If you struggle with understanding Revit's coordinate system then THIS LINK, at Autodesk's Knowledge Base (KB) site for this subject might be helpful. I like the images and some of explanations or interpretations it offers.
Check it out, it may help!
Edit: I wrote this on Sept. 7th originally, received an unflattering comment about it, returned it to draft, revised it, and restored it to published on Sept. 14th.
I was lazy. I thought the information was an addition to their formal help documentation. When I saw the comment I read through the KB article again and realized that it was written by an Autodesk User Group member and submitted to their Knowledge Base system, which happens to be curated by different people than the product documentation group. I might quibble with some subtlety of it here or there but its approach may help someone get a grasp on the bigger picture. Just keep in mind that its claims are not gospel, nor written by Autodesk's own people.
Friday, July 14, 2017
20 Mile Threshold on Import
This is a follow up to my earlier post this week regarding the 20 mile threshold. A comment to that post mentioned that the governing extent is equivalent to a 10 mile radius sphere whose origin is at 0,0,0. In my own testing I've observed the threshold is more closely defined as a cube.
This image is a 10 mile radius sphere with a line segment that travels beyond the edges of the sphere but within the boundary that a cube would have.
You can see the highlighted square is the extent of the DWG file and line extends outside of the sphere at each end but is still inside the boundary of where a cube would lie instead.
This image is the same file but the line is altered to extend beyond the edge of the sphere/cube extent.
This is the message that appears when I reloaded the file after altering the line's extent.
The warning can be avoided if we ensure that the DWG file doesn't have any elements that extend beyond the 20 mile cube (10 mile radius). The cube can be quite far from the origin of the DWG file but nothing can be outside the cube's boundary.
This image is a 10 mile radius sphere with a line segment that travels beyond the edges of the sphere but within the boundary that a cube would have.
This image is the same file but the line is altered to extend beyond the edge of the sphere/cube extent.
The warning can be avoided if we ensure that the DWG file doesn't have any elements that extend beyond the 20 mile cube (10 mile radius). The cube can be quite far from the origin of the DWG file but nothing can be outside the cube's boundary.
Wednesday, July 12, 2017
Reset Shared Coordinates Update
During April 2012 I wrote about using a separate file as a diversionary tactic to allow us to reacquire coordinates from a model we used Acquire Coordinates on before; now that it has changed and no longer lines up with our own work.
In the years since that post Revit seems to have decided it should remember more than one file has had the Acquire Coordinates tool used on it. Revit used to be monogamous but that's no longer true.
The reset process is still necessary but an extra step is required now: we must deliberately disable the link's Shared Site setting first.
Usually it is necessary to move the linked file to align with ours and so its new position can be reacquired. If the setting isn't disabled first it will trigger Revit's desire to change the Shared Coordinate system of the link. Keep in mind that Acquire Coordinates is a pull transaction but moving a file that is sharing coordinates causes Revit to think it must push that change out to the related file. If that's what is really needed then consider using Publish Coordinates instead.
Select the linked file and in the Properties Palette click the Shared Site button (by default says Internal unless someone has changed the name). In the Choose Site dialog that appears click the radio button for Do not share site of selected instance.
It should say <Not Shared> like in the image above after choosing that option. It should be possible to move the linked file into the desired position so it lines up with our model correctly again. If it works correctly you won't get a warning to save the changes to the link nor will you get prompted to do so when you save the file.
It is now possible to link a Reset File to use the Acquire Coordinates on. As soon as that is done successfully the original linked file can be used to Acquire Coordinates again, from it instead.
If the disabling step was not taken we'd find that Revit remembers it has a shared coordinate relationship with both files, the original link and the reset file. Examining properties for both linked files would reveal a Shared Site setting in play (Internal) for both.
However, Shared Coordinates and its Survey Point only acts according to the last file Acquire Coordinates was used on regardless how many files Revit is keeping track of. Trying to use Acquire Coordinates on either file in this condition will just generate this warning.
It's almost as if Revit is treating using Acquire Coordinates like a marriage and keeping a record of each marriage, regardless how many divorces the file goes through. I'd recommend it moves on, focus only on the active marriage and make that work.
To recap - if you find your shared coordinate relationship has failed you'll want a divorce. Then you'll fall for someone else quickly, on a rebound, only to discover that your previous love was the best. Just remember you need to get a lawyer involved to disable your first marriage before you start your rebound. This way you'll legally be able to get married again when you come to your senses.
In the years since that post Revit seems to have decided it should remember more than one file has had the Acquire Coordinates tool used on it. Revit used to be monogamous but that's no longer true.
The reset process is still necessary but an extra step is required now: we must deliberately disable the link's Shared Site setting first.
Usually it is necessary to move the linked file to align with ours and so its new position can be reacquired. If the setting isn't disabled first it will trigger Revit's desire to change the Shared Coordinate system of the link. Keep in mind that Acquire Coordinates is a pull transaction but moving a file that is sharing coordinates causes Revit to think it must push that change out to the related file. If that's what is really needed then consider using Publish Coordinates instead.
Select the linked file and in the Properties Palette click the Shared Site button (by default says Internal unless someone has changed the name). In the Choose Site dialog that appears click the radio button for Do not share site of selected instance.
It should say <Not Shared> like in the image above after choosing that option. It should be possible to move the linked file into the desired position so it lines up with our model correctly again. If it works correctly you won't get a warning to save the changes to the link nor will you get prompted to do so when you save the file.
It is now possible to link a Reset File to use the Acquire Coordinates on. As soon as that is done successfully the original linked file can be used to Acquire Coordinates again, from it instead.
If the disabling step was not taken we'd find that Revit remembers it has a shared coordinate relationship with both files, the original link and the reset file. Examining properties for both linked files would reveal a Shared Site setting in play (Internal) for both.
However, Shared Coordinates and its Survey Point only acts according to the last file Acquire Coordinates was used on regardless how many files Revit is keeping track of. Trying to use Acquire Coordinates on either file in this condition will just generate this warning.
It's almost as if Revit is treating using Acquire Coordinates like a marriage and keeping a record of each marriage, regardless how many divorces the file goes through. I'd recommend it moves on, focus only on the active marriage and make that work.
To recap - if you find your shared coordinate relationship has failed you'll want a divorce. Then you'll fall for someone else quickly, on a rebound, only to discover that your previous love was the best. Just remember you need to get a lawyer involved to disable your first marriage before you start your rebound. This way you'll legally be able to get married again when you come to your senses.
Monday, July 10, 2017
Revit 2018 - GEO Reference and Shared Coordinates
I replied to a thread at RFO that asked about Revit 2018 touting support for AutoCAD's GEO Reference feature.
On the surface, there is no obvious difference between how things worked in 2017 (or older versions) compared with 2018. Over the years you may have noticed that the Location Dialog, the one that allows you use a map to locate your project did not do anything at all related to the Shared Coordinate system. All that action did was provide a way for Revit to; originally calculate sun position (and therefore shadows) more believably and more recently to allow for energy analysis estimation to be done.
Now...in Revit 2018, assuming the source DWG file is using AutoCAD's GEO Referencing feature, it is possible for Revit to inherit this data to affect not only the Location (Sun and Energy Analysis) but also the coordinate location of the project (Shared Coordinates).
The thread at RFO also asks about the 20 mile threshold Revit has regarding model size and warning us about model accuracy. The following is a restatement of things I've written in the past. Specifically they asked if there was any change to this in 2018. There isn't that I know of. I included the following to superficially explain the reason it exists.
The 20 mile threshold is a math and computer science problem that Revit developers choose not to lie to us about. They want us to keep the model as close to the file's mathematical origin as possible. External files (and internal modelling) that have data whose extents are larger than 20 miles begin to influence the accuracy of the calculations required to generate and display the model faithfully.
More often than not a civil file is not really larger than 20 miles. It just has elements that are farther away from the origin than that. Revit doesn't mind that issue and it doesn't mind assigning very large coordinates values to the shared coordinate origin (Survey Point).
It only cares when there are elements that are beyond the threshold. For example a file that only has two short line segments that are 30 miles apart will cause a warning. A file with an entire set of contour lines 40 miles away from the origin won't cause an error IF all the contours themselves and other annotation don't cause the extent of elements to also be larger than the 20 mile threshold. Distance from the origin is one aspect and the total extent (X,Y AND Z) of the elements in the file is the other.
Ultimately, the error appears because they want us to know that this external data could negatively affect the accuracy of what we work with inside Revit.
I wrote THIS POST to discuss how I deal with survey files that violate the threshold. It starts out with one issue (transparent elevations/sections) that occurs when the threshold is crossed.
On the surface, there is no obvious difference between how things worked in 2017 (or older versions) compared with 2018. Over the years you may have noticed that the Location Dialog, the one that allows you use a map to locate your project did not do anything at all related to the Shared Coordinate system. All that action did was provide a way for Revit to; originally calculate sun position (and therefore shadows) more believably and more recently to allow for energy analysis estimation to be done.
Now...in Revit 2018, assuming the source DWG file is using AutoCAD's GEO Referencing feature, it is possible for Revit to inherit this data to affect not only the Location (Sun and Energy Analysis) but also the coordinate location of the project (Shared Coordinates).
The thread at RFO also asks about the 20 mile threshold Revit has regarding model size and warning us about model accuracy. The following is a restatement of things I've written in the past. Specifically they asked if there was any change to this in 2018. There isn't that I know of. I included the following to superficially explain the reason it exists.
The 20 mile threshold is a math and computer science problem that Revit developers choose not to lie to us about. They want us to keep the model as close to the file's mathematical origin as possible. External files (and internal modelling) that have data whose extents are larger than 20 miles begin to influence the accuracy of the calculations required to generate and display the model faithfully.
More often than not a civil file is not really larger than 20 miles. It just has elements that are farther away from the origin than that. Revit doesn't mind that issue and it doesn't mind assigning very large coordinates values to the shared coordinate origin (Survey Point).
It only cares when there are elements that are beyond the threshold. For example a file that only has two short line segments that are 30 miles apart will cause a warning. A file with an entire set of contour lines 40 miles away from the origin won't cause an error IF all the contours themselves and other annotation don't cause the extent of elements to also be larger than the 20 mile threshold. Distance from the origin is one aspect and the total extent (X,Y AND Z) of the elements in the file is the other.
Ultimately, the error appears because they want us to know that this external data could negatively affect the accuracy of what we work with inside Revit.
I wrote THIS POST to discuss how I deal with survey files that violate the threshold. It starts out with one issue (transparent elevations/sections) that occurs when the threshold is crossed.
Monday, June 26, 2017
Active View can Matter When Linking Using Positioning Auto - Center to Center
If you link a model via Positioning: Auto - Center to Center in a plan view its zero elevation will align with the host model's zero elevation.
Do that in an elevation or section view however and the linked model may not rest at the correct Zero elevation. The discrepancy man be very subtle or quite obvious. It will depend on the adjusted extents of the view that is active.
The trigger appears to be the elevation or section view being cropped very shallow (only one level visible) prior to linking the model (tested as far back as Revit 2015). If all the levels are visible in the view it seems to be more reliable.
Far safer me thinks to just link via a plan view, something to watch out for.
Do that in an elevation or section view however and the linked model may not rest at the correct Zero elevation. The discrepancy man be very subtle or quite obvious. It will depend on the adjusted extents of the view that is active.
The trigger appears to be the elevation or section view being cropped very shallow (only one level visible) prior to linking the model (tested as far back as Revit 2015). If all the levels are visible in the view it seems to be more reliable.
Far safer me thinks to just link via a plan view, something to watch out for.
Subscribe to:
Posts (Atom)