Showing posts with label Troubleshooting. Show all posts
Showing posts with label Troubleshooting. Show all posts

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.

Monday, March 09, 2020

Parameter is Missing for Some Types

From a thread at RFO, Aaron explains what's gone wrong...

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.
  1. Take any Family that uses a Shared Family Type Parameter, that has a default value.
  2. Find the family in the project browser, that is the Family and Type that's in the default value.
  3. Delete that family from the Project Browser.
  4. After you've clicked *DELETE* in the warning, go back to the original Family (the parent family with the parameter).
  5. For JUST the types that had that default value set, that parameter is now gone.
And yes, the instances in your project are hella broken, now."

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.

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:

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

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.

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.
  • Xrefs on their own layer
  • Xrefs always unloaded
If we can count on the AutoCAD user being consistent to assign all of the file's xrefs to a unique layer not shared by any other elements then we can still turn off the overlay xref when it shows up. This shouldn't be too difficult to achieve and many firms already have that standard for xrefs.

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.

Monday, December 30, 2019

UnHelpful Help Location URL

I read about quirky Reviteristic issue at RFO this afternoon. A weird graphics glitch occurs when we interact with the Help Icon families that use the URL parameter feature to reference an external document. This is an example of it in the sample architecture model that ships with Revit (rac_basic_sample_project.rvt - in imperial content).


When we select the icon and examine its properties we get this Learning Link parameter.


When we click in the field the small button appears with the ellipsis icon. Clicking on the that button will take us to the URL saved in family.


The trouble begins after we move our cursor away from the field and start to resume work. The URL is stuck on screen over another parameter like below, the Detail Number parameter for the view.


I noticed that I can work past the issue if I click in the Default Analysis Display Style field, which I presume works because it also has an navigation/ellipsis style button.


I also noticed that if I am careful to click on the field right above the Learning Link, called Location, before leaving the Properties Palette I can avoid the issue too.


The forum thread was talking about this in 2019 but these images are from 2020.2. 

Monday, December 23, 2019

Revit 2020.2 Internal Origin Part Three

John Pierson and Parallax Team Apps recently shared a solution at the Autodesk App Store called Internal Origin Hide-ifier. I thought mine was cool but it doesn't install itself or come with a Doge.


It's only 1,000 bucks...nope its free!! Check it out.

Friday, December 06, 2019

Internal Origin Follow Up

After I shared the earlier Dynamo graph I received an email from Aaron Rumple that did away with any package requirements. He wrote a python script and added it to my graph. It also eliminates the warning message that appears after running mine. The crux of that issue is the need to filter out view templates from the process because while view templates are applied to views under the hood they are also views...at least that's my layman's understanding.

Many thanks to Aaron, a real design software savant.

Download the new Dyn

As before, my graph allows you to include/exclude the internal origin, survey point and project base point. Just edit the settings of the Dyn before running it (see previous post).

Saturday, November 30, 2019

Work Plane Based Families and Rotate w Copy

I participated in a thread at Autodesk's Revit forum and it took me far too long to catch on to the issue described at the outset. I should have retraced the thread sooner, but I did get there eventually.

I'm referring to the Rotate tool and its Copy option, this...


The issue boils down to this: the Rotate with Copy option works/affects a Work Plane-Based (and face-based) family differently than when a family is merely hosted by a Level (all non "based" families). Let's start here, imagine I want two screens on my desk like this.


These are stock families: TV - Flat Screen.rfa and Desk.rfa The desk has a top surface that isn't visible in plan view so it can't act as a face to host the TV. I changed that. The TV isn't a work plane-based family. In a plan view, when I place it on the desk it ends up eaten by the desk because it looks like this in a 3D view.


Sure, I can use its Elevation from Level parameter to put it on the desk (an illusion of a relationship). When I move the desk I need to remember to select the TV too (or make a group...or...I digress). I get the clever idea, "Make this family Work Plane-Based, that's easy!"


Using Rotate with Copy should give me the result I want in the first image and it does until I check the box for Work Plane-Based. The angle I decide I want between the screens is 22.5 degrees. I added a couple reference planes for the images to help see what happens, the desired result.


That's what I want except that they should be hosted by the desk, not relying on using the Elevation from Level parameter. When I use Rotate with the Copy option after editing the TV family to make it Work Plane-Based (also Always Vertical is checked) I get this result.


