Showing posts with label Errors. Show all posts
Showing posts with label Errors. 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.

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, October 08, 2019

BIM 360 Sync Failure Retry

Lately we've been experiencing some poor performance accessing BIM 360 projects. The primary cause eludes us at the moment, but Location Services, Windows Updates and Anti-Virus systems appear to be factors for now. Most of the time it works great but doesn't.

Today I'm having trouble syncing changes with a project and this dialog has been stuck on my screen for about a half hour so far.

It's the fourth cycle of trying to Reload Latest... I think after a second failure to sync it should exit more elegantly. At this point I'm wondering how many times will it try before giving up? There is no option to quit or cancel...just stuck with forcefully quitting Revit at this point? That's polite.

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 19, 2018

Moving a Viewport Error - Disjoin

The Move tool offers us an option called Disjoin. When it is used Revit deletes the original and creates a new element at the new location. That isn't obvious to us but if you examine the GUID (ID's of Selection) you'll find it has a new GUID after the Move is complete.

The option is sticky, we have to remember to disable it when we use the Move tool again. When we are working on sheets and adjusting views we now have an opportunity to run into a confusing error message.

If you run into this or people you support do, just remember to Disable da Disjoin.

Per a comment: My previous post on re Disjoin.

Tuesday, August 14, 2018

Move to Room - Element ID - Review Warnings

If we use Review Warnings often enough, and we should be, we'll run into this warning eventually.
Check the item and Click Show to have Revit try to find a view to show it in. Once it is selected we can either drag the Tag where it is suppose to go or Click the Show Related Warnings button on the ribbon to show the dedicated warning it has again.
When this warning is isolated like this the dialog includes the Move to Room button. An aside, is it amusing or worrisome that Revit seems to think the best way to fix warnings is to delete the offending element (via Delete Checked)? Regardless, Move to Room will resolve the issue whether we can see where the tag is meant to be or not.
Another way to tackle it from the Review Warnings dialog is to make a note of the Element ID referenced in the warning. Now we can then use the Select by ID tool. Enter the ID value and click OK.
This will select the tag, even if we're not in a view that it can be seen in, and then we can use the Show Related Warnings button on the ribbon again followed by the Move to Room button.

Wednesday, February 01, 2017

Properties Palette and Project Browser are not Responsive

This issue tracks back at least a couple of years now but I've just been asked about it again the other day. People report that on occasion Revit refuses to acknowledge when you click on either the Project Browser or Properties Palettes. For example this thread at Autodesk's User Forum began in February 2014.

The suggested methods, in the thread, for fixing this issue include: Using Save As, Disabling Hardware Acceleration and clicking on the Help icon. One person posted that their screen went black first and then Revit crashed. That bit sounds like a graphics card/driver could be involved.

Those fixes resolved the situation but don't tell us specifically why it happened in the first place. Since it has not happened to me personally I can't say for sure why it happens either. I have heard that some errors generate a warning message that can get lost behind the Revit UI. Using ALT + Tab will allow you to cycle between open windows (applications) and you may find a message dialog lurking there. I wouldn't expect any part of Revit to be responsive as such. Interesting that users find that they can access the Help and Application menu (Big R) items despite the two windows being inaccessible.

Perhaps a reader has isolated the cause?

Tuesday, April 26, 2016

Revit 2017 - Text Element Error Message

I created a drafting view and placed a single text element. I type a simple sentence and then clicked the new Close button on the ribbon. I received this nonsensical warning for my effort.

Doesn't seem to matter what view I am placing text in, clicking the Close button pops up the warning. I'm curious if others are seeing this too? I was using the stock architectural template from the Imperial Library. Simple fix is to just finish text in the same old way, don't use the Close button.

Edit: A little more testing and the plan view Level 1 doesn't seem to mind anymore. When I tried it again in the Construction template the floor plan view Level 1 didn't complain but Level 2's did and the Ceiling plan for Level 1 did too. Okay...more weirdness. This is after placing text in an Elevation view.

Traded emails with Aaron Maller last evening and pinned down the circumstances that this issue is reproduceable. It boils down to placing text in a view and then placing text in another view while the previous view is still open. Revit doesn't seem to recognize that the new text is in a different view when the Close button is used. Here's a video explanation.

Saturday, April 09, 2016

Warning Messages and Profile Families

