Hello all, we have been dealing with this problem for a number of years so I wonder if you guys know any solution or workaround for it. When copy pasting families between projects with different “family definition” but same family name Revit rename the family that is pasted to avoid conflicts? this results on a large list of family duplicates, specially if they are Detail Items in Detail Groups.
I have found a number of threads like the one below but not a practical solution???
Anyone has used Guardian Family Mapping successfuly?
Hows is this dynamo related? Are you coping to the new file via API method?
What is the end goal? Do you want to overwrite the family with the new one, potentially causing data loss? Use the old family in place of the existing? Have both with different names?
Hi Jacob, thanks for your message, I will try to explain both:
1.I dropped the item here cause it is a Revit issue so I thought about asking the community if via Dynamo/Revit API could be a workaround to it.
2.The end goal is quite simple if you have family named a in project a and you have another family named a in project b when you copy paste the family from a to b you would expect Revit to update the family and not append a suffix to the pasted family to avoid conflicts. The main issue we have is copy pasting Detail Groups across projects with Detail Items, if some families exist in the destination file instead of updating them create a bunch of duplicates.
It is quite frequent to end up with double the number of Detail Items, and within groups so replacing without losing annotations is a big thing.
For #1: The Revit API can accomplish such a task, but I wouldn’t go the Dynamo route as it would have to be more of a ‘dynamo only’ command to work - you can’t effectively & safely trigger Dynamo to do something when another action is taken. It can be made to work (search the forum for event listener for examples), but while some have reported success it isn’t a supported workflow at this time (read that as you may lose data/production time so proceed with caution).
For #2: The desire now makes sense, but you might want to proceed with caution. Say Project A and Project B have a detail item named ‘plywood’. Detail B started with the same family, but a user edited it to insert an extra reference plane which controls a constrained graph for a nailing symbol. The nailing symbol is also dimensioned and tagged not in the family environment but in the project. Extra parameters were also added to control the tag values to indicate the nailing pattern names.
By using the version in Project A when pasting the content from Project B you will lose the nailing symbol, annotation, dimension lines, and family parameters. Now if you inly have project A and B you can ‘fetch’ the item later to reproduce the issue and use the ‘load into project’ method to update all the components. But the copy/paste will never allow moving things over as the command has an event listener to prevent the alternative insertion.
This is really a people issue not a technology one as the content your firm produces should be the same for all projects in order to scale your work effectively. And so the recommendation I make to people who ask about this is to manage your detailing in a central rvt file, monitoring your project modifications to families and use of non-standard details and components thereof.When users want a detail they can leverage ‘insert view from file’ and things will always be to the standard. You just need to help people navigate that change by providing incentives to ‘keep to the standard’ as they work.
For technical solutions I would recommend looking into UniFi and other content management solutions, as they can help track what changes have been made when they occur.
I disagree with you in one thing, this is a technology issue.
As Steve Stafford explained very well in his blog, link attached above.
If User a in project a do not change anything in the family at all, but just upgrade from one version into another or saving the family Revit still do the same thing.
We have a library of detail items, and teams assemble the detail groups in their projects. They dont make changes to families at all and other teams want to make use of these detail groups, collections of items.
It is not possible to copy/paste without having to deal with duplicates.
What we think it should happen otherwise, Revit should prompt you with what do you want to do with the duplicates rename or use the host elements.
But upgrading is a change. You may have heard the horror stories of particular families which if upgraded from Revit 2010 to Revit 2024 fail to properly transition all the data. While exceedingly rare, they happen. So in our previous situation, let’s say project A was built in Revit 2024 using components from your family library which were upgraded every year (and therefore with proper QA performed). But project B which has the modification done was in 2010 format, and just directly opened and copy/pasted across the two projects. When the user "just wants to grab the previous unmaintained detail’ and opens it up and copies it over there are three options the tool could take:
Swap all instances of the family to the version from project B even though data may be lost and indeed the entire project could go corrupt.
Swap the pasted version out for the version in the project, even though the references might differ due to the lack of maintenance over the years.
Duplicate the family type and allow the user to decide manually, or indeed even keep separate versions to account for the extra dimensions.
The technology can force option 1 or 2 - and indeed I can attest to the Revit development team having had such discussions in the past. In asking others "would you rather risk losing data from the pasted content or from the original content’ the answer was 30/30/40, with 30% opting for ‘pasted’ or ‘in project’, and in fact most saying “it depends”. And to deal with ‘it depends’ means Revit has to ask ‘do you want to do option 1 or 2?’ for family which differs. That isn’t feasible as it would often result in 100’s of pop ups in sequence - users would revolt and the time such a transaction would be open for could lead to both corruption concerns and worksharing issues. All of this is to say nothing of the many ‘cannot edit element until…’ warnings which will come up in bulk editing family types and instances without knowledge of when/where. And so option 3 of adding duplicates was the solution as it’s feasible at scale.
Option 4 is likely what you really want, which is multiple paste options. One for ‘paste using in project families’, one for paste using ‘source project families’, and one for ‘paste with duplicated families’. You could write such an add-in or indeed Dynamo graphs, but the general confusion around paste options even outside of AEC (consider the humble paste options in MS Word) means the ROI will likely be less than envisioned.
I don’t need option 4, I’d like to choose between option 1 or 2.
The user should be aware of the information when copy/pasting, similarly when we use Transfer Project Standards the user should be aware of the consequences of doing it.
There is no need for data loss if we know what we are doing, let the user decide.
We are suffering with this default behaviour and it’d be good if Autodesk take some actions on it.
Guardian Family Mapping has been developed to cover this gap so that means that is not only us who would like this to be implemented.
The user can’t necessarily see the difference though - the files might look exactly the same but not be (ie: the filled region showing the pattern for the plywood could have one more line in it reference to be lost). To see how much impact that might have for your jobs, PDF one of your projects with duplicates, then select all elements of family type in you project browser for all the elements which are one of the duplicate types and change it to the non-duplicate. If there is a single warning or error which pops up, or if the view prints differently you would have lost data during the process. The data loss is often more detrimental than most think, and that’s where the people/process comes into play.
As noted above ‘option 1’ or ‘option 2’ don’t have anything resembling a consensus - with ‘it depends’ being the majority preference. The Revit team has fostered the flexibility to build whichever option you’d like via the API though, and this is sadly the only real path forward without risking data loss, which is a non-starter (for likely obvious reasons).
Honestly I’d recommend just contacting and scheduling a demo with the Guardian team, they’re a good bunch. Yes it’s paid, software budget etc. but solving this one in API or your own developed app is likely also costly so at the least worth connecting with them.
I’ve played with this and it’s a wicked challenge and a shortcoming of the software (which I don’t think will be addressed during Revit’s lifetime). Closest I got was:
Dynamo script runs with selected detail item elements to copy
User ensures there are no detail groups in use as API cannot access them
Second script reads a csv made on desktop with the element ids, rounds them up and pastes them all in the new model. I had to process all the possible location and placement methods, but I edit/load the families over first, and after I create the elements fresh in the model vs copy/paste elements
Most users don’t use it as it’s too clunky and copy/paste is too tempting for lazy/time poor people.
One other, perhaps more valuable root for a Dynamo tool would be a ‘unify duplicate families’, which would allow grouping families by common name, and walk the user though their options in selecting ‘one family to rule the rest’. Other than when suffering the pain of groups this would not be too build either.
Guardian Family Mapping works super well!!! it does provide a workaround with copy/pasting even when we are copying famlies in a group as there is only one instance of it.
The issue is if we use the tool once there are multiple instances of the same group type, we face another constraint which is not been able to edit groups via API.
As Gavin advised too I’d really recommend giving a shot to the Guardian Toolset.
I tried to copy family types and Overwrite with IronPython2.7 code inside Dynamo. If family names or family types already exists it doesn’t Overwrite it adds a number sequence at the end of the names.
I commented this is different post and i remember you replied with an answer like just copy and accept that then swap all element instances by the new types renamed with a number at end, then delete the previous family type version and when successful then rename the current swapped families back to original.
I was wondering if in the current project file we could set the property of family types to which i think was something familysymbol.isactive, if it’s set to false perhaps when copying it actually overwrites the types because it’s like if it’s not being used in the project?
Nevertheless, I experienced a real pain with Revit families of pipe fittings and pipe accessories families in a project, even doing the Overwrite manually in Revit I have been waiting around 5 hours to Revit to respond and always gets hundreds of error warnings saying the elements have been disconnected from the system or some families nested families have been broken for unknown reasons but deleted. So i am afraid to try to resolve with script .
Sometimes the families are not overwritten and what i have to do is change damily names and nested families names and load into the project and swap manually the family instances amd even doing replacing manually sometimes revit gives an error that doesn’t allow to swap the only option is cancel and undo the task, so forced to delete those elements and model the again in same locations.
And i suppose Revit is doing this because families have one family type that generate any size by lookuptable and many nested shared families driven by lookuptable as well. Have to live with Revit
So this approach sounds like remove those families that want to be replaced and create same family types as the original, need to create dimensions and tags again, great pain work, I don’t achieve this by using Dynamo
Our project life span is typically a number of years, Revit versions every year, maintaining libraries for all to avoid this issue is far from possible.
Much easier let user decide to override or not… same as transfering other standards
I think we’ll have to agree to disagree on this point, as I have successfully implemented such a library before joining Autodesk (200+ users), and have worked with companies exceeding 2k users with similar setups. No system works unless the users follow it though, so any implementation should always start with the people and mange the change you’re about to implement.
.