Notice the TV angle itself is correct but it's location is wrong...and a warning message appeared to help me notice... It's been moved/copied by double the input value of 22.5 degrees using the origin of rotation correctly and managed to maintain the angle I wanted. This next image summarizes what happened.


That's weird enough on its own but I can go weird by one more, un-check the TV's Always Vertical parameter. After running through the exercise again I get this outcome.


This time it applied the rotation input angle of 22.5 degrees x 2 = 45 degrees to both rotating the family and its position. This time it did it fully wrong while the previous time it only did it half wrong.

Introduce a Floor, instead of a desk family, into the mix and place the TV family before it is Work Plane-Base with Always Vertical and this happens. No rotation, just copy and in the same place no less.


When the TV family is Work Plane-Based and Always Vertical is used then it works wrong in the same way as relying on the desk's face as the host did.

I imagine Revit is attempting to relate the rotation and copy actions to the family's host, since that is the work plane the family is hosted by. Clearly it is unable to do so properly. I think it is reasonable to expect to get the same result whether level based or work plane-based. This post and the images are from using Revit 2020.2 but I did the same things in Revit 2016 with the same results. This has been around for quite awhile now.

If it is any consolation, the Mirror and Polar Array tools don't suffer from this malady but each have their own prep work required to make them a ready replacement.

Thursday, November 28, 2019

Revit 2020.2 Internal Origin Redux

Happy Thanksgiving to those who observe!

One little thing I'm thankful for, I got a file yesterday from Autodesk (TurnOffInternalOrigin.Dyn) that is meant to be run in Dynamo Player (it's a custom node in testing ATM). You can download the file, place it wherever your Dynamo Player is looking for files already or in Dynamo Player just browse to wherever you placed the file. Click the play button (see image) and it will turn off the Internal Origin in all views. This approach means very little Dynamo knowledge is necessary, just enough to get Dynamo Player open and find the file.


Since I already put in some time with my own graph which included the Survey Point and Project Base Point I decided I'd like to be able to turn on/off all three or just the internal origin or some combination. I modified my graph (Control Coordinate Graphics.dyn) to provide input options (see image).


When you use Dynamo player you can edit the input options through On/Off switches (see image).


Click the little Properties button (looks like a old Macintosh computer to me). Clicking the toggle will make the statement either true or false for each "hide" question. All three true = all off for example. Remember my graph is dependent on a node from the Archilib package, make sure you've installed that before trying to use it.

Monday, June 17, 2019

Reference Planes without Names

It is a common practice to add a name to the reference planes we create. If it isn't common where you work then it ought to be. The name helps give a hint to anyone that works in the model that this reference plane is more important than those without a name. It can also help understand what it is for, why it was made.

There are some who make the effort to clear out reference planes that are not named periodically, just another of any number of model/housekeeping chores. I've even seen Dynamo scripts intended for this task.

If you're using Ideate's Explorer you'll find it easy to see a summary of all the reference planes in the model. In the following image I've created two reference planes, one with a name and another without a name.


Notice that there are five (5) reference planes listed though. As it happens, when the Edit Profile concept is used on a wall four reference planes are created and internally applied against the sketch of the wall. They are only visible to us while editing the wall's profile sketch. We can't see these reference planes in the regular user interface, it only becomes very apparent with their Explorer tool.

It is also possible for us to create reference planes while creating any sketch based element, like a floor or stair for example. These reference planes are only visible to us while editing their related sketch.

The reference planes associated with a wall's edited profile can't be deleted via IDEATE Explorer. It can delete them when we've created our own within a wall's profile and other sketch based elements.

Attempting to clean up these unnamed reference planes might also be an issue if you're writing your own code or Dynamo script to delete them. We can/could add names to these internal reference planes (wall profile) but I don't think that's a task that worth the effort.

Something to keep in mind.

Thursday, May 23, 2019

Structural Column Disappears - Part Deux

Yesterday while trading messages with a friend we discussed my previous post about columns disappearing. He suspected it might explain the issue he was observing. After looking more closely it turned out that it doesn't. In his situation the structural columns were modeled the full height of the building and Join Geometry was used on walls, that passed through (overlapped) the columns, at each floor (level). The result: at some levels no column appeared while at others they do.

It was necessary to pull the walls back so they stop at the surface of the columns. Join Geometry allowed for the desired appearance and the columns reappeared at the other levels where they were missing earlier.

Monday, May 20, 2019

Structural Column Disappears in Detail View Type