Profile families are loadable (component) families but they don't exist on their own in projects. They are either used to create solid and void forms in the family editor, in-place families in projects or applied to System Families in projects. For example, a Railing, Sweep, Reveal and Floor Slab Edge can all use a Profile family.
Occasionally I'll get a generic sort of warning regarding the system family I'm trying to make, telling me "Sorry Steve, I can't make this thing for you".

Quite often the reason Revit is complaining is because I was sloppy making the Profile family. You may recall I've written about good sketches and bad sketches in the past.
Regardless the error message could certainly be written better; to mention that such an error may be related to a profile that isn't created properly. At this time, the error trapping process may not be able to reach deeply enough into the sketch mode process, for example like we use to create a Floor Slab Edge. Regardless, there is no reason the error message couldn't mention a common culprit, something to prod us to look more deeply for.

Technically the error is in a component family and then evaluated as part of a system family that references it. In a sense it is too far removed from the active operation for Revit to properly recognize what's wrong precisely. Therefore I think it would help if, while saving a profile family type, Revit tested it for proper closed boundaries to help us catch errors while editing the family. Revit does this when we attempt to finish a sketch for a solid or void form. Perhaps it could be a button on the ribbon? Something like Test Profile.

Help us help you Revit!

Thursday, April 07, 2016

Did you Load a Family - Synchronize NOW

ALWAYS use Synchronize with Central (SwC) immediately after loading new families or types (or duplicating system family types). Don't place any instances until you have!

This post is tagging on two earlier posts on the subject of loading content, restating the punch line to emphasize it on its own. If you're inclined to just take my advice just reread the first two sentences and behave accordingly. If you're a bit curious, need more convincing, you can read the FIRST and SECOND posts for more background info.

Thursday, January 14, 2016

Worksharing - Loading Content

I read Jason's post this morning and he describes a classic worksharing gotcha. Unfortunately he hasn't identified the true culprit. I'm referring to this part of his post specifically.
One of our most notorious examples is the infamous Break Line. Each drafting view we imported had a copy of the break line family. By the time anyone noticed, the project model had “Break Line (1)” through “Break Line (22)”.
What he describes is the result of worksharing and multiple users loading the same family in their own local files. Revit sees multiple versions of the same file being loaded from different local files (users) and seeks to protect them by renaming the other versions it encounters. We see this sort of message when it happens.

This error and situation is easy to replicate.
  • Two users open local files for the same project
  • Each user loads a new family and the same type
  • Each uses Synchronize with Central (SwC)
The first person to sync will be successful without an issue but the second person will receive a warning about the family being renamed. If this is repeated enough, and by enough users at the same time, we could end up with family22 like he described.

For example, if eight people all introduce the same new family to the project then by the time the last person uses SwC there will be eight versions of this family listed in the Project Browser. This is what the Project Browser looks like after just two users think they both need to load a new double door and type.

Jason's post is focused on cleaning up after oneself and it IS important but it is also important to manage the loading of content and harvested details. It is equally important that people understand why these extra versions show up in the first place. Each time someone uses Load Family or Insert from File they must reconcile the warnings that appear before anyone has a chance to begin using the wrong version of the families that are duplicated.

I think it is worth restating that the subtlety of this issue is that this only happens when more than one user is introducing the same new family to the project (via their Local Files).

Once the family is part of the project (defined in the Central File) Revit doesn't get confused anymore. Here's what happens when I introduce the Break Line family he mentioned to the project via two users. Keep in mind that there is no Break Line family defined in the Central File at the moment. Each user loads the family, into their Local File, unaware the other user is doing it too. The first person to use SwC is fine but the second user sees this message (I expanded the warning to see the family description).

When the first user uses Reload Latest or SwC they'll both be able to see this in the Project Browser, listed beneath Detail Items.

Subtlety compounded with yet another subtlety...if the family is already defined in the project (Central File) but a new TYPE is loaded by more than one user then we end up with this situation in the Project Browser.

How do we avoid this situation?

As soon as we think we need to load a new family or type...STOP.

Who (on our team) is responsible for ensuring the content we need is available to us? There ISN'T any ONE person assigned to this? There should be. All new content should be requested, requests sent to or asked of this person. That person can delegate the task.

The goal is to avoid the situation where more than one user is loading the same new content.

Only ONE person needs to load the family(ies)/type(s) and then use SwC to make it available to everyone else on the team (they use Reload Latest). We are working on the same project after all.

To close and return to what inspired my post, Jason went on to write that they've abandoned using Detail Components in their details because of this issue. Tragic. They (the detail families) aren't the problem; Revit's worksharing behavior and user habits are. I hope he'll revisit that decision.

