I wish the list of projects I get when I use Manage Cloud Models (BIM 360 projects) didn't waste sooo much real estate. These big icons are a waste of space, they just mean lots of scrolling. Well if you only have a couple projects on BIM 360 maybe it's no big deal to you. But hundreds? I keep looking for a View option of "List" or "Details" ... something to shrink this bugger down.
That's my experience with Revit 2020 at the moment when a good many projects that I get to look at reside. I'll have to check out 2021 to see if it is any different.Welcome to Steve Stafford's Blog ~ Revit OpEd = OPinion EDitorial ~ My view of things Revit, both real and imagined.
Wednesday, December 02, 2020
Friday, November 06, 2020
Insert From File and BIM 360
When we're working on a BIM 360 hosted project there are times we'd like to use the Insert From File > Insert Views tool. Unfortunately BIM 360 isn't an available path in the Insert From File dialog.
Yes, we can download a copy of the project or open both projects and use Copy/Paste but it would be nicer to be able to use the tool itself as it is an easier/faster (more obvious) process.
Wednesday, August 05, 2020
Ramp Slope is Still a Second Class Citizen
Wrote about this before in 2013. Ramps and the Slope Annotation don't like each other. In the past we could work around their unfriendliness by dragging a working slope annotation from an adjacent floor to the ramp. That no longer works since as far back as 2019.
I'm reasonably sure Ramps have a slope... odd that the annotation doesn't think so? I wrote another post in 2013 too that describes using an adaptive point family to add some graphics to a floor posing as a ramp which might also permit using the slope annotation on it instead. Yet another thing to experiment with.
Then again it might just be better to ignore the ramp feature entirely in favor of Floors?
Labels:
Bug,
Dept. of Reviteristics,
Issues,
Ramps,
Slope
Friday, July 24, 2020
Revit 2021.1 Reset Shared Coordinates and Acknowledge Acquire Coordinates
I saw that Daniel Stine and Autodesk both wrote about the new point release for 2021. Daniel mentioned my past post about resetting shared coordinates because the latest update includes a new feature dedicated to that task.
I also wrote about Acquire Coordinates not rewarding us for successfully completing the task and they granted that wish too.
I also wrote about Acquire Coordinates not rewarding us for successfully completing the task and they granted that wish too.
One of my post's was written in 2012, only eight years to get my wish. Glad I'm pretty patient.
Thursday, May 21, 2020
Revit 2021 - W Shapes-Column Family is Missing
The stock imperial architecture template has the W Shapes-Column family loaded with two types: W10X33 and W10X49. I was experimenting with new features and noticed the family isn't part of the 2021 content deployment, weird. I had to reload from the 2020 version to add a size.
If it's not one thing it's another.
If it's not one thing it's another.
Wednesday, May 20, 2020
Revit 2021 Line Style Naming Tweak
I saw Jason (@RVT) tweet about this yesterday and I thought this is right up the Dept. of Subtle alley.
I've been telling people for years that the brackets meant "these belong to the Revit system" but then there were several other rogue line styles that came along without brackets. I had to explain that any line style you couldn't delete is also a system line styles...
Consider the Dept. of Subtle tickled.
I've been telling people for years that the brackets meant "these belong to the Revit system" but then there were several other rogue line styles that came along without brackets. I had to explain that any line style you couldn't delete is also a system line styles...
Consider the Dept. of Subtle tickled.
Wednesday, March 25, 2020
Create or Opening a Section View Crashes Revit
Have you encountered this issue (and/or elevations)? By crash I mean Revit stops responding, the blue spinning wheel of death. One cause I've identified is HVAC Zones. I've been able to resolve each on so far by deleting the related zone(s) and creating the zone(s) again. I haven't figured out what is going wrong with the zones. I'm just calling it corruption for now but I have no idea if it is something I can prevent or see first yet.
Happy to hear if any readers have encountered this situation too.
Happy to hear if any readers have encountered this situation too.
Monday, March 09, 2020
Parameter is Missing for Some Types
From a thread at RFO, Aaron explains what's gone wrong...
Aaron wrote:
Aaron wrote:
"If someone deletes a family that is also the default option for a Family Type, with that Shared Parameter: Yes, the entire parameter gets deleted. It's terrible behavior, and its been that way for years.
In case I wasnt clear: This is a known issue, and it's easily reproducible.
And yes, the instances in your project are hella broken, now."
- Take any Family that uses a Shared Family Type Parameter, that has a default value.
- Find the family in the project browser, that is the Family and Type that's in the default value.
- Delete that family from the Project Browser.
- After you've clicked *DELETE* in the warning, go back to the original Family (the parent family with the parameter).
- For JUST the types that had that default value set, that parameter is now gone.
Thursday, February 27, 2020
Keynote Schedules Not Updating
I wrote a post in April last year when we were observing some projects that would not update their keynote schedules during printing.
When they issued 2018.3 that issue was reportedly resolved. Moving forward into 2019 and 2020 versions it seems true. However we've seen a few projects that seem to continue to exhibit the problem. Specifically a keynote schedule does not show all of the keynotes that are actually visible in views on the sheet.
With these troubled project files we can force a regeneration IF each sheet view is open during printing. Like before turning the annotation crop boundary off/on or on/off will cause a regeneration too. However printing is when it matters the most. More testing is required before I can be certain there is an ongoing issue in the more recent releases but these projects do exhibit the problem in more recent versions too.
The current solution is to open all the sheets that must print first and then print to PDF. Alternately open a sheet view and print and repeat for all required sheets. If all the views are open then the revision schedule regenerates (you can watch it happen). The sheet view does not have to have Revit's focus, just has to be open in the background at least. Any sheet views that are not open won't refresh.
When they issued 2018.3 that issue was reportedly resolved. Moving forward into 2019 and 2020 versions it seems true. However we've seen a few projects that seem to continue to exhibit the problem. Specifically a keynote schedule does not show all of the keynotes that are actually visible in views on the sheet.
With these troubled project files we can force a regeneration IF each sheet view is open during printing. Like before turning the annotation crop boundary off/on or on/off will cause a regeneration too. However printing is when it matters the most. More testing is required before I can be certain there is an ongoing issue in the more recent releases but these projects do exhibit the problem in more recent versions too.
The current solution is to open all the sheets that must print first and then print to PDF. Alternately open a sheet view and print and repeat for all required sheets. If all the views are open then the revision schedule regenerates (you can watch it happen). The sheet view does not have to have Revit's focus, just has to be open in the background at least. Any sheet views that are not open won't refresh.
Friday, February 07, 2020
Revit 2020.2.1 Hot Fix Posted
Regarding my last post - a Revit 2020.1 Hot Fix is now posted.
Of specific interest...Autodesk writes:
Of specific interest...Autodesk writes:
Issues Resolved:
Fixed an issue that resulted in the loss of family data in some workshared models when family definitions had not been recently modified. This fix does not repair models which have encountered loss of family data, for more information refer to Family Corruption in Revit 2020.2
Labels:
bugs,
Corruption,
Errors,
Families,
Issues,
Revit 2020.2,
Troubleshooting
Tuesday, February 04, 2020
Revit 2020.2 Corrupt or Unusable Families Issue
Autodesk posted an article describing a particularly unpleasant bug/issue that started to appear shortly after 2020.2 was made available. This is the text from the article. If you're using 2020.2 pay close attention, you don't want to catch this bug. They've removed the 2020.2 download until they've resolved the situation.
Issue:
The Revit team has identified a defect with Revit 2020.2 that affects a small percentage of customer projects. In order to reduce the likelihood that customers come across this issue, we have temporarily removed the Revit 2020.2 updates while we work to provide a build that remedies this defect. For customers that have already installed Revit 2020.2, please see the FAQ below. We apologize for any inconvenience this issue may have caused.
Solution:
Q. What is the issue?
A. A change in the way that Revit 2020.2 processes families can cause family content to go missing from workshared central models created in previous versions if the families have existed in an active project for a long time without being modified. The defect results in the deletion of the family content from the central model.
Q. Which versions/models are affected?
A. This issue affects only Revit 2020.2. Previous versions are not affected.
Q. What models are affected?
A. The issue can affect workshared models that were created or upgraded in Revit 2020.0 or 2020.1 which are then repeatedly modified in Revit 2020.2. This issue can impact central models stored locally, on Revit Server, or in Revit Cloud Worksharing. The following models are NOT affected:
Non-workshared models
Workshared models created and exclusively modified in Revit 2020.2
Q. What if I have already installed Revit 2020.2?
A. If everyone on the project team is working in 2020.2, there are a few one-time operations you can take in a Revit 2020.2 build to prevent the issue:
Rename all families in the project (e.g. FamilyX to FamilyX-2 and then back to FamilyX)
OR
Save the model as a new central (must be a new file, not Save As to the same location)
OR
Reload all families (including company, Autodesk, and 3rd party families) in the project
OR
Move the entire project team back to Revit 2020.1
If the team is working on mixed versions, we suggest first getting everyone onto the same version. Working in a mix of Revit 2020.2 and earlier versions can reintroduce the issue to model(s).
Q. What is Autodesk doing to resolve the issue?
A. The Revit team has reproduced the issue and is actively working on a build that does not contain this defect. In the meantime, we advise against installing Revit 2020.2 until the Revit team provides an updated build. To reduce the likelihood that customers come across this issue, we have temporarily removed Revit 2020.2 updates from Accounts and the Autodesk Desktop Application. Due to backend constraints a full install of Revit 2020.2 continues to be available from Accounts.
Q. When will a fix be available?
A. Thanks to the support of our valued customers, the Revit team has been able to reproduce the issue and has identified a fix. In the next few days we will be thoroughly testing the fix. Assuming all goes well, it will then take the team a few more days to make the build available in Accounts and the Autodesk Desktop Application.
Q. Revit 2020.2 has been available for months – why didn’t Autodesk communicate anything previously?
A. The Revit team was first made aware of a possible issue by our customers a few weeks ago. Since these kinds of issues can be difficult to reproduce from scratch, from the time a concern was raised we have been working closely with those customers to reproduce the issue. We were finally successfully able to reproduce, and therefore confirm, the issue at the end of last week when we took action to limit the availability of Revit 2020.2. We have been working diligently to clarify the full scope of the impact and the possible workarounds in order to write this communication.
Q. Why didn’t the Revit team discover the issue during pre-release testing?
A. Unfortunately because this issue requires a combination of model creation and modification of families in a previous version and then extensive modification to the same model in 2020.2 it does not lend itself well to typical testing practices or automated regression tests. This means that unfortunately, despite rigorous Revit 2020.2 testing, we were not able to identify the issue before it affected customer models. We sincerely thank the customers that escalated the issue to us so that we are now able to take appropriate action.
Q. What actions will the Revit team take to prevent this kind of issue from happening again?
A. After the Revit team resolves the immediate issue, we will be holding a retrospective to clarify how the defect occurred and what specific actions we can take to prevent similar issues in the future. As much as possible we will look to create automated tests to cover this kind of situation as that means that every future Revit code submission will be scanned for similar problems.
Labels:
bugs,
Issues,
Revit 2020.2,
Troubleshooting,
Updates
Monday, January 20, 2020
Linked DWG Xref Overlay vs Attached Bug - Part Two
Two options exists to work around this situation (last post). One is easy and Revit focused but depends on the AutoCAD user a little and the second is impractical and depends on the AutoCAD user entirely.
If the xref's are always unloaded before closing a file then they won't show up in a Revit project. That's pretty unlikely. It's inconvenient for AutoCAD users and forgetting just once and the system fails.
- Xrefs on their own layer
- Xrefs always unloaded
If the xref's are always unloaded before closing a file then they won't show up in a Revit project. That's pretty unlikely. It's inconvenient for AutoCAD users and forgetting just once and the system fails.
Labels:
Attached,
DWG,
Importing,
Issues,
Layers,
Linked Files,
Linking,
Overlay,
Troubleshooting,
Xrefs
Monday, January 13, 2020
Linked DWG Xref Overlay vs Attached Bug
Revit has long understood the difference between a DWG having an attached or overlay external reference (Xref). It uses the same logic for its own linking behavior for RVT files. Recently a client began reporting seeing DWG files including Xref layers in Object Styles and Visibility/Graphics even though the DWG has only an overlay Xref. Revit seems to be converting the overlay Xref to a block element and including it and all the layers in the process.
We noticed it happening first with projects hosted on BIM360. That led me to consider it was because this firm isn't using Autodesk Desktop Connector. Not too surprising considering Autodesk recommends using it for linked DWG support on BIM360.
That's irrelevant now that I've reproduced it on a project file based on a stock template, doesn't use worksets and the all files are on a single PC. It's related to how Revit is reloading the linked DWG when a new session of Revit is opened.
It seems to matter that it is a new session of Revit, opening the project again, and to a lesser degree if there are changes in the DWG file. Any of those conditions seems to be enough to find an overlay Xref(s) showing up but reporting as a block element with Query. It is pretty easy to reproduce now that I've done it a few times.
This is the mockup DWG files.
This is the result of linking the file into a Revit project.
This is what happens after opening Revit and the project again.
This is what Revit's Query feature reports when selecting a line that belongs to the overlay Xref in the linked DWG.
It also occurred to me that it could happen if the host file's Xref was originally attached, when it was linked to Revit and changed afterward. Testing didn't support that theory. The example above is based on a xref that was placed as an overlay from the start, not changed to overlay. It also occurred to me that it might be related to large coordinate values. Civil files are linked here primarily. To rule that out, the mock up I show above is at the WCS origin and linked origin to origin.
This particular firm uses Civil 3D/AutoCAD for their civil and landscape disciplines so eliminating DWG files isn't in their future. This bug is annoying AND increasing the time required to prepare projects for plotting and publishing.
Assuming this isn't being caused by some aspect of this firm's EyeTee implementation (PC configuration and/or security measures) I'd love to hear some corroboration.
We noticed it happening first with projects hosted on BIM360. That led me to consider it was because this firm isn't using Autodesk Desktop Connector. Not too surprising considering Autodesk recommends using it for linked DWG support on BIM360.
That's irrelevant now that I've reproduced it on a project file based on a stock template, doesn't use worksets and the all files are on a single PC. It's related to how Revit is reloading the linked DWG when a new session of Revit is opened.
It seems to matter that it is a new session of Revit, opening the project again, and to a lesser degree if there are changes in the DWG file. Any of those conditions seems to be enough to find an overlay Xref(s) showing up but reporting as a block element with Query. It is pretty easy to reproduce now that I've done it a few times.
- Start a new project
- Link a DWG with an Xref (overlay)
- Save the project > close it and the Revit session
- Open Revit again
- Open project (xref is now visible)
- When the project is opened and the linked DWG has changes it will load the xref too.
- If after opening the Revit project the file looks correct using Reload From will display the xref afterward.
This is the mockup DWG files.
This is the result of linking the file into a Revit project.
This is what happens after opening Revit and the project again.
This is what Revit's Query feature reports when selecting a line that belongs to the overlay Xref in the linked DWG.
It also occurred to me that it could happen if the host file's Xref was originally attached, when it was linked to Revit and changed afterward. Testing didn't support that theory. The example above is based on a xref that was placed as an overlay from the start, not changed to overlay. It also occurred to me that it might be related to large coordinate values. Civil files are linked here primarily. To rule that out, the mock up I show above is at the WCS origin and linked origin to origin.
This particular firm uses Civil 3D/AutoCAD for their civil and landscape disciplines so eliminating DWG files isn't in their future. This bug is annoying AND increasing the time required to prepare projects for plotting and publishing.
Assuming this isn't being caused by some aspect of this firm's EyeTee implementation (PC configuration and/or security measures) I'd love to hear some corroboration.
Subscribe to:
Posts (Atom)