When we create a Callout within a plan view we can choose between Floor plan and Detail. A structural column that uses a negative offset won't show up when a wall exists in the same location when a Detail view type is used. It works fine in a Floor plan view type.

Here are some example images. The first one is showing the negative offset used. If the offset is zero then there is no graphical issue, the column shows up.


This image shows both callouts in the overall floor plan, Detail on the left and Floor on the right.


This is the Floor Plan Callout, column shows up as expected.


This is the Detail Callout, no column is visible.


This is the same Detail Callout but my cursor is hovering over the column and Revit sees it, highlights it despite not being visible. The wall is masking the column.


This is the same Detail Callout but the view is changed to use Wireframe and the column appears.


It boils down to the negative offset applied to the column. The graphics hierarchy does not respect the full height of the column and the wall element is drawn over the structural column. We can also get around the issue if we edit the column family and remove the option: Show family pre-cut in plan views.

Wednesday, April 24, 2019

Keynote Legends and Keynotes not Updating 2018.3

In Revit 2018.3.2.7 I am seeing and getting reports that keynote legends are not updating to show the current state of keynote tags visible in views. The existing workaround to force a refresh by turning on/off the Annotation Crop Boundary works but is entirely impractical to expect a team to open every sheet and do that task for each and every view on a sheet.

This past Knowledge Network post seems relevant. A portion of the text at that article suggests...

Workaround:
There are a few ways you could work around this behavior, and the best method will vary depending on the model geometry and number of affected tags. Here are a few options:

Temporary fixes (these will restore the display keynote tags, but future view changes will clear them again): 
Temporarily adjust the location of the Cut Plane so that is above the affected elements (this will restore the value to the tags) and then restore the original cut plane location. Note: Some customers have noted that for views with dependent views, this process is required:
  1. Open the parent view and adjust the cut plane upward.
  2. open all sheets containing dependent views belonging to this parent view to refresh the keynote tags.
  3. move the cut plane back to its original position in the parent view.
(Note: this may not work for some elements such as Duct; in that case, see the Non-temporary fix below.) Recreate the affected tags manually.

Non-temporary fix (This will prevent future changes to the view from clearing the keynote tag): Adjust view or elements so that the cut plane is above the affected elements. (This could be done with a Plan Region.)

We really need this fixed ASAP!!

Wednesday, November 28, 2018

Downloads Fixed - Some

I have been trying to carve out a little time here and there to fix the paths to downloads I've shared in the past. As of now the most requested stuff is fixed, the egress family and railing files. If you try to download something and hit a page not found warning, drop a comment in the post to bring it to my attention and I'll make it a priority.

Thanks for being patient - The mGmT...

Wednesday, October 17, 2018

Reveal Elements - Hidden Viewport

The other day I was looking at a sheet a user reported it was impossible to select a floor plan view on. It seemed as though Revit did not see the view port on the sheet. People frequently pin views to make it a bit harder for other people to move them on a sheet accidentally. That will still allow a view port to be seen by Revit, it will still highlight as the cursor travels over it.

Then I thought of right-click Hide In View > Element. I used Reveal Elements and I could select the viewport. Using that tool does not hide what is visible in the view, it just disables the ability to select the view port.

Good? Bad? It isn't expected, well I didn't expect it.

Friday, September 28, 2018

Color Fill Calculation Failed is Back

This warning appeared quite a bit with Revit 2016 and patched in subsequent updates.



I've clicked Restart to no joy and I've submitted the error. I've done the Edit Color Scheme and Cancel process described for Revit 2016 with no joy either. Hopefully it will get sorted out again.

Wednesday, September 26, 2018

Links in Posts are Broken

An update to my company site has broken links to the files I've shared in posts throughout the history of my blog posts. Oh joy! I apologize for the inconvenience while I work through those to restore their paths.

Thursday, September 20, 2018

Troubleshooting - Start an Email or Forum Post

I find it helpful to resolve an issue by starting to write an email or forum post (or a blog post) to ask for help or complain about it. Trying to write an explanation for what is happening so someone else might be able to help me focuses my thoughts. Very often I find it isn't necessary to finish writing.

The answer presents itself during the writing.

Next time you're puzzling over something, consider writing down what you think is wrong and the solution may arrive as you type.

Worth mentioning that a short break can also help a lot. Grab a beverage, talk to someone else, or stretch your legs; or all the above. The change gives you chance to work on the problem in the background of your attention.