Wednesday, May 13, 2015

Revit 2016 - Loss Method and ASHRAE Tables

Fittings and loss errors have been annoying in Revit MEP for quite some time. If we were striving for a warning free model then we'd be confounded at every turn by fittings and their loss for loss. In Revit 2015 R2 and 2016 we've got the option to assign fitting's Loss Method parameter to Coefficient from ASHRAE Table.

The ASHRAE Table Settings dialog displays graphical information that is associated with duct fittings table. We can choose from among the fitting descriptions in the table or accept the default one that is already selected.

If you select a fitting randomly and check this out you may find the dialog set to None. It only starts to work when components are well connected. That means, if you see warnings associated with fittings, its likely those fittings are not part of a well connected network yet.

Wednesday, October 22, 2014

Local File Error on Open

Have you run into this error message before?

One possible reason is that the folder you are storing local files is running out of allowable space. A folder can have restrictions placed on it. If so Revit can't properly create the local file in a folder that has hit its quota.

When we create a new local file we can often avoid this if we use the option to Overwrite the existing local file versus the Append Timestamp option. Chances are there are just a great many older local files hanging around in the folder.

Friday, May 23, 2014

Past its End

If you see this message, it's not a good message, sorry.

It is a database phrase for the file was not saved properly and the software can't figure out where the beginning and end of the file are correctly, which is a more complicated way to say the file is corrupted. When you get this error it could just be a one time thing. It might be an indication that there are network issues with latency which means that the saving process isn't able to complete reliably. If you get this error frequently it's time to have it checked closely to look for hardware problems.

If you are fortunate you'll be able to open and save a backup version of the project, you need to determine which kind you've got: Stand-alone or worksharing.

If your file is a stand-alone project there will be a project file like this: MyProject.rvt and additional files like this MyProject.0003.rvt, MyProject.0004.rvt and MyProject.0005.rvt. The extra four digits indicate they are backup files. Three additional backup files is the default. Revit writes over the oldest file, never using more than three files for a backup. This is something that can be changed but only when the file is saved initially or when you use Save As. Notice the Options button when you are in the Save dialog next time.

These backup files can be opened just like a regular project file. They represent the state of you project when you saved it, corresponding to the time stamp shown in the file properties. You'll need to use Save As when you do open the file because Revit will ask you if you really want to save a file, as a backup, using the backup file format.

If the project is using Worksets/Worksharing then there is a folder named something like MyProject_Backup. Revit stores all the backup history and data it needs to restore a file in there but you don't do anything with the files inside it directly. You need to open Revit, but don't bother to open a project file, and activate the Collaboration ribbon tab > click Restore Backup. You browse to the location of the project and select the project's backup folder. Revit opens a dialog that let's you choose from a history of saved versions you could choose to recover with.

You should use the Save As button. Pick an earlier version and click Save As. Save the file in a different folder temporarily. The resulting file is technically a local file that is expecting to connect to the central file that isn't working. Revit will ask you if you want to open the file, don't. You'll need to open the file using Detach from Central so that it breaks the relationship to the central.

In either case, hopefully Revit will be able to open the most recent backup file and you won't lose too much work. If the most recent file fails then try the next older version until you get the project open again. Save the file back into the correct project folder and carry on.

If you want more background on worksharing I've got a summary of posts I've written on the subject.

Thursday, December 19, 2013

Copy Paste and Structural Floors

The situation this post describes seems like a bug to me. If not then it is certainly confusing least.

When we use Copy to Clipboard and Paste Aligned... to place families on another level or more than one other level the outcome is affected by whether a structural floor slab was present when the families were added. For example consider these floor slabs (see next image), each configured as shown by the screen capture of their properties. There are three desks in the view too, one on each floor. Specifically the floor on the left does not have it's Structural parameter checked, the middle floor has both Structural AND Enable Analytical Model parameters checked, and the floor on the right only has the Structural parameter checked.

If we use the Copy to Clipboard tool on the three desks (one on each floor) and then use Paste Aligned to Selected Levels, choosing Level 2 we get a dialog showing that there are two warnings associated with the desks over the two structural floors. The desk on the left is not involved in the warning.

This is what the end result looks like in elevation. We have a new desk on Level 2 above the floor that is not structural but the other two new desks are in the same location on Level 1.

