*Face Based Family Hosted on Reference Plane relocating itself wildly on parameter change or family swap*

[david_burchellJDSME]

I have posted this issue before with no resolution but the error persists and so I assume it to be a bug somewhere within Revit.

Essentially I have a face based family I created (a sprinkler) assigned to reference planes in a project, with the benefit that these elements can be copied about slopes (reference planes) in a plan view and also display annotation symbols correctly without tagging.

While these appear to function correctly for a time, randomly some instances will start to malfunction and fly off their reference planes by large distances in both plan and elevation, breaking associated connections (see screen record).

This tends to occur when changing any parameter or swapping out the family with another almost identical one, meaning once they break you are stuck without solution but to delete the offending instances.

It does not occur with every instance but the extent of corruption appears to increase with time with no easy fix save manually replacing and connecting the elements (incredibly time consuming).

I have recreated these families from scratch after first encountering the issue to try and rule out family corruption but it persists and thus I assume it to be either an issue with the face based family or with Revit itself.

Has anyone else experienced this / found a fix and does anyone developer side know what could be causing this?

I have tried many possible solutions with the families to try and resolve and still retain the desired functionality. To not use face-based families is not a solution in my opinion as these should behave as designed and as stated they have unique benefits for the intended application.

It seems a fairly serious issue on the MEP side and causes severe issues for anyone like myself placing large quantities of hosted families in a project as the issue presents itself randomly with no definitive cause or solution.

I attach screengrab of the issue in action along with the family in use.

Thanks in advance.

[fabiosato]

Hello,

Which Revit version are you using?

I made a quick test on Revit 2019, the family´s version, and it seems to work well. 

[david_burchellJDSME]

Hi,

Most recently used on Revit 2022 with noted behaviour.

Its a hard one to pin down as they will behave predictably for a time and then somehow get corrupted. Some will continue to behave fine and others will exhibit this jumping behaviour. Very strange.

Am hoping someone else has experienced something similar to confirm it is a genuine bug and not a family issue.

Regards

[ducmap2212]

Hi,
I think face based family is not a good choice, use normal family and set workplane in family environment may help you solve this problem

[david_burchellJDSME]

Thanks for suggestion. I have tried as a Work Plane -Based Generic model family but the functionality is impaired.

The main benefit of having the face-based family is that it can  be copied or moved in plan views and it stays on the work-plane host.

This is what is required as far as sprinkler design is concerned as you want to space the sprinklers in plan (i.e. dimensioned on the flat) but have them stick to the soffit slope in section. This way you could copy one 3m in plan and it would actually move up or down the slope.

Work Plane Based families do not appear to remain connected to their hosts in this way which makes spacing sprinklers with them on a slope much more time consuming.

[ducmap2212]

I think there is something wrong with your family, work plane based can do what faced base can.

[david_burchellJDSME]

I dont think so tbh. There is no such thing as a work-plane based family type (see attached).

What I think you are thinking of is a face-based family hosted on a workplane which is the family I shared. The only other alternative can be the one I suggested which is a standard generic model family with 'workplane based' checked in the properties.

[RSomppi]

Try this:

https://help.autodesk.com/view/RVT/2024/ENU/?guid=GUID-3FE4DAED-82D8-4C56-A017-737BDA740E50

[david_burchellJDSME]

This is a link for 'how to create a plan view'??

[RSomppi]

Sorry, wrong thread.

[fabiosato]

Hello,

Use the Work Plane-Based setting in a generic model family.

Uncheck the Always vertical if you want it to be perpendicular to a sloped surface.

[david_burchellJDSME]

Please see message 5. I have tried this approach already before posting and the functionality is impaired - work plane based do not 'stick' to workplanes.

Clearly the face based family has been created to serve a specific requirement (one which serves me) yet it is not performing as designed and appears to be victim of this inherent bug.

There must be other face-based family users out there who have experienced a similar issue with hosting MEP items with connectors to workplanes?

To abandon the face-based family does not resolve the underlying issue..

[RSomppi]

---

@david_burchellJDSME wrote:

To not use face-based families is not a solution in my opinion as these should behave as designed and as stated they have unique benefits for the intended application.

---

Why are you limiting yourself?

When I started using Revit for MEP design, we almost immediately chose not to use hosted families because of a variety of reasons. First and foremost was that we did not have control of the hosts because of linked architectural models. Most libraries that I've worked with or built were almost entirely level based families.

[david_burchellJDSME]

Refer to Message 5 for clarity. I created the face based family for sloped soffits only and there is no restriction as the instances are hosted on workplanes in my model, not the Linked model geometry. You are right to abandon face based families for most workflows due to inherent lack of flexibility in use but for this application they are perfect and far exceed the intelligence and usability of level based alternatives (when they behave)

I have created extensive libraries of parametric MEP families so have a fair amount of experience in this regard and you need to trust me that if these worked as they should they are perfect.

IMO the bug needs fixing by Autodesk as face based families have a place and as explained offer unique benefits for this use case.

Arguing for using different family types is a waste of time unless they satisfy the objectives made clear in message 5 and would be considered a workaround only, not solution.

[RSomppi]

Sorry, I was only trying to help. You are entitled to your opinion but your complaints need to be directed to Autodesk. This is a user based forum. Try the IDEAS forum to suggest fixes.

[david_burchellJDSME]

Hey, No offence intended and appreciate your trying to help.

Will try the ideas forum but expect no resolution there until it gets confirmed as an issue.

Main reason for posting here was trying to find others who have experienced the issue as its difficult to replicate consistently and needs confirmation.

Seems to present as a unique effect of workplane hosted, face based families which are connected in an MEP network. Driving me crazy tbh.

[sragan]

Have you tried auditing the family?

I get a different file size after doing an audit, which might indicate something changed.