Showing posts with label Issues. Show all posts
Showing posts with label Issues. Show all posts

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?




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.

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.

Wednesday, May 22, 2019

Filter Dialog and Reading a Long Filter Name

Dialog stretchiness has been an ongoing long standing user wish for all dialogs. Daniel wrote to me hoping that I'd echo his complaint about the Filter dialog. Yes you can stretch it but the frames remain less so. The Filter name frame does add a scroll bar at the bottom when a filter name exceeds the width of the frame, which does not increase in size when the overall host dialog stretches out. Ideally we'd be able to stretch/adjust individual sections of such dialog boxes. If memory serves that is dependent upon which GUI tools are being used to generate the dialog. If that tool set doesn't do it then...we don't get it...without a custom entity.

Daniel was writing about Revit 2019. Even when you scroll over to the right completely a filter with a long name gets truncated and you can't read all of the name.


I note that in Revit 2020 a tooltip will appear that displays the full name while the frame does the same truncating even when it has been scrolled completely to the right.


Naturally, we can avoid it if we can use Filter names that are not very long, an easy fix...there's that word again - easy. Easier said than done...it seems.

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

RevitForum.org Back

It appears to be restored via a new ISP and up and running again. Glad it's back!

...EDIT...some are saying it isn't fully set up at the new ISP yet...mileage may vary for a bit longer but it is on the way.

...EDIT...Site is still in transition to a new ISP, a message to that effect appears on the site until it is fully transitioned. (05/10/2019)

...EDIT...Site is UP, restored...aahhh

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!!

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.

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.

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.

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.

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.