At this point it appears that it is caused by using the Structural parameter. If it's checked that is BAD for using Copy/Paste. If we create a floor that is not structural the hosting relationship isn't forced on the hosted elements. If at any time we check the structural parameter any elements that you place on that surface will lock out the normal desired Copy/Paste behavior, they'll only be placed on that surface. Deciding to un-check (turn off) the option after it was turned on won't resolve the situation either. The floor can't EVER be structural. If they are/were any families placed on the floor's level will become locked in to that floor.

Said another way, this condition affects families that were originally placed on a floor that is or became Structural before the families were placed. If the families were there before the floor or before the floor was changed to structural they'll work fine with Copy/Paste. In my testing so far this condition also appears to be limited to families that are level based (also referred to as "not" hosted), for example furniture, casework, generic model, plumbing, and specialty equipment. If the families are "Face-Based" they appear to be unaffected, for example a light fixture.

We can avoid this by turning off the Floor category in the view before placing families. Changing the view to use Wireframe instead will not help.

This post is the result of looking at a project shared at RFO that was exhibiting the problem.

Thursday, November 14, 2013

Errors and Omissions

This is a repost from September 2009 based on having this conversation a couple times recently.

Every now and then I read an article pumping BIM or Revit. It used to be few and far between but new articles pop up daily. All too often the words, never, perfect, automatic, press-of-a-button and many more show up in the text. These words are used to compare Revit with other software and are often meant to highlight the strengths that Revit has. The fact that we can generate elevations and sections easily and that they are derived from the model without drawing them completely from scratch is wonderful. Many examples can use a little dose of reality.

There is an Urban Legend where a person bought a Winnebago and thought the cruise control didn't require someone behind the wheel. Most people laugh or at least chuckle at the notion that someone would set cruise control and get up to make a sandwich (the version I've heard the most) and think that the vehicle could safely navigate on its own.

Let's be clear - we can make mistakes in Revit too.

I used the image above a few days ago regarding interference detection but each of these things can be done easily in Revit.

Revit coordinates information much better and makes it more obvious that things are wrong too, like the things in the image. When things are working well, if it is correct it is correct everywhere. With Revit, when it is wrong, it is wrong EVERYWHERE too. This is an important distinction. When comparing Revit to other software the thing that is wrong in other software may be correct elsewhere because there is no connection to the other drawing or representation of the building. The distinction here is that documents are derived from the modeling process in Revit and embellished to create a finished document, with documents as the deliverable or focus for now.

Schedules are never wrong! I read this one every now and then, unfortunately this is incorrect. A schedule that does not use sorting/filtering, design options or phases as criteria will not report incorrect information. A schedule will NOT misrepresent data though. For example, a single panel door will not magically become a double panel door unless someone swaps a single for a double in the model. A schedule CAN misrepresent the whole story though by excluding information because of criteria applied by the user. User Error CAN and WILL creep into a Revit model. You can't blindly accept the results you get.

If we can make mistakes in cad and in Revit then what's the difference?

The difference is in how many of the mistakes are easily prevented or eliminated. Revit does a great job of managing the annotation related to views, sections, elevations, details and enlarged views etc. So much of the hassle of checking these is greatly reduced. When mistakes are made in Revit a team is much more likely to bump into them because they are working on the same data set or model. With the separate file process used by cad a team can be quite isolated from one another. How do I know if someone is making mistakes in their drawing if I really only see their work when it is printed out? Even then I have to visually compare their work with mine. Digitally I can reference their files and check them on the computer. All of this is so much easier, or at least more fluid, and we are always in the context of the building with Revit.

So much of quality assurance is the rigorous studying of printed drawings for inconsistencies. Much of it is based on years of experience and even intuition. I know that this and this are likely conflicts so I'm hunting for them. Most firms have checklists that go on for days.

It is my observation that teams using Revit know more about each others work and the whole building than teams who use other software. How can you avoid being more aware of what someone on your team has been up to when you see and walk by their work in the model each day? I've also observed many times that two users will have a conflict because they both observed a problem and set out to fix it at the nearly the same time, which generates a permission warning.

With my Revit bias you won't likely find me telling you Revit isn't the correct choice for you. I do want you to have realistic expectations though. The Staples EASY Button is a great fun thing to think of but what we do in this AEC business is rarely truly easy.

Mistakes can and will be made using Revit. Revit does give you a much better chance to catch and minimize mistakes as well as the opportunity to focus on making good decisions, and doing so as early as is practical so that the costs associated with those decisions can be managed well. Said another way, a past client once said to me in language more colorful than I'll write here, "My staff are making mistakes in cad all day long, at least in Revit they will be better coordinated!". Perhaps a bit too practical or not a lofty enough goal, but focused and realistic!

Monday, April 23, 2012

Extents Greater than 20 Miles

This message appears when you import a DWG file that has geometry that makes the total extents of the file larger than 20 (33 km)miles horizontally or vertically.

That message is different from this message.

The second message occurs when all the geometry in the file is farther away from the origin than Revit wants it to be, but the extent of geometry is not large enough to trigger the first warning. What that magical distance or number is, who knows. I've spent quite a bit of time trying to pin that down. The closest I've come is that when I have some geometry that is between 43,500 and 50,000 feet away from the origin of the DWG file Revit will complain. The problem with pinning it down is that as soon as I think I've got it, I change it a little and then Revit doesn't complain about importing the file. Suffice it to say that if all the geometry is pretty far away from the origin, there is a pretty good chance that you'll see that message. It isn't as far away as the first error message though (20 miles), it's more like 8ish miles.

If a file is too large to import when you've selected the correct units you can technically circumvent it by importing with different units. For example if Inches are too big, try Feet. The file will like import. Then you can reset the Units of the file and reset the scale value to 1. The file will be the correct size again. It won't prevent the graphical issues that really large DWG import can cause though. Your mileage may vary.

Another technique that has worked is to link the big file into another file as an Attached overlay. Then import the file that hosts the big one. Revit doesn't look at the Xref and doesn't complain.

Tuesday, January 03, 2012

Sorry You are Too Short

No I'm not picking on short people, that's Randy Newman's domain. Revit does have a bias against short lines (as most of us are well aware). Try sketching a line that's less than 1/32" long and you'll get this message.

It also doesn't care much for moving or copying elements very small distances. You may have run into this message?

What may not be obvious is that you can often trim a line to be shorter than the minimum size of 1/32". The threshold appears to be 1/128" (.16mm). In my experience this appears to work for most families such as annotation, detail component and generic model families. I've tried it in various project views including a drafting view without success. The project environment seems to be entirely intolerant of slipping past the 1/32" (0.780369mm) threshold. Trying to get smaller than that generates the first warning again.

If you want to copy/move something a smaller distance and get the warning, try dragging or using CTRL + Drag. You can get the arbitrary smaller distance and then use the temporary dimension to set the actual distance you want. Sometimes you can affect this limitation by zooming in closer, at least with regard to move or copy.

Fwiw, 1/128" converted to decimal is 0.00781250". I was able to make a line shorter still, to this decimal inch value 0.0063477", however Revit could not display anything other than 1/128" unless I changed the project units to decimal inches first using six decimal places. It is possible to create shorter lines than we are accustomed to (Revit limits) but only in family files.

Friday, January 21, 2011

Dept. of Huh? - A New Little Guy?

I've been dealing with getting Windows 7 installed and rebuilding my life on the PC during this past week, finally! A continual experience of, "oh, let's take care of this! Oops, I didn't install that yet...hello Firefox let's download some software!" Like the video I wanted to record for another post next week, oops don't have Jing installed yet.

I fired up Revit Architecture 2011 this morning and I'm greeted by this new little guy!

It lingers there on screen until I actually click on it to close it. I'm thinking it is supposed to be hidden and related to getting authorization/licensing? Can't imagine what cool setting I've triggered to get it!

Anybody else seen this?? Say hello to my little friend?

[Added 5:40 PM - January 21, 2011] Thanks to Ryan Duell's specific comment about graphics card managers I remembered that I did play with settings in my nvidia Quadro FX1600m configuration using their nView Properties tool. Turns out that checking the option: Prevent windows from opening off-screen was the culprit. Disable that and no little friend, bye bye. Sorry, but I won't miss you.

Thanks Ryan!! and the other comments too!

Friday, November 26, 2010

Unresolved References

I'm experiencing an issue where files that have linked files (Revit files that is, haven't tested CAD links) that aren't found are causing Revit to get stuck at the Unresolved References dialog. A simple test will confirm, rename a linked file and try to open the project that references again. It happens to me whether I'm referencing a file on a network or on my own hard drive regardless. The computer also freezes any other graphics that appear over the Revit session. I can drag the application to a different monitor but an image of it is trapped on the Revit window. Very odd. This is what the dialog looks like unfortunately.

The only way I can get back to work is to use Task Manager to use End Task on Revit.exe. I can't open any file that can't find its references. Looks like I've got a Uninstall/Reinstall in my future, near future, very near future.

Anyone else running into this?